Why your email keeps going to spam — and the three DNS records that fix it

You send an invoice, a booking confirmation, a reply to a customer — and it quietly drops into their spam folder. Or worse, it never arrives at all. You rewrite the subject line, avoid the word "free," and it keeps happening.

The content is almost never the problem. The problem is that the receiving mail server can't prove your message actually came from you — so it treats it like it might be a forgery. Fixing that is three DNS records. Here's what each one does, in plain terms.

The core idea: proving mail is really yours

Email was designed in a more trusting era. By default, anyone can send a message that claims to be from your domain — that's what spammers and phishers do all day. To fight it, receivers (Gmail, Outlook, everyone) now ask three questions about incoming mail, and each maps to a DNS record you control.

1. SPF — "who is allowed to send for me?"

SPF (Sender Policy Framework) is a DNS record that lists the servers permitted to send email using your domain. When mail arrives, the receiver checks: did this come from a server on the list?

It's a single TXT record that looks like v=spf1 include:amazonses.com ~all — "mail from Amazon SES is legitimate for me; be suspicious of anything else." If you send through Google Workspace, Microsoft 365, your CRM, and a newsletter tool, they all need to be in there. A missing sender is a message that fails the check.

2. DKIM — "was this message tampered with, and is the signature really mine?"

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. Your mail provider signs with a private key; the matching public key lives in your DNS. The receiver uses it to verify two things: the message wasn't altered in transit, and it was signed by someone holding your key.

This is the strongest of the three, because a signature is hard to fake. It's usually a few CNAME or TXT records your provider hands you.

3. DMARC — "what should you do if the first two fail, and tell me about it"

DMARC ties SPF and DKIM together and sets your policy: if a message claiming to be from your domain fails both checks, should the receiver let it through, quarantine it (spam folder), or reject it outright? A record like v=DMARC1; p=quarantine says "quarantine the fakes." It also sends you reports, so you can see who's sending as you — including impersonators.

The gotcha that trips almost everyone up: alignment

Here's the part the DIY guides skip. SPF and DKIM passing isn't enough — they have to align with the domain your customers actually see in the "From" line. It's entirely possible to have all three records in place and still get quarantined, because the authenticated domain doesn't match the visible one. Getting alignment right is the difference between "I added the records" and "my mail actually lands."

That's why this looks simple but bites people: the individual records are easy to paste in; making SPF, DKIM, and DMARC all pass and align for every service you send through is the fiddly part.

What to do

If your business email is landing in spam, don't touch the copy — check these three records first. Set up SPF for every service that sends as you, enable DKIM signing, and publish a DMARC policy. Start DMARC at p=none to watch the reports without affecting delivery, confirm your real mail passes, then tighten to quarantine.

Do it right and your invoices land in the inbox, your domain gets harder to impersonate, and you stop losing customers to a spam folder they never check.

Not sure whether your domain is set up correctly — or watching real mail disappear? I can check it and fix it.