Lookproof Browse tools

DMARC, SPF and DKIM for Zendesk

Updated 2026-11-06

Zendesk is a help desk, not a mailbox provider. Customers write to an address such as [email protected], your mail server forwards it to Zendesk, and Zendesk sends the replies and notifications. For those replies to carry your own domain, you authorise Zendesk with SPF and DKIM at your DNS host. This guide follows the Zendesk help centre articles on SPF, DKIM and email deliverability. For the background on each standard, see SPF explained, DKIM explained and DMARC explained.

What Zendesk sends from

Zendesk sends outbound mail from its own servers. Which domain it uses depends on whether you have authorised it.

  • Not authorised. Zendesk says that when it sends with your address and has no authorisation, "the message identifies the sender as zendesk.com to avoid getting rejected". Recipients may then see a "via" statement, and the agent interface shows a warning next to the external support address.
  • Authorised with SPF. Once your SPF record includes Zendesk, "Zendesk stops sending messages from zendesk.com, and sends them from your domain". Zendesk checks the SPF record when you add a support address.

The help centre does not name the envelope sender (Return-Path) domain explicitly. What it does say is that Zendesk uses "your domain only when you authorize Zendesk with a proper SPF record", and that the SPF record goes on your own domain. The articles describe no custom bounce subdomain and no separate MAIL FROM record to publish.

For DKIM, Zendesk's article on the authenticated SMTP connector refers to "our d=zendesk.com DKIM tag". That suggests Zendesk signs with its own domain until Custom domain for DKIM is on; check the d= value in a test message. After you add the CNAME records and turn on digital signatures, Zendesk signs "on your behalf" with d=yourdomain.com.

Two cases fall outside this guide. System addresses such as [email protected] are authenticated by Zendesk "by our own authority" with SPF and DKIM. If you use the authenticated SMTP connector, your own mail server does the final sending, and Zendesk will not add its d=zendesk.com signature; SPF then belongs to your mail service.

SPF

Publish one TXT record on the domain of the support address (host @ at most DNS hosts). As of November 2026 Zendesk's documented value is v=spf1 include:mail.zendesk.com -all. We recommend the same record with ~all:

example.com TXT "v=spf1 include:mail.zendesk.com ~all"

Zendesk adds some notes to this record, as of November 2026:

  • include:mail.zendesk.com "must be in the first-layer lookup". In our reading, that means putting it directly in your domain's record; Zendesk does not say how this applies to redirect.
  • SPF macros and the redirect modifier are supported. Flattening services work, but Zendesk calls them "less stable".
  • Every other domain in the record must be valid and resolve, or verification can fail.
  • Zendesk recommends hardfail (-all). Another Zendesk article also shows ?all as an option, "depending on the domain needs". Prefer ~all. RFC 9989 warns that some receivers check SPF early in the SMTP transaction, so -all can get mail rejected before DMARC runs, even when aligned DKIM would have passed it. That mail never appears in your aggregate reports.

A domain may have only one SPF record. Zendesk says multiple records "may cause issues, and cause rejections of your email", and shows how to merge them. A typical setup with Zendesk plus another service looks like this, where _spf.example.net stands for that other service's include:

example.com TXT "v=spf1 include:mail.zendesk.com include:_spf.example.net ~all"

That record uses 2 DNS lookups itself. Each include then adds the lookups inside its own record. Zendesk does not document a number for include:mail.zendesk.com. When we counted it with real DNS on 7 November 2026, the mail.zendesk.com record held only IP ranges, so it cost 1 lookup in total. The outdated include:smtp.zendesk.com and include:support.zendesk.com each cost 2. Zendesk can change these records, so count your whole tree with the SPF lookup counter. RFC 7208 sets the limit at 10 lookups; above that, SPF returns a permanent error (too many SPF lookups).

Older Zendesk advice used include:smtp.zendesk.com or include:support.zendesk.com. Zendesk now calls both outdated. Zendesk notes that DNS changes for SPF can take up to 48 hours to be recognised.

DKIM

Zendesk hosts the keys. You publish two CNAME records that point to them, then switch signing on. Zendesk says it rotates its DKIM keys every quarter, and with CNAME records you do not need to change anything when that happens. It does not document the key length.

As of November 2026 the documented records are:

zendesk1._domainkey.example.com CNAME zendesk1._domainkey.zendesk.com
zendesk2._domainkey.example.com CNAME zendesk2._domainkey.zendesk.com

The docs write the host as zendesk1._domainkey.your_email_domain.com, where your_email_domain.com is the external domain you use for Zendesk mail. Repeat both records for each external domain.

Steps, as documented:

  • At your domain registrar or DNS host, open the DNS management page.
  • Add a CNAME with host zendesk1._domainkey.example.com and target zendesk1._domainkey.zendesk.com.
  • Add a second CNAME with host zendesk2._domainkey.example.com and target zendesk2._domainkey.zendesk.com.
  • Wait for DNS. Zendesk says this "can take anywhere from a few hours to a day".
  • In Admin Center, click Channels in the sidebar, then select Talk and email > Email (as of November 2026).
  • In the Email settings section, select Custom domain for DKIM and click Save.

