Email authentication for Zendesk: SPF, DKIM and DMARC

24 April 2026 · 11 min read

Zendesk is one of the trickiest support platforms to authenticate properly, and it catches a lot of teams out. The reason is specific and worth understanding before you touch DNS: Zendesk sends email from your support address (for example support@yourdomain.com) but it does not let you set a custom Return-Path. The envelope sender stays on a Zendesk-owned domain. That single design choice means SPF will authenticate, but it will not align, so SPF on its own can never make Zendesk traffic pass DMARC. DKIM is the path that actually works, and you have to configure it deliberately.

This guide walks through the exact records, the real selectors Zendesk uses, the order of operations that prevents a delivery outage, and how to get Zendesk traffic passing DMARC so you can safely move your domain to p=reject.

How Zendesk sends your email

When an agent replies to a ticket, or a trigger fires an automated notification, Zendesk relays the message through its own mail infrastructure. The visible From header shows your support address, because that is what your customers should see and reply to. But two technical headers tell the real story:

• The Return-Path (envelope MAIL FROM, the address SPF actually checks) is set to a Zendesk-controlled domain such as support.zendesk.com or a bounce domain on *.zendesk.com. Zendesk owns the bounce processing, so it keeps the envelope on its own domain.
• The DKIM signature, if you have not configured anything, is signed with a Zendesk selector on a Zendesk domain (d=zendesk.com or similar), not your domain.

DMARC does not care that SPF passes or that a DKIM signature is valid. It cares about alignment: the domain that authenticated must match the domain in the visible From header. So:

• SPF result: Zendesk's envelope domain is in Zendesk's SPF record, so SPF passes for the envelope. But because the envelope domain (*.zendesk.com) does not match your From domain (yourdomain.com), SPF is not aligned. DMARC ignores it.
• DKIM result: if Zendesk signs with d=zendesk.com, that does not match your From domain either, so DKIM is also not aligned.

With nothing configured, Zendesk mail can fail DMARC outright. That is exactly why you cannot skip DKIM here. Unlike many senders where adding an SPF include is enough, Zendesk's locked Return-Path makes DKIM the only mechanism that can produce an aligned pass. Get DKIM right and DMARC alignment follows; get it wrong, or skip it, and your support email breaks the moment you enforce.

The mental model that saves you: for Zendesk, DKIM is not optional and it is not a nice-to-have for deliverability. It is the one and only mechanism that will carry your DMARC alignment. Plan around that.

Step 1: add Zendesk to your SPF record

Even though SPF will not align, you should still add Zendesk to SPF. SPF still influences spam scoring and some inbound filters, and several Zendesk notification paths benefit from it. The mechanism Zendesk publishes is:

include:mail.zendesk.com

You must not create a second SPF record. A domain is allowed exactly one v=spf1 TXT record; publishing two produces a permanent SPF error (PermError) and breaks SPF for every sender on the domain, not just Zendesk. Instead, merge the include into your existing record. If you already send through Google Workspace, a typical combined record looks like this:

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

Two things to watch:

• The 10 DNS-lookup limit. SPF allows a maximum of ten DNS lookups across the whole record, including everything pulled in by nested includes. include:mail.zendesk.com expands to further lookups, and stacking several providers tips you over the limit, which also produces PermError. If you are close to the edge, flattening is the fix. See how SPF flattening works and our hosted SPF product, which keeps a flattened record updated automatically as providers change their IPs.
• Your all qualifier. Keep -all (hard fail) once you are confident every legitimate sender is listed. If you are still discovering senders, ~all (soft fail) is a safer interim setting.

Before and after you change anything, confirm the record parses and stays under ten lookups with the SPF checker. It will show you the expanded lookup count so you know whether mail.zendesk.com pushed you over.

Set your expectations correctly here: a clean SPF record is good hygiene, but it will report SPF: pass, alignment: fail for Zendesk mail in your DMARC reports. That is normal and expected. DKIM does the real work.

Step 2: publish Zendesk's DKIM CNAME records

This is the important part. Zendesk uses two selectors and rotates the underlying keys, so you publish two CNAME records that point back to Zendesk. Because they are CNAMEs, Zendesk manages the actual public keys for you, and key rotation happens on their side without you needing to touch DNS again.

Replace yourdomain.com with your real external email domain and create:

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

