Zendesk SPF: setting up include:mail.zendesk.com the way Zendesk checks it

Zendesk is one of the SaaS senders where the SPF include does affect what the customer sees. Zendesk says it sends using its own domain "when we're not authorized to use your domain," and uses the client's domain only once a proper SPF record authorizes Zendesk. So if a client wants support replies to come from support@client.com instead of a zendesk.com address, the SPF record has to be right. Here's what Zendesk's help center documents.

The record Zendesk recommends

Zendesk's article on allowing Zendesk to send on behalf of your domain recommends:

```

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

```

That's the whole record for a domain where Zendesk is the only sender. Most client domains also send from Microsoft 365 or Google, so you merge the include into the existing record. Zendesk's own example combines Google and Zendesk:

```

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

```

Zendesk says the SPF specification requires one SPF record per domain, and that multiple records "may cause issues, and cause rejections of your email." RFC 7208 §4.5 is specific: more than one v=spf1 record is a permerror.

The rules Zendesk adds

Zendesk lists several conditions that are easy to miss:

• First layer only. "If you use include:mail.zendesk.com, then it must be in the first-layer lookup." Put it directly in the domain's own SPF record, not inside another include, such as a flattening service's or a parent record you include.
• Macros and redirect= are supported. Record flattening also works, but Zendesk says it "may be less stable than include:, redirect:, or macro syntax."
• Everything has to resolve. If the record includes other domains, "all domains must be valid and resolve through DNS successfully." One dead include can break verification.
• Hardfail is recommended. Zendesk leaves the choice to the domain admin, but recommends -all as "the greatest security against email spoofing."
• An invalid record can make verification fail. Zendesk says it can't administer customers' DNS, so this one lands with the MSP.

Zendesk says it attempts to verify the record when you add a support address in Zendesk.

Replace the outdated Zendesk includes

Zendesk used to suggest other values. Its article names include:smtp.zendesk.com and include:support.zendesk.com as outdated: "While they might still work, they're not the best option." Zendesk shows a warning flag if you still use them. When you find either in a client's record, replace it with include:mail.zendesk.com rather than adding the new one alongside it, which would spend an extra lookup for nothing.

Lookup cost

On Oct 13, 2026, a live DNS check showed that mail.zendesk.com publishes ip4 ranges only, with no nested lookups, so it costs one of the ten lookups RFC 7208 §4.6.4 allows. That's an observation, not a documented figure.

DKIM: what makes Zendesk mail pass DMARC

DMARC (RFC 9989) passes when SPF or DKIM passes and the authenticated domain aligns with the From: domain. Zendesk's tip at the end of the SPF article is to also sign outbound mail with DKIM. Its DKIM article has you publish two CNAMEs:

Then, in Admin Center → Channels → Talk and email → Email, you turn on Custom domain for DKIM.

Zendesk's warning about order is worth repeating to clients: enabling digital signatures "must be the final step," and turning it on before the CNAME records exist "will cause delivery failures." Publish the CNAMEs, wait for DNS (Zendesk says anywhere from a few hours to a day, depending on TTL), confirm they resolve, and only then flip the switch.

Aligned DKIM is also what RFC 9989 expects at p=reject. It says those domains must not rely solely on SPF.

Multiple brands, multiple domains

Zendesk accounts often serve several brands, each with its own support address, such as help@brand-a.com and support@brand-b.co.uk. SPF and DKIM are per domain, so every domain that appears in a Zendesk support address needs its own SPF entry and its own pair of DKIM CNAMEs. Authorizing one domain doesn't cover another. That includes country domains, and subdomains if you use them as support addresses. When you audit a client, list the support addresses in Zendesk first, then check each domain separately. A brand that was added last year and never authorized will keep sending from a Zendesk domain while the main brand looks fine.

Gmail connector note

If the client uses the Zendesk Connector for Gmail, Zendesk says setting up the SPF record is "recommended, but not required." It's still worth doing so behavior stays consistent if the client moves to a standard support address later.

A client checklist

• Find out which address Zendesk sends as (the support address), and its domain.
• Add include:mail.zendesk.com directly to that domain's single SPF record, replacing any smtp.zendesk.com or support.zendesk.com entry.
• Make sure every other include in the record resolves.
• Publish the two DKIM CNAMEs, wait for them to resolve, then enable Custom domain for DKIM.
• Send a test from Zendesk and confirm dkim=pass for the client's domain in the Authentication-Results header.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10, names common senders, and flags unresolvable includes, duplicate records and +all or ?all endings.

Founding Partner: $1,999, one time. Find the outdated vendor includes and broken records across your client base in one scan, then track the fixes. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →