If you want to use your own email address to receive support requests, and you've added your email address as a support address in Zendesk, then 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 in this article, the via statement and warning don’t appear.
Setting up records for your domain
Ideally, the task in this section is something you’d get help with, if you can, or that you’d ask your system administrator to do for you. You will need to set up an SPF record and a separate DNS TXT record (as described in Verifying your domain). Make sure you do both.
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. A TXT record is required for your SPF record to be validated.
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
In the past, Zendesk suggested alternate formulations for SPF records, including 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.
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 SPF record, 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 an example.
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. If you're having trouble setting up your DNS record correctly, see Why do I receive the error "DNS records are not set up correctly" when verifying my DNS records.
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 IP addresses are allowed to send email as if it originated from your domain.
This is accomplished by adding Domain Name System (DNS) TXT record. Think of DNS as a publicly accessible record for the internet. This record enables 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?
152 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.
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.
Yes, of course; you will want your customers to continue to send to support@smartsmileapp.com
Ensure that the server that handles mail for your domain, is setup to forward those mails to your support@smartsmileapp.zendesk.com
Also ensure that reply emails that are sent from Zendesk (from your support agents), send 'as' support@smartsmileapp.com
If your mail domain is protected against spoofing (where you authorise specific servers to send 'as' your domain) you will also have to update the protection to allow Zendesk servers.
SPF is one type of protection that is discussed above.
This is important because many (not all yet) customer email systems may perform checks as part of their anti-spam protection. Those that do will more than likely not receive your support agents’ replies from Zendesk unless protection is updated correctly.
My organisation has an on premise Exchange server that works with this scenario and is secured as much can be. Thus the components of our Exchange server (receive connectors) required similar action (add Zendesk mail sending server IP’s) to authorise Zendesk’s emails, posing as our domain, to arrive in our own support agents or sales employees mailboxes.
Bear in mind that if your mail server is inaccessible, it cannot receive or forward mails from your customers. Zendesk itself is quite resilient, in many cases, more so than some of its customer’s mail platforms. But it depends on each scenario. Research, plan and test where you can. Good luck.
Please sign in to leave a comment.