A few specifics that trip people up:

• They are CNAME records, not TXT. A common mistake is to paste the target into a TXT record. If your DNS host shows the value with a trailing dot, keep it; if it does not, do not add one. Match your provider's convention.
• Do not flatten or proxy these. If your DNS is behind a CDN or proxy that lets you toggle proxying per record (for example, an orange-cloud toggle), DKIM CNAMEs must be DNS-only. A proxied DKIM CNAME will not resolve to the key and DKIM will fail.
• The hostname must be exact. zendesk1._domainkey and zendesk2._domainkey. No typos, no extra subdomain, no swapping the numbers.
• Subdomains of your support address. If your support address lives on a subdomain (say support@help.yourdomain.com), the selectors must be published under that subdomain: zendesk1._domainkey.help.yourdomain.com and so on. The selector hostname always tracks the From domain Zendesk signs for.

One firm limitation from Zendesk: DKIM signing only works for external email domains, not your Zendesk subdomain. Zendesk does not permit third parties to send on behalf of a *.zendesk.com address, so if your support address is still support@yourcompany.zendesk.com, you cannot DKIM-sign it. You need to be sending from your own domain first.

After publishing, verify the CNAMEs resolve before you do anything in Zendesk. The DKIM checker lets you query a selector directly: check both zendesk1 and zendesk2 against your domain and confirm each returns a valid key via the CNAME chain. DNS propagation can take anywhere from a few minutes to a day depending on your TTL, so do not rush the next step.

Step 3: enable DKIM signing in Zendesk (last, not first)

The single most important sequencing rule with Zendesk DKIM: publish DNS first, confirm it resolves, then enable signing in Zendesk. If you enable signing before the CNAMEs are live and propagated, Zendesk will start signing with a key that recipients cannot verify, and that causes delivery failures on your support email.

Once both CNAMEs resolve cleanly:

1. In Zendesk, open Admin Center.
2. Go to Channels then Talk and email then Email.
3. Under the DKIM/digital-signature setting, choose the option to sign with your custom domain for DKIM and enable it.

From that point, outbound Zendesk mail carries a DKIM signature with d=yourdomain.com and a zendesk1 or zendesk2 selector. Because the signing domain now matches your From domain, DKIM aligns, and that is what makes Zendesk traffic pass DMARC.

Send a test ticket reply to an address you control at a major mailbox provider, then open the raw message and inspect the Authentication-Results header. You want to see something like:

dkim=pass header.d=yourdomain.com header.s=zendesk1
dmarc=pass (p=NONE) header.from=yourdomain.com

If header.d shows zendesk.com instead of your domain, the custom-domain DKIM toggle did not take effect, usually because the CNAMEs were not resolving when you enabled it. Re-check DNS and toggle the setting again. You can also confirm the end-to-end alignment by pasting the raw headers into the email header analyzer.

Why DKIM, and not SPF, carries your alignment

It is worth stating plainly because it changes how you read your reports. Zendesk does not allow a custom Return-Path. There is no setting, no premium tier, no DNS trick on your side that moves the envelope sender onto your domain. The bounce domain stays on Zendesk. Therefore:

• SPF alignment for Zendesk is impossible. Do not chase it. You will see spf=pass for the Zendesk envelope but it will never be aligned to your From domain.
• DKIM alignment is achievable and reliable, via the two CNAMEs above and the custom-domain signing toggle.

DMARC passes if either SPF or DKIM passes and aligns. Since SPF cannot align here, your entire DMARC pass for Zendesk rides on DKIM. This is the opposite of senders where SPF is the easy win and DKIM is the bonus. For a refresher on how the two mechanisms combine, see understanding your DMARC record.

There is one more reason DKIM matters more than usual: forwarding. SPF breaks when mail is forwarded, because the forwarding server becomes the new envelope sender. DKIM survives forwarding as long as the message body and signed headers are not altered. Since support email is frequently forwarded inside customer organisations, DKIM alignment is also what keeps your mail authenticating after a hop. SPF was never going to help you here anyway.

Step 4: read your DMARC reports and find every other sender

Before you tighten your policy, you need evidence that Zendesk is aligning and that you have not forgotten another sender. Your From domain is almost certainly used by more than Zendesk: a marketing platform, your own mail server, an invoicing tool, a CRM. Enforcing DMARC blocks anything that is not aligned, so you must inventory everything first.

