SPF, DKIM & DMARC for Zendesk.
Zendesk sends your ticket replies, notifications, and automations from your support address (support@yourdomain.com), so authenticating it is what stops those messages landing in customers' spam folders or wearing a "via zendesk.com" tag. Authentication is split across your DNS host and the Zendesk Admin Center. SPF is a genuine shared include — you add include:mail.zendesk.com to the one SPF record on your domain — and DKIM is two CNAME "digital signature" records you publish and then switch on under Channels → Talk and email → Email. DMARC is a third, separate record Zendesk never creates for you. One prerequisite matters: DNS authentication only applies when you send from an external email domain of your own; addresses on the default yourbrand.zendesk.com domain are already signed by Zendesk and need nothing.
Why authenticate Zendesk?
Authenticating Zendesk isn't housekeeping — it decides whether your support replies reach customers at all. A busy support queue easily clears the 5,000-messages-a-day threshold that, since February 2024, obliges Gmail and Yahoo bulk senders to pass SPF, DKIM, and DMARC with alignment; Microsoft began enforcing similar rules for high-volume senders in 2025. Until you authenticate an external support domain, Zendesk sends replies that are only weakly attributable to you: recipients see a "via zendesk.com" note, your From address isn't cryptographically yours, DMARC can't pass, and any spam complaints pool against Zendesk's shared infrastructure instead of building your own reputation. There's also a Zendesk-specific wrinkle that makes DKIM non-negotiable here: Zendesk's SPF never aligns to your domain (it bounces mail on its own zendesk.com Return-Path), so unlike Google Workspace or Microsoft 365, you can't lean on SPF to carry DMARC — DKIM is the only mechanism that aligns. Set up the SPF include, the two DKIM CNAMEs, and a DMARC policy, and your replies go out signed as your own domain, the "via" tag disappears, DMARC passes, and the reputation you earn is yours.
The SPF reality for Zendesk
Zendesk is a genuine "include" provider — you add one real shared mechanism, include:mail.zendesk.com, to the single SPF TXT record on your domain, and Zendesk officially recommends the full record v=spf1 include:mail.zendesk.com -all (it recommends the -all hard fail for the strongest anti-spoofing). Verified against live DNS, mail.zendesk.com resolves to a flat record containing only ip4: ranges and its own ~all, with no nested includes, so it costs exactly ONE of your 10 SPF DNS lookups. Here's the part almost every tutorial skips, and it's the most important thing to understand about Zendesk SPF: it passes but it does not ALIGN. By default Zendesk sends outbound mail with the envelope Return-Path (the MAIL FROM that receivers actually run SPF against) on one of Zendesk's own zendesk.com bounce domains, not on your domain — and Zendesk provides no mechanism to move that Return-Path onto your domain. So SPF authenticates against Zendesk's infrastructure and passes, but because the checked domain is a zendesk.com subdomain rather than your From domain, it is not aligned, and DMARC only counts SPF when it aligns. That means include:mail.zendesk.com cannot carry a DMARC pass on its own. It is still worth adding — Zendesk recommends it, some receivers do a non-aligned SPF check on the visible From domain, and it stops SPF-related bounces and spam-foldering — but the mechanism that actually makes DMARC pass for Zendesk is DKIM alignment, not SPF. Keep exactly one SPF record on the domain (merge the include if you already send via Google Workspace, Microsoft 365, etc.), keep include:mail.zendesk.com as a first-layer mechanism in that record, and start with ~all rather than -all until every other legitimate sender is enumerated.
Two ways to set it up
External email domain — SPF include + DKIM (recommended)
- Replies come from your own brand (support@yourdomain.com), not a zendesk.com address
- DKIM signs as d=yourdomain.com so DMARC passes via DKIM alignment
- Add include:mail.zendesk.com plus the two zendesk1/zendesk2 DKIM CNAMEs to your DNS
- Costs one SPF DNS lookup; keys rotate automatically once the CNAMEs are live
Default yourbrand.zendesk.com address — nothing to set up
- Zendesk already authenticates and signs its own zendesk.com domain
- No SPF, DKIM, or DMARC records for you to publish
- But customers see a generic zendesk.com From address instead of your brand
- No control over reputation — you share Zendesk's domain with every other tenant
Step by step
- 1
Add and verify your external support address
In Admin Center, open Channels → Talk and email → Email and add a support address on your own domain (e.g. support@yourdomain.com), then verify it — either by forwarding incoming mail from that mailbox to your yourbrand.zendesk.com address, or by connecting Google Workspace / Microsoft 365. This matters because DNS authentication (SPF include + DKIM CNAMEs) only applies to external domains; addresses on the default yourbrand.zendesk.com domain are already signed by Zendesk.
- 2
Add or merge the SPF include
On your root domain, add a TXT record with v=spf1 include:mail.zendesk.com -all (Zendesk recommends the -all hard fail). If an SPF record already exists, don't publish a second one — merge include:mail.zendesk.com into the existing v=spf1 line, keeping it as a first-layer mechanism, and use ~all until every other sender is listed.
- 3
Add the two DKIM CNAME records
Create two CNAME records: host zendesk1._domainkey.yourdomain.com pointing to zendesk1._domainkey.zendesk.com, and host zendesk2._domainkey.yourdomain.com pointing to zendesk2._domainkey.zendesk.com. There are two because Zendesk rotates DKIM keys for security. These must be CNAME records, not TXT — Zendesk holds the keys behind those hostnames.
- 4
Publish a DMARC record
Add a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only — it changes nothing about delivery while you confirm Zendesk is passing DKIM aligned to your domain. Keep just one _dmarc record for the whole domain.
- 5
Wait for the records to propagate
Give DNS a few hours (occasionally up to a day) to propagate before the next step. Do NOT enable DKIM signing in Zendesk yet — turning it on before the CNAMEs resolve is the single most common cause of Zendesk delivery failures.
- 6
Turn on DKIM signing (must be the final step)
Back in Admin Center → Channels → Talk and email → Email, find the DKIM / digital-signature setting and select Custom domain for DKIM, then click Save. Zendesk is explicit that this must be the last thing you do: enabling it before the CNAME records for your domain are live will cause delivery failures.
- 7
Send a test reply and read the headers
Reply to a test ticket so Zendesk sends a real outbound message, open it in Gmail, and use ⋮ → Show original. Confirm DKIM: PASS signed by yourdomain.com (selector zendesk1 or zendesk2) and DMARC: PASS. SPF will show pass but not aligned (Return-Path on a zendesk.com domain) — that's expected and fine; DKIM is carrying DMARC.
- 8
Repeat for every brand and support domain
Each external support address on a different domain needs its own SPF include, its own zendesk1/zendesk2 DKIM CNAMEs, its own DMARC record, and the Custom domain for DKIM toggle enabled. Authenticating one domain does not cover the others.
Records to add
Zendesk generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:mail.zendesk.com -allRoot SPF — keep one SPF record and merge include:mail.zendesk.com into it. Passes but does NOT align (Zendesk's Return-Path is a zendesk.com domain), so it doesn't carry DMARC on its own. Costs 1 DNS lookup. |
| CNAME | zendesk1._domainkey | zendesk1._domainkey.zendesk.comDKIM key 1. This target is the same for every Zendesk customer (not a per-account value); only the host's domain is yours. Zendesk rotates the key behind it automatically. |
| CNAME | zendesk2._domainkey | zendesk2._domainkey.zendesk.comDKIM key 2 — both are required because Zendesk rotates keys. Also a shared target, identical for all customers. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comOne DMARC record per domain. This is what carries the DMARC pass for Zendesk — via DKIM alignment. Start at p=none, then tighten to quarantine/reject once DKIM is confirmed. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Zendesk's setup costs against that budget.
Zendesk adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM is where Zendesk mail actually earns its DMARC pass, so it's the record that matters most. You publish two CNAME records — zendesk1._domainkey.yourdomain.com → zendesk1._domainkey.zendesk.com and zendesk2._domainkey.yourdomain.com → zendesk2._domainkey.zendesk.com — and then enable signing in the Admin Center. A few Zendesk-specific things to know. First, these are CNAMEs, not TXT keys you paste: Zendesk holds the private keys and publishes the public keys behind zendesk1._domainkey.zendesk.com and zendesk2._domainkey.zendesk.com, so it can rotate them (roughly quarterly) without you ever touching DNS again — the CNAME lookup always resolves to the current key. Second, both hostnames point to the same shared zendesk.com targets for every customer; there is no per-account value, so don't try to personalize the target or paste an account ID into it. The reason there are two selectors (zendesk1 and zendesk2) is precisely to make that rotation seamless — one is active while the other is staged. Third, DKIM only works for an external email domain; you can't DKIM-sign mail sent from a yourbrand.zendesk.com address as your own domain. Finally, publishing the CNAMEs does nothing until you switch signing on: go to Admin Center → Channels → Talk and email → Email and select Custom domain for DKIM, then Save — but only after the CNAMEs have propagated, because enabling it early causes delivery failures. Once live, Zendesk signs with d=yourdomain.com, which aligns to your From domain and passes DMARC.
DMARC
DMARC is a separate policy record that Zendesk never creates for you — you publish it yourself as a TXT record at _dmarc.yourdomain.com, starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery but asks receivers to email you aggregate reports so you can confirm Zendesk mail is passing. The Zendesk-specific caveat is that your DMARC pass depends entirely on DKIM, because Zendesk's SPF never aligns (its Return-Path lives on a zendesk.com bounce domain). So before you tighten the policy, use the rua reports to make sure Zendesk is showing up as DKIM-aligned and passing — if you jump to p=quarantine or p=reject while DKIM is misconfigured, SPF can't cover for it and your support replies will start getting quarantined or rejected. Watch the reports for a week or two, confirm Zendesk and every other legitimate sender aligns, then move to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you run; never add a second one just for Zendesk.
Check it actually worked
Don't trust the Admin Center's status alone — confirm it on a real message. Reply to a test ticket so Zendesk sends an outbound email from your external support address, open it in Gmail, and choose ⋮ → Show original. You want DKIM: PASS with signed-by: yourdomain.com (selector zendesk1 or zendesk2) and DMARC: PASS. SPF will read pass but unaligned — the mailed-by/Return-Path will be a zendesk.com domain — and that is expected for Zendesk, not a misconfiguration, so don't chase SPF alignment. You can spot-check the raw records with dig CNAME zendesk1._domainkey.yourdomain.com (it should resolve through to zendesk.com) and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm every record resolves and your SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Zendesk should appear as a DKIM-aligned, passing source even though its SPF is unaligned.
Common gotchas
- DNS setup
Enable DKIM last. Zendesk is explicit that selecting Custom domain for DKIM before your zendesk1/zendesk2 CNAMEs have propagated will cause delivery failures — publish and let DNS settle (a few hours to a day) first, then flip the switch.
- Coverage
SPF won't align, by design. Zendesk bounces outbound mail on its own zendesk.com Return-Path, so include:mail.zendesk.com makes the raw SPF check pass but never aligns to your domain and can't carry DMARC alone. DKIM is what aligns — don't waste time trying to force SPF alignment; Zendesk offers no way to do it.
- Coverage
DKIM only works on an external email domain. Mail sent from a yourbrand.zendesk.com address can't be signed as your domain — you must add and verify a support address on your own domain first (support@yourdomain.com).
- DNS setup
The DKIM CNAME targets are shared, not unique. Both point to zendesk1._domainkey.zendesk.com / zendesk2._domainkey.zendesk.com for every Zendesk customer — don't try to add an account ID or 'personalize' the target, and don't publish them as TXT records.
- Breaks auth
Keep exactly one SPF record and keep the include first-layer. If you already send via Google Workspace, Microsoft 365, etc., merge include:mail.zendesk.com into that single v=spf1 line — two SPF records is a PermError, and burying the include inside a nested lookup can stop it resolving in the first layer.
- Coverage
-all vs ~all. Zendesk recommends the -all hard fail, but if your SPF doesn't yet list every legitimate sender, -all will hard-fail that other mail. Use ~all until you've enumerated all senders, then tighten to -all.
- DNS setup
Host-field doubling. Many registrars auto-append your domain, so entering zendesk1._domainkey.yourdomain.com produces zendesk1._domainkey.yourdomain.com.yourdomain.com. Enter just the label zendesk1._domainkey if the panel adds the domain for you.
- DNS setup
Multiple brands and domains each need the full set. Every external support domain needs its own SPF include, its own two DKIM CNAMEs, its own DMARC record, and Custom domain for DKIM enabled — one domain's setup doesn't cover the others.
Build your SPF record
Zendesk is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listZendesk SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.