How to set up DMARC/DKIM/SPF for Zendesk
Published 5 Aug 2026
Updated 12 Oct 2026
12 min read
Summarize with
Updated on 18 Oct 2026: We corrected the DMARC matching checks and added Zendesk incoming authentication steps.
For an external support address on your own domain, configure an SPF authorization for mail.zendesk.com, two DKIM CNAME records and a domain-level DMARC record. Add the address first, publish SPF and DKIM, enable Zendesk's DKIM signing only after DNS resolves, then verify a real ticket reply. DMARC requires at least one passing SPF or DKIM result whose authenticated domain matches the visible From domain under the configured matching rules.
What the finished setup should do
- SPF: Authorize Zendesk with include:mail.zendesk.com and verify the actual return-path domain in a delivered reply.
- DKIM: Zendesk signs with your domain through the zendesk1 and zendesk2 selectors.
- DMARC: At least one aligned SPF or DKIM result passes for every legitimate Zendesk message.
Add an external support address
Zendesk does not have a separate domain inventory step for this workflow. Add the custom-domain mailbox as an external support address, configure server-side forwarding and let Zendesk verify the address. This must be complete before Zendesk can send branded replies from that address. You need Zendesk admin permissions and access to the domain's authoritative DNS settings.
- Open Email: In Zendesk Admin Center, go to Channels, Talk and email, then Email.
- Start connection: Select Manage support addresses, Add address and Connect external address. Choose the correct brand if Zendesk asks.
- Choose forwarding: Select Email forwarding and continue. Create server-side forwarding in your mailbox provider to the Zendesk support address shown.
- Save address: Return to Zendesk, enter the external support address, then select Save.
- Verify forwarding: Open the options menu beside the new address and select Verify forwarding. If your mailbox provider sends a confirmation message, find the resulting ticket and approve it. Check Suspended tickets for that confirmation, then retry Verify forwarding after resolving any failure.
Zendesk external support address and email forwarding setup
Use a dedicated mailbox, not a distribution group or alias. Keep forwarding to one hop and configure it on the mail server, not inside a desktop mail client. Zendesk's outbound setup instructions confirm that custom-domain authorization is recommended when Zendesk sends for an external support address.
Set up SPF
Authorize Zendesk in the single SPF TXT record at the exact domain used in the external support address. For support@help.example.com, edit the SPF record at help.example.com, because SPF records are not inherited from the parent domain. The supported include is mail.zendesk.com, and Zendesk requires it in the first layer of the record rather than behind another include.
- Find the record: Check the TXT records at the exact domain used in the Zendesk From address.
- Create or merge: If no SPF record exists, publish the Zendesk-only example below. If one exists, insert include:mail.zendesk.com before its final all mechanism.
- Keep one record: Never publish a second SPF TXT record. Multiple SPF records return a permanent error.
- Count lookups: Keep the evaluated SPF path within the limit of 10 DNS-querying terms, counting nested includes and redirects.
New Zendesk-only SPF recordDNS
v=spf1 include:mail.zendesk.com -all
Example merged SPF recordDNS
v=spf1 include:spf.sender.example include:mail.zendesk.com -all
Do not use the older smtp.zendesk.com or support.zendesk.com includes. They are outdated. A hard fail ending is appropriate once every legitimate sender has been inventoried, but preserve the current ending while making a narrowly scoped Zendesk change if another team owns the record. The merged record is illustrative: replace include:spf.sender.example with your existing sender's real include before publishing it.
The checker below should return one valid SPF record and show mail.zendesk.com in the evaluated path. It should not report duplicate records, a syntax error or an exceeded 10-term SPF lookup limit.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Zendesk also checks SPF when the external support address is added. A clean DNS result does not prove DMARC compliance by itself, so send a ticket reply and inspect the message headers after DKIM is enabled.
SPF authenticates the envelope sender (MAIL FROM), usually recorded in Return-Path, rather than the visible From address. If those domains do not satisfy DMARC's matching rules, SPF can pass without contributing to a DMARC pass. Confirm that DKIM passes with the appropriate signing domain before treating an SPF domain mismatch as acceptable.
Set up DKIM
DKIM is a dependable DMARC path for Zendesk replies because the signature survives forwarding when the signed content remains intact. Publish both Zendesk CNAME selectors for every external sending domain, wait for them to resolve, then enable signing in Zendesk. Zendesk rotates the keys behind these CNAME targets, so the records should stay in place.
- Open DNS: Go to the authoritative DNS zone for the domain in your external support address. Replace example.com in both selector names with that exact domain, including any subdomain.
- Add selector one: Create a CNAME for zendesk1._domainkey.example.com pointing to zendesk1._domainkey.zendesk.com.
- Add selector two: Create a CNAME for zendesk2._domainkey.example.com pointing to zendesk2._domainkey.zendesk.com.
- Check resolution: Confirm both names return their Zendesk targets through public DNS before changing the Zendesk setting. Use DNS-only CNAME records. If the DNS editor appends example.com automatically, enter zendesk1._domainkey and zendesk2._domainkey as the hosts.
- Enable signing: In Admin Center, open Channels, Talk and email, Email. Select Custom domain for DKIM in Email settings, then Save.
Zendesk DKIM CNAME recordsDNS
zendesk1._domainkey.example.com. IN CNAME zendesk1._domainkey.zendesk.com. zendesk2._domainkey.example.com. IN CNAME zendesk2._domainkey.zendesk.com.
Enable signing last
Do not select Custom domain for DKIM until both CNAME records resolve. Enabling it first can cause delivery failures. DNS propagation commonly takes several hours and can take about a day when the previous TTL is long.
Zendesk Custom domain for DKIM setting enabled
A resolving CNAME proves that the alias exists; its Zendesk target must also return a DKIM public key. The final test is a live Zendesk reply whose Authentication-Results header shows dkim=pass with a signing domain that satisfies the DMARC policy's matching rules. Zendesk's DKIM instructions describe the selectors and signing setting.
Set up DMARC
For mail sent as support@example.com, publish the DMARC TXT record at _dmarc.example.com. It covers every sender using that From domain. Begin with p=none to collect reports without asking receivers to quarantine or reject mail. If the domain already uses p=quarantine or p=reject, keep that policy and fix Zendesk without weakening enforcement.
No existing DMARC record
- Start safely: Publish p=none with an aggregate report mailbox.
- Use one record: Create one TXT record at the _dmarc host.
Existing enforced policy
- Keep enforcement: Do not lower quarantine or reject to add Zendesk.
- Repair first: Complete aligned DKIM before enabling the sending address.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Replace the example reporting mailbox with a real address that can receive aggregate XML. If rua points to a different organization's domain, confirm that the reporting destination has authorized external reports. The DMARC record generator can build the record if you need subdomain policy or alignment controls. Publish only one DMARC TXT record at the host. For support@help.example.com, check the existing DMARC policy for help.example.com before publishing a record at _dmarc.help.example.com.
After DNS propagates, confirm that the record parses and that the reporting address appears exactly as intended. A p=none record requests reports from participating receivers but does not request quarantine or rejection of failing mail.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The result should show one DMARC record, a valid DMARC version, the expected policy and the correct aggregate mailbox. Other unrelated TXT records at the same host do not invalidate DMARC; multiple DMARC policy records do. Check for an invalid rua URI.
DMARC passes when either SPF or DKIM passes and its authenticated domain satisfies the matching rules for the visible From domain. With the default relaxed mode, the domains share an organizational domain. With adkim=s or aspf=s, the respective authenticated domain must match the From domain exactly. These rules are defined in RFC 9989. Verify custom-domain DKIM for Zendesk and check SPF against the actual MAIL FROM domain.
Verify and troubleshoot
DNS checks are necessary but do not prove that Zendesk used the expected domains on a real message. Create a ticket through the external support address, reply as an agent and inspect the delivered message's raw headers. Test at least one mailbox outside your own domain and repeat the test for each sending domain or brand.
- Send inbound: Email the external support address and confirm Zendesk creates a ticket under the intended brand.
- Reply outbound: Send an agent reply and confirm the visible From address uses your custom domain without a Zendesk via warning.
- Read headers: Open the raw message and locate Authentication-Results, Return-Path and DKIM-Signature.
- Check outcomes: Require dmarc=pass and dkim=pass with your domain. Check spf=pass separately, comparing the receiver's smtp.mailfrom domain with the visible From domain under the DMARC policy's SPF matching rules.
|
|
|
|---|---|---|
SPF | Pass | smtp.mailfrom is authorized; compare its domain with header.from under aspf |
DKIM | Pass | header.d satisfies adkim; header.s is zendesk1 or zendesk2 |
DMARC | Pass | header.from is your custom domain; at least one passing method satisfies DMARC |
Header results for a correctly authenticated Zendesk reply
The Suped email tester below provides an end-to-end check. Send a Zendesk agent reply to the generated test address, then review the authentication results and message headers in one report. A DMARC pass does not guarantee inbox placement.
Use a fresh message created after DNS propagation. A forwarded copy can change the path or hide the authentication result produced by the final receiving system.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the tester reports dkim=none, confirm both CNAMEs resolve and that Custom domain for DKIM is enabled. For dkim=fail, check public key resolution, the DNS record type or proxy, and whether signed content changed. For dkim=pass with dmarc=fail, compare header.d with header.from under the policy's adkim setting. A valid signature for the wrong domain is a DMARC matching problem.
If SPF fails, check the domain shown in smtp.mailfrom for duplicate records or an exceeded 10-term limit. Separately confirm mail.zendesk.com appears directly in the SPF record Zendesk checks for the external support address. Use the DMARC checker to separate policy syntax problems from message-level authentication failures.
Zendesk support address showing verified forwarding status
Common failure patterns
- SPF permerror: Merge duplicate SPF records and reduce DNS-querying mechanisms.
- DKIM missing: Fix both CNAMEs before selecting Custom domain for DKIM.
- DMARC fail: Compare the SPF mail-from and DKIM signing domains with the visible From domain.
- Forwarding fails: Use server-side forwarding, retry Zendesk verification and check Suspended tickets for a provider confirmation message.
Configure incoming email authentication
Zendesk's incoming sender authentication checks customer email before creating tickets and has its own account setting. The DNS records above authenticate outbound Zendesk replies.
- Open Email settings in Admin Center under Channels > Talk and email > Email.
- Under "Authenticate emails received with SPF, DKIM, and DMARC alignment", review the selected profile.
- Minimal applies basic checks. Native traffic adds checks for mail sent directly to a Zendesk address. Test Native traffic before choosing Native and forwarded traffic.
- Save, test direct and forwarded customer mail, then inspect Suspended tickets for "Failed email authentication".
Native and forwarded traffic uses ARC (Authenticated Received Chain) seals and recorded authentication results to assess forwarded mail. Check ARC support with your forwarding provider and repair failed forwarding workflows. Agent email is always authenticated. Zendesk's incoming authentication instructions explain the profiles and suspension rules.
Monitor Zendesk authentication
A one-time pass can break after an SPF edit, forwarding rule changes, a DNS migration or a new sender deployment. Aggregate reports reveal these changes, but raw XML is slow to triage. Continuous DMARC monitoring turns them into pass rates and failures for each sending source.
Suped is our DMARC reporting and email authentication product. Use it to review Zendesk's reported authentication results and follow the remediation steps for the affected source. Aggregate reports arrive after the receiver's reporting cycle, so report-based alerts do not provide immediate notification for every message.
Monitor the Zendesk source
- Identify Zendesk: Confirm the source through sending IPs and reported authentication domains, then inspect a live reply for the Zendesk selectors before marking it authorized.
- Set alerts: Notify the domain owner when Zendesk authentication failures exceed the chosen threshold.
- Review changes: Compare failure timing with DNS edits, forwarding changes and Zendesk configuration work.
- Fix the source: Use Suped's issue-specific remediation steps, then confirm recovery in new reports.
For an MSP or a team with several brands, Suped's multi-tenant dashboard keeps domains and their owners in one operational view. Assign a domain owner to investigate Zendesk authentication failures.
Secure your domain with p=reject
A p=none policy reports domain use but does not ask receivers to quarantine or reject failing mail. Move to p=reject only after Zendesk and every other legitimate sender consistently pass DMARC. The Zendesk source should show passing custom-domain DKIM on normal ticket replies; verify SPF independently instead of assuming a second DMARC path is available.
- Inventory sources: Classify every source seen in aggregate reports as authorized, obsolete or unauthorized.
- Fix Zendesk: Require stable custom-domain DKIM pass and confirm the external support address sends with the expected From domain. Keep both selector CNAMEs resolving; Zendesk chooses the active selector during key rotation.
- Watch full cycles: Observe enough report data to include low-volume automations, weekends and billing or renewal sends.
- Stage quarantine: Move to p=quarantine, inspect quarantined legitimate mail and reported policy dispositions, and correct failures before moving to p=reject.
- Publish reject: Set p=reject after legitimate sources are ready and continue monitoring for changes.
Full DMARC enforcementDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC lets you stage policy changes without editing the full TXT value for each adjustment. Review Zendesk's reported authentication failures before increasing enforcement and continue monitoring afterward.
Do not weaken an existing policy
If the domain already has p=quarantine or p=reject, keep it. Complete Zendesk DKIM before enabling outbound mail, test with a controlled address and repair authentication at the source. Lowering policy exposes every sender on the domain, not only Zendesk.
Frequently asked questions
A custom external support address should use all three. SPF authorizes Zendesk in your domain's DNS, DKIM signs with your domain and DMARC checks that at least one passing authenticated domain satisfies the visible From domain's matching rules. Verify the actual envelope sender to assess SPF. DKIM remains important when forwarding breaks SPF.
Reverse DNS names ending in .zendesk.com are a clue, but do not authorize a source from rDNS alone. Confirm it with sending IPs, reported authentication domains and a live reply using the zendesk1 or zendesk2 DKIM selector. Aggregate reports do not reliably include selectors.
mail.zendesk.com is Zendesk's supported SPF include for custom-domain outbound mail. Do not add an SPF include only because it appears in observed data. Add it when Zendesk is authorized to send for the domain and keep it in the first layer of the single SPF record.
Yes. DMARC passes when DKIM passes and its signing domain satisfies the From domain's matching rules, even if SPF fails or loses the required domain match during forwarding. Under adkim=s, the DKIM signing domain must match the From domain exactly.
No. A domain must have one SPF record. Merge include:mail.zendesk.com into the existing record before its final all mechanism, then verify syntax and the 10-lookup limit.
