Plan requirement
| Subscription | Any plan |
| Access | Admin |
Three DNS records decide whether your replies reach inboxes or spam folders. One is needed, the second is strongly recommended, the third is optional.
What each does
- SPF lists who may send mail for your domain, and Zendesk has to be in that list. This is the one that has to be right; Zendesk checks it for you when you add a support address.
- DKIM signs each message so the receiver can verify it was not altered and did come from you. Strongly recommended rather than required, and the difference between arriving and arriving reliably. Unlike SPF, this one goes in as CNAME records rather than a TXT record, which catches people out.
- DMARC tells receivers what to do when the first two fail, and can send you reports. Optional, and the one to add once the other two are in place. Start it at p=none, which watches without rejecting anything, and move to p=quarantine or p=reject only once the reports show your legitimate mail, Zendesk's included, passing SPF and DKIM. Going straight to reject is how a company blocks its own post.
Set them up
- Open Admin Center, then Channels, then Talk and email, then Email.
- Find the records Zendesk shows for your domain.
- Add them at your DNS provider.
- Wait for propagation. Zendesk asks for up to 48 hours before a changed record verifies, so a check the same afternoon proving nothing is not a fault.
- Return to Zendesk and verify.
The SPF mistake
A domain may have only one SPF record. If you already have one for your own mail, Zendesk is added to it rather than published separately. Two SPF records is worse than none, because receivers treat that as an error and both are ignored.
Adding rather than publishing separately has one consequence: an SPF record may resolve at most ten DNS lookups, and every include spends some of them. A domain already sending through a mail provider, a newsletter tool and a CRM can pass that ceiling the moment Zendesk is added, and the record then fails while looking perfectly reasonable.
The include to use is mail.zendesk.com, so a domain sending only through Zendesk reads:
v=spf1 include:mail.zendesk.com -all
Check what you inherited. Two older includes still turn up in records set up years ago: smtp.zendesk.com and support.zendesk.com. Both are out of date, and Zendesk flags them as such rather than failing outright, so an account can sit for years with a record that technically resolves and is not the one it should be.
Per domain, not per account
Each domain you send from needs its own records. Adding a second brand on a different domain means doing this again, and forgetting is why a new brand's mail lands in spam while the first brand's is fine.
Why it is not optional
Large mail providers increasingly reject or filter unauthenticated mail outright. Without these records a growing share of your replies never arrives, and nobody tells you: the customer thinks you did not answer.
There is a second reason now, and it points the other way. Zendesk also checks authentication on incoming mail, forwarded mail included. Where that check is already on, it applies now. Where it is off, Zendesk begins switching it on from 23 September 2026. So the same records that decide whether your replies arrive also decide whether mail forwarded from your own domain reaches your queue instead of the suspended list. One set of records, both directions.
DNS is often managed elsewhere in the organisation. Send us the records Zendesk gave you and we will help you and your DNS administrator get them right first time.
Comments
0 comments
Article is closed for comments.