When a support reply lands in a customer’s spam folder, it’s rarely the content. It’s authentication. Three DNS records, SPF, DKIM, and DMARC, tell receiving mail servers that a message claiming to be from your domain is really yours. Get them right and your mail is trusted. Get them wrong and even a perfectly normal reply looks like a forgery.
Here’s what each does, without the jargon.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are permitted to send mail for your domain. When a receiver gets a message from you, it checks the sending server against that list.
A record looks like:
v=spf1 include:_spf.google.com include:spf.example-sender.com ~allEach include authorizes a sending service (your email host, your help desk’s mail provider, your newsletter tool). The ~all at the end means “anything not listed is suspicious but not an outright fail.”
The most common mistake: SPF allows only one include chain to be flat-resolved within a 10-DNS-lookup limit. Stacking too many services can silently break it. Keep it lean and only include services you actually send through.
DKIM: a tamper-proof signature
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. Your sending service holds a private key; you publish the matching public key as a DNS record. The receiver recomputes the signature and confirms the message genuinely came from your domain and wasn’t altered in transit.
SPF checks the envelope (the server). DKIM checks the message itself. That distinction matters because email gets forwarded, and forwarding breaks SPF but not DKIM. This is why DKIM is the stronger signal of the two, and why both matter.
DMARC: the policy that ties them together
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when SPF or DKIM fail, and asks them to report what they see.
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.comp=nonemeans “monitor only, don’t block.” Start here.p=quarantinesends failing mail to spam.p=rejectblocks it outright.
DMARC also requires alignment: the domain in the visible From address has to match the domain that passed SPF or DKIM. This is the piece people miss. You can pass SPF and DKIM and still fail DMARC if the aligned domain doesn’t match your From.
The order to roll this out
- Publish SPF and DKIM first through your email/help-desk provider. Most provide the exact records to paste into DNS.
- Add DMARC at
p=noneand watch the reports for a week or two. You’ll see every service sending as your domain, including ones you forgot about. - Tighten to
p=quarantine, thenp=rejectonce the legitimate sources all pass. Don’t jump straight to reject, or you’ll block your own mail.
A note on Google Groups and forwarding
If your support address is a Google Group, the group rewrites the From for strict-DMARC senders (you’ll see “X via Group”). That’s normal and expected. What matters is that your outbound replies are signed for your domain. A help desk that sends through a provider with your domain’s DKIM verified will pass alignment cleanly.
The takeaway
Deliverability isn’t luck. SPF says who can send, DKIM proves the message is genuine, and DMARC sets the policy and reports the results. Set up all three, roll DMARC out gradually, and your support mail earns the trust it deserves.
teckyz verifies your sending domain (DKIM and Return-Path) as part of setup, so replies from your support address are authenticated out of the box. See the FAQ or start a trial.