Zendesk sends from your own support address once you publish two things: include:mail.zendesk.com in your SPF record and two DKIM CNAMEs, zendesk1._domainkey and zendesk2._domainkey. Then you switch on Custom domain for DKIM in Admin Center, and that has to be the last step. Zendesk's SPF article was last edited on 1 October 2026.
The records at a glance
| Record | Type | Host | Value |
|---|---|---|---|
| SPF | TXT | @ |
v=spf1 include:mail.zendesk.com -all |
| DKIM 1 | CNAME | zendesk1._domainkey |
zendesk1._domainkey.zendesk.com |
| DKIM 2 | CNAME | zendesk2._domainkey |
zendesk2._domainkey.zendesk.com |
| DMARC | TXT | _dmarc |
v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Unlike most vendors, Zendesk uses the same DKIM values for every customer. Nothing here is generated per account.
Before you start
This setup only applies to an external support address, such as help@example.com, that forwards into Zendesk. Addresses on your yoursubdomain.zendesk.com domain are already Zendesk's to send and sign. Zendesk adds that third parties cannot send as any Zendesk subdomain.
DKIM signing with your domain is listed for Suite Team, Growth, Professional, Enterprise and Enterprise Plus, and for Support Team, Professional and Enterprise.
SPF: the include, and why it matters for DMARC
Zendesk's SPF article recommends:
v=spf1 include:mail.zendesk.com -all
Most domains already have SPF for their mailbox provider. Merge, never add a second record. Zendesk's own example:
v=spf1 include:_spf.google.com include:mail.zendesk.com -all
Zendesk's rules for the include are stricter than most:
- It must be in the first layer of lookups, written in your own record rather than nested inside another include.
- SPF macros and
redirect=are supported. - Flattening services work, but Zendesk calls them less stable than a plain include.
- Every other domain in the record must resolve. A dead include elsewhere can break verification.
The SPF record also decides which domain Zendesk sends from. Zendesk says it uses its own domain when it is not authorised and switches to yours once a valid SPF record is in place. That is when the "via zendesk.com" note and the warning next to the support address disappear. Because the envelope then uses your domain, SPF can align for DMARC under RFC 7489.
The include is cheap. On 19 October 2026, mail.zendesk.com held only ip4 ranges and no further includes, so it costs one of your 10 lookups under RFC 7208.
It is also common. In our scan of the Tranco top 1,000 domains on 19 October 2026, 110 domains listed include:mail.zendesk.com, more than for Salesforce (72) or HubSpot (40). Of those 110, 69 publish p=reject. None used the outdated smtp.zendesk.com or support.zendesk.com includes, which Zendesk now flags with a warning.
DKIM: two CNAMEs, then the switch
Add both records at your DNS host:
zendesk1._domainkey.example.com. CNAME zendesk1._domainkey.zendesk.com.
zendesk2._domainkey.example.com. CNAME zendesk2._domainkey.zendesk.com.
Zendesk rotates its DKIM keys every quarter. The CNAMEs follow the rotation, so you never edit them again. Brevo's domain is one live example: on 19 October 2026 zendesk1._domainkey.brevo.com pointed straight at zendesk1._domainkey.zendesk.com.
Zendesk says DNS changes take anywhere from a few hours to a day, depending on TTL. Only after both names resolve:
- Open Admin Center.
- Click Channels in the sidebar, then Talk and email > Email.
- In Email settings, select Custom domain for DKIM.
- Click Save.
Zendesk's warning is unusually direct: enabling this before the CNAMEs exist causes delivery failures. Receivers see a signature for example.com with no key to check it against.
With the setting on, signatures carry d=example.com, which aligns with your support address. You then have two aligned passes, SPF and DKIM.
DMARC
Zendesk does not publish a DMARC value for you. If you already have a record for your mailbox provider, leave it alone. Zendesk mail joins the same reports. If you have none, start at p=none with an rua address and use the DMARC generator.
Pitfalls specific to Zendesk
- Order of steps. CNAMEs, wait, check, then the Admin Center switch. Never the reverse.
- Gmail connector. If agents reply through the Zendesk Connector for Gmail, Zendesk calls SPF recommended but not required.
- Several support domains. Each external domain needs its own SPF include and its own pair of CNAMEs.
- Doubled names. Hosts that append the zone turn
zendesk1._domainkey.example.comintozendesk1._domainkey.example.com.example.com. Type onlyzendesk1._domainkeythere.
Check the result
- SPF checker:
include:mail.zendesk.comshould be at the top level, with a lookup count under 10. - DKIM checker: run it for
zendesk1, thenzendesk2. - DMARC checker: one record at
_dmarc.
Then create a test ticket from a Gmail address and reply as an agent. In Show original on the reply, look for spf=pass and dkim=pass for example.com, and dmarc=pass. If the From line still says "via zendesk.com", Zendesk has not picked up your SPF record yet.