Verified AI summary ◀▼
By allowing email to be sent on behalf of your domain, you maintain your brand identity in customer communications. Set up an SPF record in your DNS settings to authorize sending emails from your domain. This prevents emails from being flagged as spam and removes the "via" statement in messages.
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
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 attempts to verify this record when you add a support address.
Zendesk recommends using the following SPF record:
v=spf1 include:mail.zendesk.com -all- If you use
include:mail.zendesk.com, then it must be in the first-layer lookup - SPF macros are supported
-
redirect:syntax is supported - Record flattening services will work, though this practice may be less stable than
include:,redirect:, or macro syntax.
-all), which offers the greatest security against email spoofing. An invalid SPF record can cause verification to fail. Seek support from your domain provider, as Zendesk cannot help you administer your DNS or security records and policies.If you've already set up an SPF record for another purpose, 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, combine them into one, like this:
v=spf1 include:_spf.google.com include:mail.zendesk.com -allIn 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
Zendesk auto-verifies this record when you add a support address. It currently does not have a verification function but we may require the value be added to your domain's DNS record in the future.
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. Generally, this helps to prevent emails from your Zendesk account to your customers from being incorrectly marked as spam. However, if you are having this problem, see How can I stop my emails from going into my customer's spam folder?
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?