Zendesk SPF, DKIM and DMARC setup, step by step

For native Zendesk Support email sent from your own external support domain, authorize the documented sender with include:mail.zendesk.com in your existing SPF policy, publish both Zendesk DKIM CNAMEs, and enable Custom domain for DKIM only after DNS resolves correctly. Then inspect a fresh ticket notification for a passing, aligned signature and DMARC result. Connected Gmail or authenticated SMTP routes need their own sending-path checks.

This guide covers outbound Support notifications, not Zendesk's inbound checks on customer email, another Zendesk product, or permission for another service to impersonate a zendesk.com address. No customer account, DNS zone, or delivered message was tested.

Confirm your support address and sending route

First record the external support address, its exact domain, the associated brand, and how Zendesk sends replies. A ticket arriving successfully proves an inbound path; it does not prove outbound authentication.

For the native route, add your external email address as a support address and configure the appropriate incoming forwarding. Zendesk's domain authorization guide makes the added support address a prerequisite. You need an administrator with access to the email settings and someone authorized to edit the actual DNS zone.

Use a domain you control. You cannot publish Zendesk authentication records inside public providers' domains such as gmail.com. If using a branded subdomain, prepare records for that subdomain rather than automatically editing the parent domain's SPF and DKIM.

Check these route differences before proceeding:

• Native Zendesk sending with an external support address: Follow the SPF and custom-domain DKIM procedure below.
• Zendesk Connector for Gmail: Zendesk describes its SPF authorization as recommended but not required for this connector. Review the connected account and the actual message path.
• Authenticated SMTP connector: Your mail service performs final outbound delivery. Its SPF authority and signing behavior must be reviewed alongside any Zendesk custom-domain signature.
• Zendesk-owned system address: You do not control its DNS. Do not attempt to authorize another server to send as your Zendesk subdomain.

The public setup pages use a dynamic What's my plan? selector rather than an explicit plan list in the retrieved body. Confirm the relevant controls in your subscription before promising connector availability. The native DKIM procedure specifically applies to external email domains, not every address shown in the account.

Add Zendesk to the correct SPF policy

For native outbound, Zendesk's current SPF instructions specify:

include:mail.zendesk.com

This is a mechanism to merge into the existing SPF policy, not a complete standalone TXT value. Zendesk requires this include in the first layer of the SPF record. Its older smtp.zendesk.com and support.zendesk.com includes are outdated; do not introduce them from an old screenshot.

Inventory the current record before editing. Preserve legitimate mailbox and application senders, place the mechanism before the terminal all, and keep only one v=spf1 TXT record at that owner. Do not overwrite the full policy with a Zendesk-only example. Zendesk recommends -all, but changing the existing qualifier is a domain-wide security decision that requires the full sender inventory.

If there is no SPF policy and Zendesk truly is the only sender using that envelope domain, Zendesk documents v=spf1 include:mail.zendesk.com -all. Confirm those conditions before using it. Other TXT records at the domain, such as verification tokens, are not duplicate SPF records and should remain.

Where the existing policy uses redirect=, inspect its delegated authorization before changing it. An all mechanism makes redirect ineffective; do not add all to an intended redirect-based policy or silently replace its security decision. Zendesk's page spells this as redirect: in its descriptive bullet, but SPF uses the standards-defined redirect= modifier. RFC 7208 all and redirect

Check the entire expanded policy against RFC 7208's ten-lookup-term limit. The evaluated include, a, mx, exists, ptr and redirect terms count, including nested evaluation; ip4, ip6 and all do not. This is not a count of raw DNS packets. Adding one visible include can trigger several underlying lookups. Do not fix a lookup error by adding a second record or authorizing every IP with +all.

SPF authorization does not prove alignment

The SPF identity is the SMTP MAIL FROM domain, normally reflected in Return-Path; with a null reverse-path, the applicable identity is derived from HELO. RFC 7208 identities The visible From address can be different. A passing SPF result for a provider domain does not automatically align with your branded support address.

Inspect both domains in a delivered notification. If SPF does not align but a valid DKIM signature aligns, DMARC can still pass. Conversely, two authentication passes on unrelated provider domains do not authenticate the branded From for DMARC.

This distinction is particularly useful when a dashboard clears an SPF warning. That status confirms a configuration check, not every receiver's result or every support address's route. Avoid widening your SPF policy simply to make an unrelated signature or identity look successful.

Publish both Zendesk DKIM CNAMEs

Zendesk uses documented shared targets for this native custom-domain signing workflow. Unlike an account-generated token, these targets are printed in its official DKIM instructions. Substitute only your actual external sending domain in the owners:

YOUR_SENDING_DOMAIN is a placeholder, not a literal DNS value. For an address at support.example.com, the first owner would be zendesk1._domainkey.support.example.com. Apply the same logic to every external domain used in Zendesk.

