Checking DMARC Compliance with Zendesk

Zendesk is the biggest name in customer support software, and because support conversations happen over email, it's almost always a high-volume outbound sender for the domains that use it. Zendesk's default setup sends mail via its own infrastructure, signed with Zendesk's domain — which is fine until you enable DMARC enforcement and suddenly support replies start landing in spam. This guide covers the specific Zendesk steps to pass DMARC.

How Zendesk handles outbound email

Zendesk has three ways to send outbound ticket correspondence:

The default is option 1. Most teams should move to option 2 — it keeps the sending fast and reliable while properly authenticating the messages as coming from your domain.

Step 1: Add your support address in Zendesk

In Zendesk, go to Admin Center → Channels → Talk and email → Email → Support addresses. Add the address customers should see in replies (e.g. [email protected]).

Zendesk will ask you to either forward from this address to a Zendesk-provided address, or to enable SPF, DKIM and DMARC on the external domain. Choose the external domain path.

Step 2: Add Zendesk to your SPF record

Zendesk's recommended SPF include is:

v=spf1 include:_spf.google.com include:mail.zendesk.com ~all

If you already have Google Workspace or Microsoft 365 includes, add the Zendesk include before the mechanism. Check your total lookups with the free DMARC record checker — Zendesk's include counts toward your 10-lookup SPF budget.

Step 3: Enable DKIM signing

In Zendesk, go to Admin Center → Channels → Email → Settings → DKIM (Allow Zendesk to sign outgoing email on my behalf). Zendesk generates two DNS records — typically CNAMEs pointing at Zendesk-hosted keys, or TXT records with the public keys directly:

zendesk1._domainkey.yourdomain.com   CNAME   zendesk1.domainkey.zendesk.com
zendesk2._domainkey.yourdomain.com   CNAME   zendesk2.domainkey.zendesk.com

Publish both and wait for DNS propagation. Return to Zendesk and click Verify. Both selectors should show as active.

Step 4: Verify DMARC alignment

Send yourself a test reply from a ticket. Inspect the raw headers:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=mail.zendesk.com;
  dkim=pass header.d=yourdomain.com header.s=zendesk1;
  dmarc=pass header.from=yourdomain.com

The critical line is dkim=pass header.d=yourdomain.com. That's what makes DMARC align. If DKIM shows header.d=zendesk.com, the external DKIM setup isn't active yet.

Step 5: Review your DMARC record

Once Zendesk is verified, your DMARC record can safely progress to enforcement. A reasonable record:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r

If you need to build one from scratch, dmarccreator.com will walk you through it. Always validate published records in the DMARC record checker.

Common Zendesk DMARC issues

Multi-brand Zendesk setups

Zendesk Enterprise supports multiple brands, each with its own support address and potentially its own domain. Every brand that sends mail from a unique domain needs its own DKIM setup. A multi-brand account with five brands means five sets of CNAMEs.

Forwarding considerations

Some teams forward from [email protected] to a Zendesk-provided address (like yoursub.zendesk.com). This still requires DKIM configuration on the reply side — forwarding inbound doesn't affect outbound authentication. Don't assume that because tickets arrive in Zendesk, the replies are authenticated.

Zendesk Sell and Zendesk Chat

If you use Zendesk's CRM (Sell) or chat product, they have their own email sending configurations separate from Zendesk Support. Each product's admin has its own DKIM settings. Authenticate them all if you use them.

Monitoring ongoing

Once you've got Zendesk aligned, the goal is to keep it that way. Zendesk occasionally rotates DKIM keys — if you published TXT records directly (rather than CNAMEs), you'll need to update them manually when that happens. CNAMEs are safer because they follow the Zendesk key automatically.

deliverabilitychecker.com monitors authentication continuously so a rotation or DNS change doesn't silently tank your support deliverability. Given how visible support replies are to customers, catching breakage early is worth the effort.