Allowing Zendesk to send email on behalf of your email domain

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 [e-mail], 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: [e-mail]). 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 DNS settings.

Note: If you use the Google Connector to enable automatic ticket creation, you do not need to set up an SPF or CNAME to allow Zendesk to send email on your behalf. You can read more about this here.

This article includes these topics:

• The advantages of this configuration
• Upcoming changes to the authorization process
• Setting up an SPF record
• Setting up CNAME records
• Verifying your domain

Related articles:

• Sending Zendesk email from Amazon SES servers
• Announcing Zendesk's cloud migration to Amazon Web Services (AWS)

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 [e-mail], 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 starting in January 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

Note: While we recommend using ?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

Important: 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.

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, see Sending Zendesk email from Amazon SES servers.

Tip: Consider making an additional update to digitally sign outbound email from Zendesk to prevent your customers' email clients from blocking email. Digitally signing email provide that an email actually came from your organization and not someone pretending to be your organization. For instructions, see Digitally signing your email with DKIM or DMARC.

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

1. 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.
2. Find the domain verification value under Verifications for your Support address.
3. 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 abcd1234:

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.