DMARC aggregate reports (RUA) are how you do this. Start your DMARC record at monitoring only:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; adkim=r; aspf=r

A few notes specific to the Zendesk situation:

• p=none collects data without affecting delivery. Stay here until Zendesk and every other sender shows aligned passes.
• adkim=r (relaxed DKIM alignment) is the default and is correct for Zendesk. The signing domain (yourdomain.com) and the From domain match at the organisational level, so relaxed alignment passes. You do not want adkim=s (strict) unless every sender signs with the exact same domain, which is rarely true once Zendesk is involved.
• fo=1 asks for a failure report whenever any mechanism fails, which helps you spot the Zendesk SPF-misalignment noise and confirm DKIM is the one carrying the pass.

If you do not yet have a DMARC record, generate one with the DMARC generator, and confirm what is published with the DMARC checker.

Aggregate reports arrive as XML and are painful to read by hand. Drop them into the DMARC report analyzer to see, per source, whether SPF and DKIM passed and aligned. For Zendesk you are specifically looking for rows where the source is Zendesk's infrastructure showing DKIM aligned: pass. Expect those same rows to show SPF aligned: fail, which is fine, because DMARC only needs one aligned pass.

For ongoing visibility rather than a one-off check, our monitoring ingests your aggregate reports continuously and alerts you when a source like Zendesk stops aligning, for example after a key-rotation hiccup or a DNS change. That is the difference between finding out from a dashboard and finding out from an angry customer.

Step 5: move to quarantine, then reject

Only when your reports show Zendesk and every other legitimate sender aligned over a representative window (a week or two that includes your normal volume) should you tighten the policy.

Step up gradually:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com; fo=1

The pct=25 tag applies the quarantine policy to a quarter of failing mail, so any sender you missed gets a soft landing in spam rather than a hard block. Watch your reports for a few days, raise to pct=100, then once that is clean, go to enforcement:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; fo=1

At p=reject, unauthenticated mail using your domain is refused outright. Because Zendesk is aligned via DKIM, your support email sails through. Anyone spoofing your domain does not. For the full staged playbook, see our guide on reaching p=reject without breaking email, and for the broader context on why mailbox providers now expect this, Gmail, Yahoo and Microsoft require DMARC.

Common Zendesk pitfalls

• Only one selector published. Both zendesk1 and zendesk2 must resolve. Zendesk rotates between them, so if only one is live, signing will intermittently fail when it switches to the missing key. Verify both with the DKIM checker.
• Enabling signing before DNS propagated. The classic outage. Confirm both CNAMEs resolve first, then flip the toggle in Admin Center.
• CNAME records proxied or turned into TXT. Must be CNAME, must be DNS-only, must point at zendeskN._domainkey.zendesk.com.
• Chasing SPF alignment. It will never align for Zendesk because the Return-Path is locked to a Zendesk domain. Stop trying; rely on DKIM.
• Forgetting the subdomain. If your support address is on a subdomain, the selectors and the DMARC record both need to account for that subdomain, including any subdomain DMARC record considerations.
• Other senders on the same domain. Zendesk aligning is necessary but not sufficient. Inventory every sender via reports before you enforce, or you will block your own marketing or billing email.
• d=zendesk.com in the headers. That means custom-domain DKIM did not engage. Re-check DNS and re-enable the setting.

The practical takeaway

Zendesk is a DKIM-first sender, full stop. SPF will pass but never align because the Return-Path is fixed on a Zendesk domain, so the entire DMARC pass for your support email depends on publishing both zendesk1 and zendesk2 CNAME records, confirming they resolve, and only then enabling custom-domain DKIM signing in Admin Center. Once header.d shows your domain and your reports show Zendesk DKIM aligned, you can move from p=none through p=quarantine to p=reject without losing a single ticket reply.

Start by checking what is live today with the DKIM checker and the DMARC checker, then watch your aggregate reports in the DMARC report analyzer. If you would rather not babysit selectors, propagation and the staged rollout yourself, our done-for-you DMARC service configures Zendesk alignment, keeps your SPF record flattened and within the lookup limit, and takes your domain to enforcement safely with continuous monitoring so you hear about a broken signature before your customers do.