You can set up your custom 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 use your own custom email domain and have set up forwarding to an external email address. If you use a non-custom domain, such as addresses ending in @gmail.com or @yahoo.com, you can't use this feature, as you won't have access to the account DNS settings.
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.
We will be changing the way emails are sent from your account in the future. 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. A TXT record is required for your SPF record to be validated. 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 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 ~all
include: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.
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, see Sending Zendesk email from Amazon SES servers.
Verifying your domain
In order for Zendesk Support to send emails on your behalf, you must verify that you own the domain that you want Support to use. This is done by adding a TXT record (a domain verification record) to your DNS server that Support will check. The domain verification record is unique for each Support account and domain combination.
If you don’t add the domain verification record, Support sends emails from a Zendesk-provided email address. If you want to give your customers a white label experience, hiding all Zendesk branding, you must add this record.
To verify that a domain belongs to you
- After you have finished setting up your CNAME records, go to Support and click the Admin icon (
) in the sidebar, and then navigate to Channels > Email.
- Locate the DNS records (located outside of Zendesk) for your Support address, then click See details to see the domain verification value. See the illustration below for details.
Note: If you are an agent with permissions to manage support addresses, you can use the Support Addresses API endpoint to find the domain verification code for your support address instead, if you prefer. Look for the domain_verification_code value. For more information, see the developer documentation about Support Addresses.
- Edit your domain's DNS settings and add this TXT record:
Type Name Value TTL TXT zendeskverification <your unique value found in Support> 3600 or use default You can find the value next to the Domain verification TXT record check. In this example, the value is abcdef123456:
- After you add the TXT record, click the Verify DNS records button to confirm that all of your records are now valid. If they are, the red error messages will be gone.
After your domain is verified, leave the domain verification record in-place.
If you decide to change your Support subdomain or host mapping later, you don’t need to update your domain verification records.
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. If you're having trouble verifying your SPF record, see Why is my SPF record not validating?
136 Comments
+1 @Mike Purcell
Hey Mike,
You'll want to take a look at the following article but I've gone ahead and copied the relevant information over for you as well: Sending Zendesk email from Amazon SES servers
If you have any questions or problems, open a support ticket at support@zendesk.com account and grant temporary access to your account, so Zendesk can see what you are seeing.
Hope the above helps!
We are hosted on AWS and within the Route 53 console I have followed the instructions with regard to the SPF settings such that I have entered the following as TXT (not as an SPF as recommended on this board above)
v=spf1 include:mail.zendesk.com ?all"
However, nowhere in the information posted above here:
https://support.zendesk.com/hc/en-us/articles/203683886#topic_w5x_3tp_l2b
does it say what value to enter as the "Name" when you are entering the above TXT entry per the screenshot below.
What do you insert for "Name"?
Hi Max,
Can you shine a light on this:
Feature Request - Fail SPF record validation on too many SPF lookups
- Kay
So how will we know WHEN we can remove the SPF and the TXT validation entries in DNS?
Hi Forrest, we recommend that you subscribe to the Zendesk Announcements page, where all information concerning Amazon SES account migration completion will be posted: https://support.zendesk.com/hc/en-us/sections/200623776-Announcements
Done,
But why would we not expect that the exact Article telling us Why were were making the changes to conform with Zendesk feature changes to reflect the updates and timing. I already Follow this Article because it was what I was told to follow to ensure I was in compliance. I get enough e-mails regarding updates, and was softly scolded:
"We noticed that despite multiple attempts to alert you of this important change, your account has not yet been updated.This article explains those changes and what action you should take in preparation. These changes must be completed byApril 30, 2019 to prevent any changes to the way your customers receive emails from you."
However, I found no evidence of previous contact regarding the changes or lack of action on my part.
Can you please try to consolidate the information and documentation to a single place?
In my estimation I have spend about 20 hours of my time ensuring all of my records are in place and configured properly. I would like to stop worrying about when the transition is complete.
If this article says the change from SPF to CNAME records is may 13 2019, then why now, end of august 2019 does it still complain for SPF records when setting up a new zendesk? Shouldn't it only care about the new setup going forward?
Also, our current spf1 record is so convoluted due to our services and newsletters, than adding anything for zendesk is going to thoroughly hose the entire thing.
Hey Randall,
I'm going to bring this into a ticket so our Customer Advocacy team can take a look for you. You'll receive an email shortly stating your ticket has been created.
Feel free to attach any additional information you can provide to the ticket.
Cheers!
Hi,
Do you still need to do the SPF record set up?
Best regards
Hello Caroline,
Yes, you will still need to do the SPF record set up for the time being.
Best regards!
Hi,
Have a customer that has set up there own Zendesk instance to communicate with their customers and they have also setup in DNS so they can use "send on behalf" with there domain with SPF, CNAME and TXT-record zendeskverification value from their Support.
Now we should help them with some support regarding their suppliers and some other questions. They don't want to mix the questions in their instance so we have setup our own Zendesk-instance for these issues.
Is it possible for us to "send on behalf" the customers domain, from our instance. I guess when we configure email channel we will get another value for zendeskverification. Is it possible to have multiple values for this TXT-record in DNS?
Best regards
Hey Håkan,
According to the above documentation, you can have multiple TXT records set up. However, you'll want to use the following format: v=spf1 include:_spf.google.com include:mail.zendesk.com ~all
Let me know if I'm misunderstanding your question.
Cheers!
Hi Brett,
Sorry my question was regarding the section Verifying your domain and the TXT record zendeskverification that has to be created in that section, if our customer has the possibillity to create multiple record in their DNS, one for their domain verification code in their instance and one code from our instance that we think will be another code.
Maybe it not possible to do that, and we have to use the supportaddress from our instance in our communication with the customers suppliers?
Best regards
Håkan
Hey Håkan,
I confirmed with one of our Email experts and they stated that since the verification isn't an SPF record, you should be able to have multiple TXT records without any negative effects.
Let me know if you experience anything different on your end!
Zendesk products will be hosted on Amazon Web Services (AWS) ?
Please sign in to leave a comment.