Publish at the authoritative DNS provider, which might not be your registrar. If its editor appends the zone automatically, use the relative host it expects and inspect the resulting complete owner. For full owner zendesk1._domainkey.support.example.com, the relative host in the parent example.com zone is zendesk1._domainkey.support. In separately delegated support.example.com, use zendesk1._domainkey; in delegated _domainkey.support.example.com, use zendesk1. Repeat the mapping for zendesk2. Verify the authoritative zone rather than changing delegation as a shortcut. Do not let the domain suffix appear twice.

A CNAME cannot coexist with a TXT, address or MX record, or a second CNAME, at the same owner. DNS alias rules Investigate conflicts before replacing anything. These aliases must resolve as DNS, without HTTP redirects or website proxying. Do not replace them with copied public-key text: the alias arrangement lets Zendesk rotate its keys without requiring you to republish each new key.

If the authoritative host is Cloudflare, keep the aliases DNS only and turn off a relevant per-record Flatten option where available. Whole-zone flatten-all must not suppress the literal CNAME answers; coordinate affected services before turning off that applicable setting. Apex and same-zone target behavior may flatten independently. If mandatory behavior cannot safely retain the required aliases, stop and coordinate a supported configuration rather than inventing an option or copying keys. Cloudflare flattening controls · Verification caveats

Leave both selectors in place. Zendesk documents quarterly key rotation; the second record is part of the continuing setup. No private key is required in your DNS editor.

Enable signing only after DNS is ready

The order matters. Zendesk explicitly warns that turning on digital signatures before adding the required CNAMEs can cause delivery failures. Complete and verify DNS for every external domain first.

Then follow the documented activation path: Admin Center → Channels → Talk and email → Email. In Email settings, select Custom domain for DKIM and save.

Do not confuse this outbound control with Authenticate emails received with SPF, DKIM, and DMARC alignment, which evaluates inbound customer mail. Changing an inbound protection setting does not repair your outbound signature.

The DNS guide describes a few hours to a day depending on TTL, but elapsed time is not proof: wrong authoritative records will not heal by waiting. The old example screenshot clips record text and shows a sample TTL; use the complete written targets above, not truncated image text or a universal TTL.

Record the enabled state and time. Preserve the DNS change history and previous configuration so the administrator can investigate a regression. Do not remove DKIM records as a first response to delivery trouble; first establish which support address and route failed.

Special case: authenticated SMTP delivery

Zendesk's outbound-only authenticated SMTP connector relays notifications through your domain's email service. The final server's authorization determines the receiver-facing SPF result. A Zendesk include alone cannot authorize an unrelated final sending IP.

Zendesk says it does not add its d=zendesk.com signature on this connector route. If custom-domain signing is enabled with the required CNAMEs, it can still sign with your domain. Your downstream service may re-sign, but must not accidentally invalidate the retained signature through content changes.

The connector's inbound route requires server-level automatic forwarding, not manual/client forwarding or an unsupported chain of multiple forwards. Have the routing owner approve the exact source mailbox and Zendesk destination before altering that path; this guide does not authorize MX replacement. Preserve the native Zendesk routing and loop-prevention headers through the outbound service.

Treat connector setup or migration as a separate change, not a shortcut inside this DNS procedure. Test with controlled recipients, verify final headers, and avoid making a new support address the default before it works. The connector documentation specifically cautions that an untested default can interfere with access and password-reset mail. For Microsoft Exchange users, Zendesk's current connector documentation recommends the Exchange connector rather than the authenticated SMTP connector because of authentication changes. Confirm the supported route with your mail administrator before migration; credentials and transport settings are outside this article's DNS scope. Do not use the same support address simultaneously in sandbox and production. If disconnecting this connector, coordinate a low-traffic window and test the resulting native-server fallback. The support-address API can help enumerate and remove addresses, but the native guide says it cannot add authenticated SMTP connector addresses: creation and credentials belong in Admin Center. Do not automate an unsupported migration or expose secrets in tickets.

Validate DNS, then a ticket notification

These are read-only command shapes. Replace every uppercase placeholder before use:

dig @AUTHORITATIVE_NAMESERVER zendesk1._domainkey.YOUR_SENDING_DOMAIN CNAME +short
dig @AUTHORITATIVE_NAMESERVER zendesk2._domainkey.YOUR_SENDING_DOMAIN CNAME +short
dig zendesk1._domainkey.YOUR_SENDING_DOMAIN CNAME +short
dig zendesk2._domainkey.YOUR_SENDING_DOMAIN CNAME +short
dig zendesk1._domainkey.zendesk.com TXT +short
dig ACTUAL_ENVELOPE_DOMAIN TXT +short
dig _dmarc.ACTUAL_FROM_DOMAIN TXT +short

Both CNAME answers should match the table's targets. Query the second target's TXT as well. Check authoritative responses and a public resolver; caching can delay agreement. A missing direct DMARC record on a subdomain can require inspecting the inherited policy, rather than immediately creating a conflicting new one.

