Zendesk SPF and DKIM
Zendesk sends mail as you, from servers that aren't yours. Without a Zendesk SPF record and DKIM signing, receiving providers have every reason to be suspicious.
The problem these records solve
When Zendesk sends a reply on your behalf, the From address says support@yourcompany.com but the connection comes from Zendesk infrastructure. To a receiving mail server, that is structurally identical to someone forging your domain.
The receiver has two questions. Is this sender allowed to send for this domain, and has the message been altered in transit. SPF answers the first. DKIM answers the second. Get them wrong and your replies arrive in junk, get quarantined, or bounce outright depending on the receiver's policy.
Consumer providers have tightened this considerably for bulk and automated senders. Support mail is exactly the shape of traffic that gets filtered when it's unauthenticated, which is why this dull piece of DNS config has real operational consequences.
The Zendesk SPF record: one record, all the includes
SPF is a single TXT record on your sending domain that lists which servers may send mail for it. Zendesk publishes an include mechanism you add to your existing record. The exact string is in the Zendesk documentation and you should copy it from there rather than from a blog, because it has changed before.
The shape of the record looks like this:
; one TXT record on the domain, all senders inside it
v=spf1 include:<your mail provider> include:<the include Zendesk documents> ~allThree rules that catch people out.
DKIM, keys and selectors
DKIM signs outbound mail cryptographically. The receiver fetches your public key from DNS, checks the signature, and knows the message came from an authorised system and was not modified on the way.
Zendesk generates the keys for you. Your job is publishing the records it shows you, under selector names it gives you. The shape is roughly:
<selector>._domainkey.yourcompany.com CNAME <target Zendesk shows you>
<selector2>._domainkey.yourcompany.com CNAME <target Zendesk shows you>Never copy selector names or key values from anywhere except your own Zendesk admin screen. They are account-specific. Two selectors are usually published so keys can be rotated without an outage, and it is worth checking the current Zendesk docs for whether your account uses CNAME or TXT records, since providers differ.
DNS propagation isn't instant. Publish, wait, then enable signing in Zendesk. Enabling before the records resolve produces signed mail that fails verification, which is worse than not signing at all.
DMARC and the alignment catch
DMARC is the policy layer. It tells receivers what to do when authentication fails and sends you aggregate reports about who is sending as your domain. Start on monitoring, read the reports for a few weeks, then tighten.
The subtlety that catches experienced admins: DMARC requires alignment, not just a pass. It is not enough that SPF passes for some domain, it has to pass for a domain that matches your visible From address. A setup where SPF authenticates a vendor's bounce domain rather than yours will show green on a basic SPF test and still fail DMARC. DKIM alignment behaves the same way, which is one reason DKIM tends to be the more reliable of the two once forwarding is involved.
Verifying it actually works
Do not trust the setup screen alone. Test end to end.
If you're setting up support email from scratch, the Zendesk email setup guide covers the forwarding versus custom address decision that sits upstream of all this. And when your replies do get filtered, the follow-on effect shows up in your spam and suspended queue as customers writing in again through another channel.
Frequently asked questions
Is SPF enough on its own for Zendesk email authentication?
No. Zendesk email authentication needs SPF and DKIM together, because DMARC alignment checks the signing domain, and SPF alone will not satisfy it.
Do I need both SPF and DKIM for Zendesk?
Yes, in practice. They prove different things and major receivers increasingly expect both, plus a DMARC record. SPF alone is fragile once mail is forwarded anywhere.
Can I have two SPF records?
No. One TXT record per domain, with every include inside it. Two records is one of the most common causes of total SPF failure, and it fails silently until someone reads a header.
What is the Zendesk SPF include value?
Take it from the current Zendesk documentation or your admin screen rather than from a third-party page. Zendesk has changed the value before and a stale include is a live outage.
Why do my Zendesk replies still land in spam?
Check alignment rather than just pass or fail, confirm you have not exceeded the SPF lookup limit, and read a DMARC report. Content and sending reputation matter too, but authentication is the first thing to eliminate.
How long does DKIM take to work?
As long as your DNS TTL, so anywhere from minutes to a day. Publish the records first, confirm they resolve, then enable signing in Zendesk.
Filtered replies become second tickets
When a customer never sees your answer, they write in again. Ticket Merger catches the duplicate that creates.
Start free trial14-day free trial. No credit card required.