You can set up your email domain to verify that Zendesk can send email on behalf of your email server.
For example, if you receive email from your customers at help@acme.com, and you've set up an automatic redirect to forward all email received there to Support, you can authorize Zendesk to send out notifications as if it originated from your own email address (for example: help@acme.com). That way you can preserve your branding throughout the entire process.
You don’t have to configure your email domain this way, but it’s recommended if you've set up forwarding to an external email address.
The advantages of this configuration
So, do you have to allow Zendesk to send email on behalf of your email domain? The short answer is: No. The slightly longer answer is: Only if you really don't want your customers to see the Zendesk name on their messages.
When Zendesk sends an email message using your email address (which is what happens if you've set up a support address with forwarding) the message identifies the sender as zendesk.com to avoid getting rejected. However, if you allow Zendesk to send email on behalf of your email domain, Zendesk stops sending messages from zendesk.com, and sends them from your domain, completely preserving your branding.
If you don't complete the tasks described in this article, your customers might see something like this:
The following warning will also appear in the agent interface next to your external support addresses:
However, if you complete the tasks described this article, the via statement and warning don’t appear.
Upcoming changes to the authorization process
Soon, the way that you authorize Zendesk to send email on behalf of your email domain will change. You should continue using your SPF record for now, but you should also complete the preparation work described in Setting up CNAME records to avoid disruptions.
Zendesk products are currently hosted in redundant data centers around the world. Soon, that will change and Zendesk products will be hosted on Amazon Web Services (AWS) instead. As a result, the way that you allow Zendesk to send email on behalf or your email domain will also change.
Current process
Currently, when you want to allow Zendesk to send email on behalf of your email domain, you must have an SPF record on your DNS server.
If you’re an existing customer, you may have this set up already. If you’re a completely new customer setting up Support for the first time, and you want to allow Zendesk to send email on behalf of your email domain, you must still add an SPF record—you can’t just skip this task because things are changing.
New process
Soon you won’t need an SPF record anymore. Instead, you’ll need four CNAME records that will reference our SPF records. It’s a good idea to set these up in advance, if possible. If you don’t do this before the email sending methods change for your account, and prepare for the change, emails to your customers will start coming from an email address that includes zendesk.com in the name. The emails might come from an address like support@yourcompanyname.zendesk.com, for example.
Once you add the CNAME records to your DNS server, you’ll be ready, but you’ll continue to use your SPF record until your account’s email sending methods have changed. Don’t remove the old SPF record from your DNS server yet.
The way emails are sent for your account will change sometime between October 31, 2018 and January 1, 2019. Unfortunately, you won’t get advanced notice about when exactly your account will change to use the new email sending service. This is why it’s important to make the required changes as soon as possible to avoid disruption.
Before we can start sending emails using the new service, you’ll get an email notification. Amazon Web Service (AWS) requires verification before they will send emails on behalf of another email. This takes the form of an email with a verification link.
Once your account is sending emails using our new service, you can remove your old SPF record. You won’t need it at that point.
Setting up records for your domain
Ideally, the tasks in this section are things that you’d get help with, if you can, or that you’d ask your system administrator to do for you.
Setting up an SPF record
If this is the first time doing this task, keep in mind that you should also set up your CNAME records when you’re done.
The process of setting up an SPF record is different for different domain registrars. For example, here are the instructions for GoDaddy, Namecheap, 1&1, Network Solutions, and Google Domains.
To create or edit an SPF record to reference Zendesk
- Edit your domain's DNS settings to add a TXT record. The steps vary depending on your domain registrar.
Zendesk recommends using the following SPF record:
v=spf1 include:mail.zendesk.com ?all?all because it's the least intrusive qualifier, you can use use whichever qualifier you are comfortable with.If you've already set up an SPF record for another purpose, you can simply add a reference to Zendesk to it. The SPF specification requires that you only have one SPF record on your domain, if you have multiple records, it may cause issues, and cause rejections of your email.
For example, instead of having two separate records, such as v=spf1 include:_spf.google.com ~all and v=spf1 include:mail.zendesk.com ~all, you can combine them into one, like this:
v=spf1 include:_spf.google.com include:mail.zendesk.com ~allinclude:smtp.zendesk.com and include:support.zendesk.com. These are both outdated SPF records. While they might still work, they're not the best option. If you're still using them, you'll see a warning flag indicating you've set up an outdated record.Setting up CNAME records
Try to complete this task before the change the authorization process occurs.
CNAME (Canonical Name) records allow you to delegate domain level email authorization to Zendesk. This means that Zendesk can maintain SPF records for a subset of email delivered from your domain, and ensure that they're always up-to-date.
With the new authorization process, the receiving email server will attempt to perform an SPF check, meaning the email server checks the SPF record on your DNS server by looking up the envelope-from address in the DNS.
Your CNAME records will redirect the SPF check mail*.zendesk.com. This is a Zendesk server that includes an SPF record that is maintained by Zendesk. This SPF record is used for mail sent from zendesk*.customer.com.
To authorize Zendesk to deliver your email using CNAME records
- Edit your domain's DNS settings and add each of these CNAME records:
| Type | Name / Host / Domain | Value / Target / Destination | TTL |
|---|---|---|---|
| CNAME | zendesk1 | mail1.zendesk.com | 3600 or use default |
| CNAME | zendesk2 | mail2.zendesk.com | 3600 or use default |
| CNAME | zendesk3 | mail3.zendesk.com | 3600 or use default |
| CNAME | zendesk4 | mail4.zendesk.com | 3600 or use default |
If you're unsure about any of the above, consult with your DNS provider.
For more information concerning this transition to Amazon SES, click here.
Understanding SPF checks
Sender Policy Framework (SPF) is a domain level email authorization protocol that allows you to declare which Simple Mail Transfer Protocol (SMTP) servers, other than your own, are allowed to send email as if it originated from your domain.
This is accomplished by adding Domain Name System (DNS), TXT, or CNAME records. Think of DNS as a publicly accessible record for the internet. These records enable you to state publicly that Zendesk is an authorized sender for your domain.
When an email client receives a message, it performs an SPF check on the sending domain to verify that the email came from who it says it did. If this check fails, or there isn't a DNS record that says that Zendesk is a permitted sender, some receivers might consider that email spam or a phishing attempt, and flag it as untrustworthy or not display it to your customers at all.
Zendesk avoids this by sending email using our own domain when we're not authorized to use your domain, and by using your domain only when you authorize Zendesk with a proper SPF record. Either way, email sent from Zendesk should never be marked as spam.
If you're curious, you can read more about SPF at www.openspf.org.
Comments
53 comments
1) Does Zendesk have a DKIM option?
2) how long does it take for the TXT record to update and be effective?
1) Yes! https://support.zendesk.com/hc/en-us/articles/203663326
2) It should be based on the "TTL" or time to live of your record. If you don't see it in a day or so (keep using the retry link to update), let our support team know.
I added the record, it says SPF record is valid in the admin panel but users still get via Zendesk in their reply emails.
Anything I can do to troubleshoot it?
Hi Eugene!
Where in the email is it saying this? I need to know what part of the communication we're dealing with in order to be able to answer your question.
(Guessing..) I think what Eugene is seeing is a "via ... zendesk.com" to the right of the From address, at least Google displays the From address in that manner if the From address differs from the Sender envelope address.
Once you create the SPF record what changes do you make in Zendesk to trigger your emails to be send via your domain?
Hey Isaac,
As long as you have your Support Addresses set up, you won't need to do anything else!
Perhaps this article could be updated… Whilst adding Zendesk to your SPF will ensure that your customers receive Zendesk emails posing as your domain, employees of your domain may not receive these type of emails from Zendesk until you have authorised your mail server to accept them. This is because SPF may not the only method of authorisation required e.g. our Exchange mail server required an additional 'Receive Connector' to be setup to accept emails that were sent from Zendesk using our domain name. Without this step in place tickets were shown in a suspended state with error: “550 5.7.1 Client does not have permissions to send as this sender”
If you already have a SPF record for your domain, you should not create a new record for Zendesk because multiple SPF records are not allowed. Instead, add 'include:mail.zendesk.com' to your existing SPF record.
The article recommends using '?all', but that makes SPF almost useless.
You should not rely on SPF or DKIM alone for email authentication.
Deploy DMARC and then -all ~all or ?all doesn't really matter, as only a SPF PASS makes the email pass DMARC.
Hi Chris - the ?all portion is up to you, as long as you have the proper entry for Zendesk it will work in regards to our system. I think we recommend ?all because it is the least intrusive, but you are free to use your preference.
v=spf1 include:_spf.google.com include:mail.zendesk.com ~all
I have updated the mentioned SPF Records. I am still being warned to verify the SPF records.
Hey Neeraj!
If you're still getting the warning message, most likely the settings aren't quite right in your DNS settings. The right way to do this is going to vary depending on what service you're using...have you checked any support documentation your DNS provider has?
I am using Office 365 and Godaddy. I have added
v=spf1 include:spf.protection.outlook.com include:mail.zendesk.com -all
Office 365 shows all good, but I can't verify the spf record in Zendesk
Hi Jonathan - I'll make a ticket for you and we can troubleshoot there. Please keep an eye out for my notification in your inbox.
I'm getting the same result as Jonathan.
Hey Adam!
It looks like Jonathan changed ?all to -all and that took care of his issue! If that doesn't solve the issue for you, I'd recommend submitted a Support ticket (if you haven't already done so) so we can take a look at it.
We are very thankful for the updates to this and other articles.
We were able to successfully set this up with one very big exception -- for tickets that are created by an agent (Customers calling us) we are seeing that Zendesk still uses a Zendesk email.
Is this some sort of default? How do we change this. Thank you so much!
Hey Heather!
That would mean your default support address is still an internal support address @yourdomain.zendesk.com. You will want to change that by Going to Admin >> Channels >> Email.
From there, You will Hover over the support address you'd like to make your default address to make the change (on the right side)
HERE is a tech note on it as well.
Thanks @Ryan! Now I understand!
I am hoping at some point in the future we can select what address Zendesk uses depending on different factors. We have multiple divisions here using the tool who would like their own default email....
Hi all - I'm still seeing an SPF warning for our configuration, and can't seem to fix it. The following is the current configuration:
'''
[togume:~] $ dig whitetalecoffee.com TXT +short
"v=spf1 include:_spf.google.com include:mail.zendesk.com include:shops.shopify.com ~all"
'''
Any support would be helpful. Thanks!
What sort of warning? It's a valid SPF record.
The Dmarcian.com SPF Survey tool is really great. : https://dmarcian.com/spf-survey/
Hi Tomas / Henrik, The record appears to be present and populated now for whitetalecoffee.com. Some domains employ a 24 hour TTL before a record becomes published publicly. If you click SPF Retry within Channels>>Email>>Support Addresses>>address in questions and it is still not verifying then please open a ticket at support@zendesk.com and we'll be happy to investigate further.
@Henrik - thanks for the reply, and for the tool! Yes - I was fairly certain that it was a valid record.
@Sean - aha! Bingo. I'd set up the SFP entry a long time ago, and today I was poking with some configurations when I came across the warnings. A manual retry cleared the warnings. I didn't even think of that; figured that it would have been cleared on its own :).
All good on this end. Thanks!
hi,
The ? should be ~ it took me a while to notice why the TXT record wasn't working, maybe edit the document to make it look like :
Kind regards Tina
Hi Tina!
The Qualifier can be either actually!
It's all dependant on what you're comfortable with, and what behavior works for you. We use the ? (neutral) qualifier so its neutral and won't cause any unexpected failures to people who are unaware of the difference. Using ~ means the SPF record has designated the host as NOT being allowed to send but is in transition -- While usually not a problem, we cannot account for every situation (or behavior that fits your workflow or servers), hence the neutral being used in its place (as a general recommendation).
But again, we allow the use of any qualifier, and any valid SPF syntax, so whatever works for you, go with (as long its in line with SPF specifications that is).
For more information on the Qualifiers themselves, Open SPF is a great resource:
http://www.openspf.org/SPF_Record_Syntax
Hello,
How can I remove the zendesk word from this support@smartsmileapp.zendesk.com ? I would like it to become like this support@smartsmileapp.com . Anyone here please help me.
Thanks
If you have control of your mail server (where emails to @smartsmileapp.com land), you can setup a forward to support@smartsmileapp.zendesk.com
Hello Simon,
Thank you so much for your reply. Basically my boss just wants to make sure our customer will not see our published email as support@smartsmileapp.zendesk.com but just support@smartsmileapp.com only. So he just want me to take the zendesk out of that email.
Please sign in to leave a comment.