Send an authorized ticket notification to a mailbox where raw source is available. Use test content without customer data. Inspect From, Return-Path, DKIM d= and s=, and the receiving server's authentication results. Establish how the recipient service strips or isolates/distinguishes externally supplied Authentication-Results fields, and ignore those untrusted fields. A familiar authserv-id or header position alone is not proof. Use the receiver's own results on its documented trusted path; if that boundary cannot be established, use receiver-controlled logs or message trace. RFC 8601 trust boundary

For this custom-domain DKIM workflow, the completion criterion is an explicit dkim=pass for the intended custom-domain signature aligned with the intended visible From, plus a trusted receiver dmarc=pass. A pass through SPF alone does not certify this DKIM setup. If the From has unexpectedly changed to a shared Zendesk fallback, a pass authenticates that fallback, not completion of the requested branded route. SPF can fail or be unaligned without defeating that DKIM-based pass. Independently investigate SPF fail, temperror or permerror even when DMARC passes through DKIM; a passing fallback does not make a broken authorization or routing configuration healthy. Repeat for each external domain, brand, and materially different connector route. Record the test event, timestamp, observed identities, and any failure response.

Where recipients forward notifications onward, compare a direct copy and a forwarded copy: SPF or signed content can change on that extra hop. Do not authorize arbitrary forwarders in your Zendesk SPF policy. Raw DKIM versus aligned policy results explains why a signature pass and policy pass are different evidence.

Preserve the domain's DMARC policy

Under RFC 9989, DMARC passes through aligned SPF or aligned DKIM. Strict alignment requires exact matching domains; relaxed alignment permits the same organizational domain. For final From help@example.com, a passing intended d=mail.example.com aligns in relaxed mode when both share the same Organizational Domain, but not strict mode. A passing d=example.com aligns in both. Check existing aspf and adkim values rather than loosening them. RFC 9989 DKIM alignment

A domain publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures. Indirect-mail interoperability still needs route testing; a successful ticket reply alone does not justify domain-wide enforcement changes. RFC 9989 Section 7.4

Keep an established DMARC policy, its reporting destination, and unrelated senders intact. Do not replace enforcement with p=none to fix Zendesk. If no applicable policy exists and the domain owner approves initial monitoring, create one TXT policy beginning v=DMARC1; p=none and append ; rua=mailto: with an approved, provisioned reporting mailbox. Preserve inherited policy too: do not create a weaker child override.

For From at example.com, the full owner is _dmarc.example.com, relative _dmarc in that zone. For From at support.example.com, full _dmarc.support.example.com is relative _dmarc.support in the parent zone, or _dmarc in separately delegated support.example.com. A delegated _domainkey zone is not the location of this DMARC policy.

For a reporting destination in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization before sending aggregate reports. Same-Organizational-Domain destinations are excepted; hostname inequality alone is insufficient. Separately obtain domain-owner approval of the aggregate recipient and data sharing, since protocol authorization is not privacy approval. RFC 9990 external authorization Omit ruf unless the recipient and message-information privacy handling are approved.

Maintain one DMARC record at a given owner. RFC 9989 supersedes RFC 7489 and removes pct, so do not plan enforcement around that obsolete percentage control. Confirm other business senders before changing a shared domain's policy. EmailAuth reporting can help isolate ongoing Zendesk failures, but aggregate reports complement rather than replace a fresh message test.

Save the approved DNS diff, service state, test timestamp/message identifier and redacted headers with a named support owner. If a change causes failure, pause affected sending or use a previously tested route under that owner's control; review queued notifications before retrying to avoid duplicates. Restore only the approved integration changes, retain keys needed by in-flight messages, and retest after rollback, rotation, domain or connector changes. Keep credentials and private keys out of handover records.

Troubleshooting and FAQs

Why is the SPF warning still present?

Check the external support domain, first-layer mail.zendesk.com include, duplicate SPF records, DNS resolution, and old include names. Preserve the rest of the policy while correcting the identified problem.

Why did signing cause failures?

Check whether the toggle was enabled before both CNAMEs resolved for every external domain. Verify exact names and targets, then investigate the failed message or bounce. Coordinate recovery with the mail administrator rather than deleting unrelated DNS records.

Why does one brand pass and another fail?

Different brands can use different support domains or outbound connectors. Compare their actual From domains and selectors, then repeat DNS and message verification for the failing route.

Can my own server send from a Zendesk-owned address?

No. Zendesk's DKIM documentation prohibits third-party sending on behalf of its subdomains. Use your own verified external domain and the appropriate route instead.

Does correct authentication guarantee delivery?

No. Receiver policy, recipient reputation signals, content, and routing still matter. A complete handover includes DNS evidence, activation state, and redacted delivered headers, with any untested routes clearly listed.