Zendesk SPF and DKIM setup

What you are setting up

Zendesk answers tickets from your support address (support@yourdomain.com), which means it sends email as your domain. For that mail to pass DMARC, Zendesk has to sign it with your domain via DKIM. You forward your support address into Zendesk, publish an SPF record and two DKIM CNAMEs, and turn on signing. One ordering rule and one thing Zendesk leaves out (DMARC itself) are where people get burned.

Connect your support address

In Admin Center > Channels > Talk and email > Email, add support@yourdomain.com as a support address, then set your mail provider to forward that address to your Zendesk address (support@yoursubdomain.zendesk.com). Use the row's Verify forwarding option to confirm it; Zendesk only sends as your address once forwarding checks out. Forward from a real mailbox, not a distribution list.

Publish SPF and DKIM

The SPF record (or merge the include into your existing one):

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:mail.zendesk.com -all

Use include:mail.zendesk.com, and keep it in the first lookup of your SPF record (include:smtp.zendesk.com and include:support.zendesk.com are outdated). Then the two DKIM records, which for Zendesk are fixed CNAMEs you can publish exactly as written:

Type:  CNAME
Host:  zendesk1._domainkey.yourdomain.com
Value: zendesk1._domainkey.zendesk.com

Type:  CNAME
Host:  zendesk2._domainkey.yourdomain.com
Value: zendesk2._domainkey.zendesk.com

These are CNAMEs (not TXT) on purpose: Zendesk rotates the signing keys every quarter, and the CNAME indirection means the live key is resolved from Zendesk so you never touch DNS again. Because the selectors live under your domain, Zendesk signs with d=yourdomain.com, which aligns and carries DMARC. SPF authenticates Zendesk's own return-path and does not align, so DKIM is the leg that matters.

Order matters: enable DKIM last. Only after the two CNAMEs resolve, turn on Custom domain for DKIM on that same Email settings page. Zendesk warns, in bold, that enabling signing before the CNAMEs exist causes delivery failures.

Add DMARC (Zendesk will not remind you)

This is the gap worth knowing: Zendesk walks you through SPF and DKIM but never tells you to publish a DMARC record. Without one, you get no reports and no protection on your domain. Add a standard _dmarc TXT and start in monitor-only mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder, watch where your support mail is actually coming from, and progress past p=none when reports are clean.

The Zendesk gotcha

The most common break is forwarding into Zendesk without finishing DKIM. Your replies go out as support@yourdomain.com, but with only Zendesk's non-aligned SPF and no aligned DKIM, so DMARC fails at Gmail and Yahoo and your support replies start landing in spam. Publish the two CNAMEs and enable signing, and remember to do that toggle last. Also note: custom DKIM only applies when you send as your own external domain, mail from a default @yoursubdomain.zendesk.comaddress is already authenticated under Zendesk's own domain and needs none of this.

Confirm it worked

• Check the DKIM CNAMEs. Our DKIM checker confirms both records resolve before you flip the signing toggle.
• Send a test ticket and read the headers. Reply to a ticket from your support address, open the original, and confirm the DKIM signature shows d=yourdomain.com and dmarc=pass. Our header analyzer reads it in plain English.
• Watch the reports. Zendesk should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox so you can tell it apart from anything else sending as your domain.