Zendesk insists that the last step, enabling signing, comes after the DNS records. DKIM signing is only supported when you use an external email domain with Zendesk. Zendesk has no built-in validator for the records; it points to third-party tools.

DMARC alignment

DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From domain.

  • SPF alignment compares the RFC5321.MailFrom (Return-Path) domain with the From domain. Zendesk does not name the Return-Path domain. It asks for the SPF include on your own domain and says it sends from your domain once authorised. Confirm the Return-Path in the headers of a test message before you rely on SPF alone.
  • DKIM alignment compares the d= domain with the From domain. Zendesk's SMTP connector article refers to "our d=zendesk.com DKIM tag", which suggests Zendesk signs with its own domain until Custom domain for DKIM is on. Such a signature would not align with example.com; check d= in a test message. After setup Zendesk signs with d=yourdomain.com, which aligns.

Relaxed alignment, the default, only needs the same organisational domain, so support.example.com aligns with example.com. Strict alignment needs the exact same name. A d=example.com signature on mail From: [email protected] passes in both modes.

DKIM is the part you can verify from the docs, so set it up before any strict policy. Zendesk's troubleshooting article gives the same order: start at p=none, and move to p=quarantine or p=reject only after all legitimate mail, "including those sent from Zendesk", authenticates.

Step by step to p=reject

  1. Publish SPF. Zendesk says "you must add your email address as a support address in Zendesk before proceeding", so add the address first. Then add one TXT record on example.com that contains include:mail.zendesk.com directly, merged with the includes of every other service that sends as your domain. Keep the whole tree at 10 DNS lookups or fewer.
  2. Publish the DKIM CNAMEs and enable signing. Add zendesk1._domainkey and zendesk2._domainkey as CNAMEs to the same names under zendesk.com. When both resolve, select Custom domain for DKIM in Admin Center and save.
  3. Start DMARC at p=none with reports. Publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. This policy does not protect the domain yet; it only turns on aggregate reports.
  4. Read the reports and fix other senders. For two to four weeks, check which servers send as your domain. Confirm that Zendesk mail passes DKIM with your domain, and give every other legitimate service SPF and DKIM for your domain.
  5. Move to quarantine. Change the policy to p=quarantine once reports show only aligned mail from your own services. Failing mail usually lands in spam, so a sender you missed can still be recovered.
  6. Reject. Change the policy to p=reject when the reports stay clean. Receivers then refuse mail that fails DMARC.

The record for step 3:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The final record:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Zendesk does not publish a DMARC record for you and says it cannot advise on domain security settings. The record lives in your own DNS.

Common mistakes

  • Enabling DKIM before the CNAMEs exist. Zendesk warns this "will cause delivery failures". Add both records, wait for DNS, then switch it on (DKIM not found).
  • Two SPF records. Zendesk says the SPF specification allows only one per domain. Merge Zendesk into the existing record (multiple SPF records).
  • Zendesk include nested too deep. Zendesk requires include:mail.zendesk.com in the first-layer lookup, which in our reading means directly in your domain's record, not inside another include.
  • Outdated includes. include:smtp.zendesk.com and include:support.zendesk.com trigger a warning in Zendesk. Replace them.
  • Staying at p=none. p=none only collects reports. Move on once the reports are clean (DMARC policy none).
  • Relying on a test flag. Some receivers support t=y (RFC 9989, DMARCbis) or pct (RFC 7489). Neither is a safety net. RFC 7489 says unknown tags must be ignored, so a receiver that implements only RFC 7489 can treat p=reject; t=y as a full reject. Let the reports decide each step.

How to check it

Run the email security check on your domain to read SPF, DKIM and DMARC in one pass. Use the SPF lookup counter to count every lookup behind include:mail.zendesk.com and your other includes. In the DKIM selector finder, look for the selectors documented as of November 2026: zendesk1 and zendesk2; each should resolve through its CNAME to a key under zendesk.com. Build or check your policy with the DMARC record generator.

Sources

Frequently asked questions

What SPF record does Zendesk recommend?

As of November 2026 Zendesk's own record is v=spf1 include:mail.zendesk.com -all, as a TXT record on the domain of your support address. We suggest ~all at the end instead (see the SPF section). If the domain already has an SPF record, add include:mail.zendesk.com to it instead of publishing a second record.

Which DKIM selectors does Zendesk use?

As of November 2026 Zendesk documents two selectors, zendesk1 and zendesk2. You publish two CNAME records: zendesk1._domainkey.example.com pointing to zendesk1._domainkey.zendesk.com, and zendesk2._domainkey.example.com pointing to zendesk2._domainkey.zendesk.com.

When should I turn on Custom domain for DKIM?

Only after both CNAME records resolve. Zendesk warns that enabling digital signatures before the CNAME records exist "will cause delivery failures".

Are the old includes smtp.zendesk.com and support.zendesk.com still fine?

Zendesk calls both outdated. They might still work, but Zendesk shows a warning flag for them. Replace them with include:mail.zendesk.com.