Allowing Zendesk to send email on behalf of your email domain

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 [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've set up forwarding to an external email address.

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

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 sometime between November 30, 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

Note: While we recommend using ?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 ~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, click here.

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.

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.