Allowing Zendesk to send email on behalf of your email domain

Have more questions? Submit a request

136 Comments

  • Jonathan March
    Comment actions Permalink

    Thanks, Sean.

    Regarding multiple addresses: 

    Actually it seemed that I needed to verify each support address separately even though they all have the same domain. Maybe I was not patient enough to let the verification propagate between address records? Anyway, after I verified each one separately, they all did show the same verification status.

    Specifically: Before our IT team added these new CNAME records, they all showed this:

    and after they added the new CNAME records, they all showed this:

    Is this immediate change in SPF status expected here? (I've also asked our IT to verify that the old SPF record had not yet been removed from our DNS server, as your instructions specify).

    Thanks.

    0
  • Sean Cusick
    Comment actions Permalink

    Hey Jonathan, Yes, I should have said that for our purposes verifying the domain once is all that is needed, the others should propagate in time. After a minute or two a refresh would also do it. The SPF will have been unchanged. Nothing on our end would change your DNS records, of course, but I will  look into this and see if perhaps there is an unexpected interaction between those settings within the UI. Thanks for letting us know. 

    0
  • Jonathan March
    Comment actions Permalink

    Thanks, Sean. In case it helps, I've dug back for some more context.

    It appears that our IT might never have actually created the recommended SPF record (back in 2016 when I first requested that this be done), and it didn't seem urgent to me to insist on it, since retrying the SPF checks (in the config email screen) made the SPF record warnings turn green.

    If this is accurate, then it's only now, after our IT added the recommended CNAME records, that the SPF warning re-emerged, but now persistently.

     

    What consequences might we experience if we leave things as-is until the AWS switchover in the next few months?

    Should this be moved to a support ticket? (Not sure how many others are in the same boat.)

     

    0
  • Jonathan March
    Comment actions Permalink

    Sean,

    As suspected, we never had the recommended SPF record, yet the SPF checks were always green until these new CNAME records were added.

    Now the SPF checks are orange as shown above.

    Will this be a problem over the next 2 months until the changeover to AWS?

    Thanks!

    0
  • Sean Cusick
    Comment actions Permalink

    Hey Jonathan, Maybe we should open a ticket to discuss this further, as we have a ticket that reflects the correct messaging for your SPF check and any additional questions will likely get into territory where we'll need more precise information? Could you send us a ticket at support@zendesk.com and include the link to this comment? 

    0
  • Jonathan March
    Comment actions Permalink

    Thanks, done.

    0
  • Fuad Gasimzade
    Comment actions Permalink

    Hello,

    I am adding CNAMEs for the domain and as per the guide, I should have a verification code under my support email address. But I dont see it. There is only Retry and Learn More buttons

    Can you please assist

    Thank you

    1
  • Kristal Lam
    Comment actions Permalink

    @Fuad - do you mind checking again? If you still don't see please create a ticket for support@zendesk.com. Thanks! 

    1
  • Fuad Gasimzade
    Comment actions Permalink

    Thank you, all worked!

    0
  • Michaël Gaudette
    Comment actions Permalink

    I haven't touched SPF seriously in a while, but my understanding is that the steps described in this article will allow the Amazon AWS/Zendesk combo to send emails on our behalf starting January 2019, but SPF records are not just meant to prove to you we own the domain, but are still relevant to prevent/decrease emails sent out on our behalf from spam-factories (or other fraudsters).

     

    Will include:mail.zendesk.com still be the right way to announce to SPF-enabled recipients thatthose emails are legit? We use a hard fail (-all sign) in our SPF record, so it's important that our SPF records are still working for whoever receives those zendesk emails when this new system is activated.

    0
  • Robert Bollinger
    Comment actions Permalink

    Ok so trying to understand this here. By following the directions on this page would I basically be setting up DNS delegation for a subdomain?

    https://dmarcian.com/soboo-delegation-with-cnames/

    For instance: if you Zendesk are currently sending emails as us: boune_randomaddress@mydomains.com to our (mydomains.com) customers, and those messages are being verified via an TXT based SPF record. (typical).

    Are you now saying that we will need to modify our Mail-From address in our zendesk.com portal:

    bounce_randomaddress@delegated.mydomains.com

    when sending emails? I am trying to wrap my head around how CNAME records and sub domain delegation are being used here. I haven't had to implement this type of email verification, before so am a little confused.

    Thanks,

    Robert

    0
  • Henrik Schack
    Comment actions Permalink

    Hi Robert

    The currently in use solution doesn't provide proper bounce handling.
    It works fine if the email is being rejected during the SMTP dialogue, but if the recipient's mail server needs to "dial back" at a later time, the bounce email is delivered to your mail server instead of the Zendesk mail servers.

    The new way is the perfect solution, bounce handling is done right, and you can get full DMARC compliance (SPF & DKIM alignment) if you need that.

    /Henrik Schack

    0
  • Robert Bollinger
    Comment actions Permalink

    Henrik,

     

    Thanks for the response. I am curious to know if I am right in my assessment of how this is supposed to work? I have never had to setup CNAME record delegation before so I am a little unclear.

    Its my understanding that this document as the final step asks you to remove SPF altogether once they have cutover to AWS.

    Thanks,

    Robert

    0
  • Jon Daniels
    Comment actions Permalink

    Hey Michaël!

    You'll want to hang onto your SPF record settings until the change happens, but once the change to the CNAME record check occurs, the original SPF records won't be necessary (or looked at) at all.

    Let us know if you have any further questions regarding this, we'll be happy to clarify!

     

    0
  • Michaël Gaudette
    Comment actions Permalink

    Hi Jon,

     

    The SPF record may not be looked at by Zendesk or associated services, but other SMTP servers (i.e. my customer's) will still refer to it when accepting emails, if they have an SPF check enabled.  So the question is relevant - will "include:mail.zendesk.com" encompass mail servers sending out emails on our behalf on your side, or will emails be sent on our behalf from other, SPF-breaking servers?

    Or, another way of asking is: what email/SPF string will i need to put in to include your outgoing servers when that change happens?

    0
  • Sean Cusick
    Comment actions Permalink

    Hi Michael, SPF will verify at the moment of the initial smtp relay and can be re-verified at any time by any server looking up the domain that will get set in the Return-Path header. SPF was designed to be a system that prevented forgery of the Envelope-Sender. The envelope will be from something like zendesk1.example.com (with example.com representing your domain). The domain found in the mail envelope sender header is the subject of SPF authentication. That authorization will happen at the moment of the initial smtp relay or afterwards at any time. The SPF will still validate because those CNAME records on your domain alias the mx host that is doing the sending. There will no longer be a need for there to be a TXT record for include:mail.zendesk.com because the authority to send will be established and maintained through the CNAME record. 

    0
  • Michaël Gaudette
    Comment actions Permalink

    Thanks Sean,

    I'll admit that my SPF knowledge is superficial

    I understand that now the I created CNAME alias the proper MX host that will send emails, but my SPF string does not include those MX servers - my only reference to Zendesk is include:mail.zendesk.com .

    The other SPF "permissions" are to my own MX, other tech partners (like you) that send emails on our behalf and internal servers.

    In other words, I somehow need to have a place in my SPF record that link to those CNAMEs, don't I? 

    0
  • Sean Cusick
    Comment actions Permalink

    Hi Michael, Use of the SPF TXT protocol is not a requirement for SPF to pass, that record just allows some more flexibility in maintaining your DNS. It is not meant to be an exhaustive list of allowed senders. The most important component of SPF passing is what happens at the MAIL FROM argument when the outbound smtp relay is being established (and to a lesser degree the HELO/EHLO argument). This is where the CNAME records alias the domain used in the Envelope-From / Return-Path header, which is what allows SPF to pass and also to be subsequently verified by any recipient server at any time. You do not need anything in your SPF TXT record to point to the CNAME records. Those records are what will be queried by any given recipient server due to this outbound sending process and will provide the authority to send.   

    0
  • Robert Bollinger
    Comment actions Permalink

    Sean. Sorry for jumping in on this but.

    I setup zendesk to send emails as my newdomain.com, I then set support@newdomain.com as my default. I then opened a ticket, a message was sent using the following addresses:

    When investigating the headers:

    Return-Path: support@mytenant.zendesk.com

    Mail-From: support@mytenant.zendesk.com

    From:support@newdomain.com (expected default).

    SPF is passing, but naturally its passing because Zendesk is connecting to Office 365's mail servers using its own name/domain name.  

    So what is the benefit of using the CNAME records, if zendesk is just going to connect to office 365's mail servers using its own domain name.

    I realize that From: should be auth'd as well here (by cname), but I can find any mention in the RFCs where it says "use a CNAME" record instead of a TXT record. Or "CNAME Records" are supported for validating SPF.

    Thanks,

    Robert

    0
  • Henrik Schack
    Comment actions Permalink

    Hi Robert

    I would expect the new solution to work something like this if configured to use your identity in the messages.

    example.com is the customer.

    Mail From/Return-Path: randomstuff@zendesk1.example.com
    From: support@example.com

    Zendesk will perform the actual delivery using SMTP servers at Amazon.

    I think the reason the CNAME approach is chosen is to make it easy on the customers AND to be able to deploy changes in the future without causing a support thread like this one :-)

    Easy because:
    Customer must only create one DNS record, the non CNAME version would require us to create an MX record and a TXT (SPF) record.

    Future proof because:
    Should Zendesk at some point in the future choose to move their entire operation to say the Google cloud, they can do so without any changes at their customers end, They simply just change the contents of the records we are pointing our CNAME records at.

    If you are DKIM signing with Zendesk today, you have already experienced the advantage of using a CNAME based solution, nobody has asked you to change your DKIM configuration. 

    0
  • Théo Koutsaftis
    Comment actions Permalink

     

    Hello everyone,

    Unfortunately, while the CNAME records are easy to add, my hosting provider blocks my attempts to add the TXT entry with zendesk_verification as its name.

    I've contacted their support and they say the underscore _ should be placed at the beginning according to the rules defined by RFC (see here : https://tools.ietf.org/id/draft-ietf-dnsop-attrleaf-07.html)

    In short they tell me that I cannot have zendesk_verification.mydomain.com, that in order to comply it should be zendesk._verification.mydomain.com to respect the RFC protocol.

    I admit this is way over my head in technical terms. Is there another way to verify my domain? Or is it possible to use another name in order to bypass the underscore all-together ?

     

    0
  • Robert Bollinger
    Comment actions Permalink

    Henrik,

     

    Thanks so much on that. The last part is what I was missing the mail-from of username@zendesk1.domain.com. Now it makes sense to me.

    This was driving me nuts!! So I appreciate the quick response and the easy to understand explanation. I have never used zendesk before and am the Office 365/Exchange messaging guy for my employer. I got a ticket asking about adding CNAME records which led me down this rabbit hole.

    However since I had no idea  that you could CNAME in place of TXT records for SPF, now I have learned something new.

    Thanks again.

    Unfortunately my trial tenant will expire before the changes are made, but I am satisfied with this response.

    Robert

    0
  • Sean Cusick
    Comment actions Permalink

    Thanks to everybody for adding some important information to this thread!

    What Henrik has said is correct: the CNAME solution was chosen for ease of implementation. It is also possible to also add four MX and four TXT records to accomplish the same thing. 

    Robert, if you open a ticket with us we can explain why you are seeing what you are seeing with the Mail-From and Return-Path values. If you do open a ticket, please reference this comment thread. It has to do with sender identifier alignment and will be changing soon (once we're fully sending from SES). I'd prefer to discuss that with you directly, so as to avoid future confusion here in the comments, etc.

    Theo: you can use zendeskverification in place of zendesk_verification. 

    0
  • Michaël Gaudette
    Comment actions Permalink

    Thanks Sean, these last answers clarified things for me (that, and reading the more detailed article here )

    In any case, I imagine Zendesk will let us know when that is done so that we can all run to our zendesk and run a few tests to make sure everything as planned.

     

    Mike

    0
  • Théo Koutsaftis
    Comment actions Permalink

    @Sean Cusick : Thank you very much for this clarification, it worked perfectly and solved my issue.

    Maybe @Max McCal can update the article to add the name without the underscore for those of us with pesky hosting providers.

    Again thanks a lot.
    Théo

    0
  • Dolev Zemer
    Comment actions Permalink

    Hi,

    I believe we made the necessary changes in the DNS. how can we be sure that everything is in order and that we are set for the zendesk servers migration?

    0
  • Sean Cusick
    Comment actions Permalink

    Hi Dolev, If all of the verification checks in Channels>>Email>>Support Addresses - forwarding, SPF, and DNS - all show green check marks then you're ready for the migration. If you see a yellow or red ! next to any of them then you may want recheck your forwarding rules and SPF/DNS settings. If you can not get them to verify by following the instructions in the article then you may want contact your email/domain provider and also open a ticket with us at support@zendesk.com

    0
  • Dolev Zemer
    Comment actions Permalink

    Thanks you @Sean Cusick!

    I'll do the required checks.

    do the changes take effect immediately? meaning, after we change the settings, I use the check it pings the DNS on the spot? (sounds like a silly question when I write it down, but just making sure)

    0
  • Sean Cusick
    Comment actions Permalink

    Hi Dolev, That depends on the TTL (Time To Live) value that is set at your domain. Many domains have a default of 86,400 seconds (24 hours) and most do not recommend lowering that value to anything less than 300 seconds (5 minutes). Once your DNS records have been published and propagated then re-clicking the verification button should do the trick. If you have any problems then you may want to open a ticket with us at support@zendesk.com. While we can not troubleshoot your possible DNS issues, but we can verify if the record is being published publicly and assist accordingly. 

    0
  • Henrik Schack
    Comment actions Permalink

    Hi Zendesk

    It looks like you added "include:_spf1.mail.zendesk.com" to the existing SPF record present on mail.zendesk.com yesterday or the day before?
    That has some serious side effects for those of your customers having SPF records already requiring 10 mechanism lookups, they now all have invalid SPF records.
    The count of customers affected is probably in the thousands.

    0

Please sign in to leave a comment.

Powered by Zendesk