Zendesk support email can pass through native Zendesk sending, external support addresses, Gmail connectors, authenticated SMTP relay, forwarding, and inbound authentication checks. Review the exact path before tightening DMARC on a support domain.
Scan the Zendesk support domain first
Check public DMARC, SPF, DKIM, MX, BIMI, MTA-STS, and TLS-RPT signals before editing Zendesk support-address records.
01$0Free scan
Check the public sender-auth records mailbox providers expect.
02$0Shareable action plan
Keep one URL with evidence, owner steps, and decisions.
03$49$49 fix plan
Add human review, provider context, and verification steps.
Optional. Most first scans can run with just the domain.
Checks Gmail, Yahoo, and Microsoft sender requirementsPublic DNS onlyNo mailbox login needed
Example result72/100Needs attention
Review DMARC policy strength before a high-volume send.
Public DNS evidence
DMARC/SPF/DKIM status and caveats are visible before you pay.
Owner-ready next step
The audit adds provider context and a verification checklist.
Get the exact fix plan for your domain.$49 readiness audit: prioritized owner actions, DNS evidence, and verification checks.
Support email often uses the same domain as Google Workspace, Microsoft 365, marketing platforms, billing tools, and transactional systems. SPF and DMARC changes made only for Zendesk can break another sender if the full map is missing.
Zendesk also has separate concepts for external support-address sending, DKIM signing, inbound sender authentication, Gmail sending, and authenticated SMTP relay. The safe review is DNS plus Zendesk account settings plus a real ticket email header.
Setup areas to review
Identify the Zendesk sending path: Zendesk system support addresses on a Zendesk subdomain are authenticated by Zendesk. External support addresses on your own domain need the domain owner to authorize Zendesk before the brand domain can be used cleanly.
Merge Zendesk into the one SPF record: Zendesk recommends authorizing external support addresses with include:mail.zendesk.com. If the domain already has SPF for Google, Microsoft, or another sender, merge Zendesk into that one TXT record instead of adding a second SPF record.
Avoid outdated Zendesk SPF includes: Zendesk says older SPF formulations such as include:smtp.zendesk.com and include:support.zendesk.com are outdated. Use current Zendesk guidance and keep include:mail.zendesk.com in the first-layer lookup when you use it.
Record account-generated TXT verification carefully: Zendesk references TXT/domain-verification values for external support-address setup. Treat the value as account-generated and do not copy a sample value from a guide.
Add DKIM CNAMEs before enabling signatures: Zendesk DKIM uses two CNAME records for zendesk1 and zendesk2 selectors. Enable Custom domain for DKIM only after the CNAMEs are published, because enabling the feature first can cause delivery failures.
Stage DMARC after every support sender is aligned: Zendesk recommends starting DMARC with p=none, then moving to quarantine or reject only after legitimate email, including Zendesk, authenticates through SPF and DKIM.
Separate inbound authentication from outbound authentication: Zendesk can authenticate received email with SPF, DKIM, DMARC, and ARC and suspend failures. That inbound protection is separate from the DNS records used to authorize outbound support replies from your domain.
Inspect forwarding and alias workflows: Zendesk recommends server-level forwarding for external support addresses. Aliases, groups, distribution lists, and client-side forwarding can change headers or authentication results, so they need real ticket-flow testing.
Review connector-specific behavior: Gmail and authenticated SMTP connectors can change which system is the final sender. Test headers in the actual Zendesk path before treating public DNS alone as complete proof.
DNS record examples and caveats
These examples show record shapes only. Zendesk account settings, the exact support address path, and current official docs are the authority for whether Zendesk, Gmail, authenticated SMTP, or another service is the active sender.
Zendesk SPF merge shape:v=spf1 include:_spf.google.com include:mail.zendesk.com -all. Use one SPF TXT record for the domain. The other includes depend on the rest of the sender map.
Zendesk DKIM selector 1 CNAME:zendesk1._domainkey.example.com -> zendesk1._domainkey.zendesk.com. Publish this for the external email domain used by Zendesk before enabling Custom domain for DKIM.
Zendesk DKIM selector 2 CNAME:zendesk2._domainkey.example.com -> zendesk2._domainkey.zendesk.com. Zendesk uses the paired selectors so key rotation can continue without recurring DNS edits.
Zendesk verification TXT shape:zendeskverification.example.com -> account-generated Zendesk value. Use the value shown for the Zendesk account and support address. Do not reuse a sample value.
DMARC TXT monitoring shape:v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Use reporting and header evidence before tightening DMARC for a support-heavy domain.
Safe verification sequence
List every Zendesk support address and brand that sends customer email.
Identify whether each address is native Zendesk, external forwarded, Gmail, or SMTP relay.
Merge Zendesk into the single SPF TXT record only for domains that need it.
Add account-generated Zendesk verification TXT values when the account requires them.
Add both Zendesk DKIM CNAME records before enabling Custom domain for DKIM.
Check public DNS propagation and inspect Zendesk Email settings for warnings.
Send a real ticket notification and review SPF, DKIM, return-path, and DMARC headers.
Monitor DMARC reports and suspended tickets before moving policy past p=none.
Zendesk authentication FAQ
What SPF include does Zendesk recommend?
Zendesk documents include:mail.zendesk.com for authorizing external support-address sending. Merge it into the domain's one existing SPF TXT record and avoid outdated includes such as include:smtp.zendesk.com or include:support.zendesk.com.
What DKIM records does Zendesk use?
Zendesk documents two CNAME records: zendesk1._domainkey.yourdomain to zendesk1._domainkey.zendesk.com and zendesk2._domainkey.yourdomain to zendesk2._domainkey.zendesk.com. Enable Custom domain for DKIM only after publishing them.
Does Zendesk publish my DMARC policy?
No. Zendesk can participate in authentication for support email, but the domain owner publishes and manages the DMARC TXT policy in DNS with the domain administrator or provider.
Can I use an alias, group, or distribution list as a Zendesk support address?
Zendesk documentation treats those paths as unsupported even when they are not blocked. They can alter headers and forwarding behavior, so test real tickets and authentication results before relying on them.
Do Zendesk subdomain support addresses need my SPF record?
Zendesk says system support addresses on support@subdomain.zendesk.com use Zendesk's own SPF and DKIM authority. Custom external support addresses on your own domain are the ones that need your DNS review.
Can Zendesk work with a strict DMARC policy?
Only after Zendesk and every other legitimate sender using the domain pass authentication. Start with p=none, watch reports and headers, then move toward quarantine or reject in stages.
Is Zendesk inbound sender authentication the same as outbound SPF/DKIM setup?
No. Zendesk inbound authentication checks received messages with SPF, DKIM, DMARC, and ARC and can suspend failures. Outbound setup authorizes Zendesk or a connector to send support replies from your domain.
Can a public scanner fully verify Zendesk setup?
A scanner can inspect SPF, DKIM selector DNS, DMARC policy, and common Zendesk signals, but a complete review still needs Zendesk Email settings and a real sent-message header from the exact support address path.
Turn the scan into a Zendesk fix list
SenderReady readiness audits organize public DNS findings, Zendesk-specific review steps, and cautious next actions for the domain owner or DNS admin. The report is a diagnostic aid, not a deliverability guarantee.