Why Your Emails Land in Spam (It's Three DNS Records, Not Bad Luck)

The quote went out on Tuesday. On Thursday the customer rang to chase it. You resent it while they were on the phone, and they found it that time — in Junk, under a yellow banner warning them that the message might not have been sent by you.

If you’ve had that call, you know the feeling that follows. You start writing shorter subject lines. You take the word “free” out of the newsletter. You wonder whether the new email tool is “bad”. None of it helps, because none of it is the problem.

Here’s the reframe: spam filters aren’t judging your writing. They’re checking your paperwork. Whether a message reaches the inbox is decided mostly by two things — whether the receiving server can verify who sent it, and what it has learned about that sender’s reputation. The first is three DNS records you can read for yourself in five minutes. The second is unlocked by the first. And the reason so many small-business emails go to junk is that the paperwork was never filed.

Email never checked who you were. Now it checks whether your domain vouched for you

Email is a 1980s design. The From: line on a message is a plain text field — anyone, anywhere, can put your address in it and press send. There is no built-in mechanism that verifies it. For the first few decades of the internet this was merely embarrassing. Then phishing turned it into the most exploited weakness in business communication.

So receiving servers — Google, Microsoft, Apple, your customer’s IT department — stopped trusting the From: line and started asking a different question: does this message’s domain vouch for it? They ask by looking up records in the Domain Name System, the public directory that already tells the world where your website lives. If your domain has published a note saying “these are the servers allowed to send as me, here’s how to verify my signature, and here’s what to do if a message fails”, the receiver can check. If it hasn’t, the receiver is left to guess — and guessing against you is the safe guess.

An analogy that holds up: a letter arrives on your company letterhead. The postmaster phones your office to confirm you actually sent it. If nobody answers — if there’s no number on file — the letter goes on the pile marked suspicious. Not because it looked bad. Because nobody vouched for it.

One detail that matters later: every email actually carries two sender addresses. There’s the visible one your reader sees in the From: header, and there’s the “envelope” address — called the Return-Path — that mail servers use behind the scenes for bounces. Different checks look at different ones, and the gap between them is where a lot of businesses quietly fail.

SPF: the guest list

SPF (Sender Policy Framework) is a single line of text published in your DNS that lists which servers are allowed to send mail using your domain. It looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Read it as a bouncer’s guest list. include:_spf.google.com says “anything Google sends for me is fine”. include:sendgrid.net admits a second service. The -all at the end means “and nobody else”. (A softer ~all means “anybody else is probably not me” — receivers treat it as a shrug, and shrugs don’t help you.)

The traps are mundane and constant:

Somebody’s not on the list. Your mailbox provider is on it, because they set it up. But the invoicing tool that emails receipts? The booking system? The CRM your salesperson signed up for last spring? The website’s contact-form handler? Every one of those sends messages that claim to be from your domain, and every one you forgot has failed SPF since the day it was switched on.

The list is too long. SPF allows at most ten DNS lookups while it’s being evaluated — every include: counts, along with the includes inside those includes. Businesses accumulate tools for years, cross the limit without noticing, and SPF stops returning “pass” or “fail” and starts returning “permanent error”. Every receiver treats that as a fail. Nobody gets notified.

There are two lists. A domain must have exactly one SPF record. When a second one appears — typically because a new tool’s setup guide said “add this TXT record” and someone did, rather than merging it into the existing one — both become invalid.

And the subtle one: SPF checks the envelope address, not the visible one. A message can pass SPF for some other domain entirely and still show your name in the reader’s inbox. Which is why SPF on its own never stopped anybody impersonating you, and why two more records exist.

DKIM: the signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. Your sending server signs the message with a private key; the matching public key is published in your DNS under a name like selector._domainkey.yourdomain.com; the receiver fetches it and checks the signature. A pass proves two things at once: the message wasn’t altered in transit, and whoever signed it controls your domain’s DNS. That’s a strong claim, and receivers weigh it accordingly.

The “selector” is just a label, and it’s why you can have several DKIM keys at once — one per tool. Your mailbox provider signs with one, your newsletter platform with another, both published under your domain. That’s the correct setup. Here’s the incorrect one, and it’s the default almost everywhere:

The tool signs with its own domain instead of yours. Most email platforms will happily send your campaigns with a valid DKIM signature — for their domain. The signature passes. It just says nothing about you. Gmail flags this with a small “via” label next to your name (Your Company via mailchimpapp.net, that sort of thing), which is Gmail politely telling your customers it couldn’t confirm the message came from you. Every serious sending tool has a settings page called something like “authenticate your domain” that fixes this with two or three DNS records. It’s the step most people skip.

There’s one more reason you need DKIM even with a perfect SPF record: forwarding. When your customer’s old address auto-forwards to their new one, the message arrives at the final server from the forwarder’s machine — which isn’t on your guest list. SPF fails, through no fault of yours. DKIM survives forwarding, because the signature travels with the message. The two checks cover each other’s blind spots, which is exactly why the third record demands at least one of them.

DMARC: the instruction, and the receipts

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that ties the other two together and gives them teeth. It lives at _dmarc.yourdomain.com and, in its simplest useful form, looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

It says three things. First: to be treated as legitimate, a message using my domain in the visible From: must pass SPF or DKIM — and the check that passed must be for my domain, not some tool’s. That matching condition is called alignment, and it’s the entire point: it closes the gap between the envelope address and the visible one. Second, the policy — p= — tells receivers what to do with a failure: none (deliver it anyway, just tell me), quarantine (send it to spam), or reject (refuse it outright). Third, rua= asks receivers to email you a daily report of everything they saw claiming to be you.

Those reports are the receipts. They arrive as XML — unreadable raw, but any of the free DMARC report processors will turn them into a table — and that table lists every server on earth that sent mail as your domain in the last 24 hours, with pass and fail counts. It’s how you discover the accounting tool nobody added to SPF. It’s also how you discover the criminal in another country sending fake invoices as “you” — because they show up too.

Now the part that changed the stakes. Since early 2024, Google and Yahoo have required senders to authenticate: SPF or DKIM at minimum for everyone, a reported spam rate kept under 0.3% for everyone, and for anyone sending more than about 5,000 messages a day to their users, SPF and DKIM, a DMARC record, an aligned From:, and one-click unsubscribe on marketing mail. Microsoft applied matching rules to Outlook, Hotmail and Live addresses from May 2025. You might never send 5,000 emails in a day. It doesn’t matter: the same machinery scores everyone, the floor of what “normal” looks like has moved, and a domain with no DMARC record now looks less legitimate than it did three years ago without having changed a thing.

If the ten characters of configuration in our post on invisible websites was noindex, the equivalent here is a DMARC record left on p=none for three years because someone meant to come back to it. It tells receivers you monitor nothing and enforce nothing — and it tells attackers your domain is free to borrow.

The website is often the culprit

Here’s the case that surprises business owners most, because it has nothing to do with newsletters. It’s an illustrative composite, not a named client, but every developer who’s worked on contact forms has met it.

A firm’s website has a contact form. To make it convenient, whoever built it set the enquiry email to arrive From the customer’s own address — so the owner can just hit Reply. Sensible-looking. Also, technically, a forgery: the website’s server is now sending a message that claims to be from customer@yahoo.co.uk, and Yahoo’s DMARC policy is reject, and has been for years. The owner’s mailbox does exactly what Yahoo asked and bins it. The customer who filled in the form never hears back. The owner never knows there was a form submission. The business’s own inbox is rejecting its own enquiries, on behalf of a third party, and nothing errors anywhere.

The related failure is quieter still. Many websites — WordPress by default among them — send form notifications straight from the web server itself, using whatever address the software makes up, from an IP address that isn’t in your SPF record and with no DKIM signature at all. That’s a message that fails every check described above. Some get through on shared-hosting goodwill. Then the host’s IP picks up a bad reputation from a neighbour’s hacked site, yours stop arriving, and there’s no error to see.

Both fixes are the same shape: the form should send from an address on your own domain, through a service that’s on your SPF record and signs with your DKIM key — your mail provider’s SMTP, or a transactional email service — with the customer’s address in the Reply-To field so Reply still works. It’s an hour’s work. It’s also the single most common thing we find when someone tells us their site “gets no enquiries”. (We covered the silent contact form from the maintenance angle in Your Website Is Quietly Falling Apart; this is the mechanism underneath it.)

Reputation: what authentication unlocks

A mistake worth heading off: authentication doesn’t get you into the inbox. It gets you identified. Once receivers can be sure a message is yours, they can hold you accountable for it — and start keeping score.

The score is reputation, and the inputs are fairly well understood:

Complaints. People clicking “report spam”. Google publishes the thresholds: aim to stay under 0.1%, and never reach 0.3%. Nothing else on this list recovers you quickly from a bad complaint rate.
Bounces. Sending to dead addresses is what spammers do, because they buy lists. If more than a couple of percent of a campaign hard-bounces, your list needs cleaning before your reputation does.
Engagement. Opens, replies, and — weighted most heavily — people moving your message out of spam or into the inbox. Recipients vote, and receivers count.
Consistency. A new domain that goes from ten emails a day to ten thousand looks like a compromise, because that’s usually what it is. Volume is warmed up gradually, on purpose.
Content. Less than folklore suggests. Filters gave up on keyword-matching years ago; “FREE!!!” doesn’t sink an authenticated sender with a clean reputation, and a beautifully written message from an unauthenticated one still won’t land. Content matters mainly when it’s the only signal available — which is precisely the position an unauthenticated sender is in.

Two practices follow from this. Marketing mail should go out from a subdomain (news.yourdomain.com, say) so a rough campaign can’t drag down the domain your quotes and invoices come from. And you should be looking at the score: Google’s free Postmaster Tools shows your domain’s reputation, spam rate and authentication pass rates for mail sent to Gmail users — which, for a UK business, is a large share of your customers.

How professionals actually diagnose it

The reason this is fixable rather than mysterious is that, like the crawling and indexing pipeline, it leaves receipts. The professional workflow is dull:

Send a message to a Gmail account, open it, and choose “Show original”. The top of that screen prints three lines — SPF, DKIM, DMARC — each marked PASS or FAIL, along with which domain each check passed for. This single screen settles most arguments. Three passes with your own domain on the DKIM line is the goal; a DKIM pass for mailchimpapp.net is the “via” problem from earlier.
Read the DNS directly. On Windows, nslookup -type=txt yourdomain.com prints your SPF record; nslookup -type=txt _dmarc.yourdomain.com prints your DMARC record, or nothing. Any of the free online lookup tools will do the same and count your SPF lookups for you.
Switch on DMARC reporting and read a week of reports. This is the audit of who’s actually sending as you, and it’s the only reliable way to find the tool you forgot.
Inspect every sending tool’s “domain authentication” page. Newsletter platform, CRM, invoicing, booking, helpdesk. Every one should show green ticks for your domain — not theirs.
Test the website form end-to-end and read the headers of whatever arrives: which From, which Return-Path, which checks passed.
Check Postmaster Tools for reputation and spam rate, and check the sending IP against the public blocklists if you’re on shared hosting.

“Have we been blacklisted?”

It’s the version of “have we been penalised?” that email people hear, so let’s deal with it directly. Genuine blocklisting of a legitimate business domain is rare, and it almost always follows a compromise: a hacked website used to send spam, a mailbox with a stolen password, an unprotected form being used as a relay. If that’s happened, you’ll usually see it in the DMARC reports (thousands of messages you didn’t send), or your host will have told you. Fix the compromise first; the delisting follows.

Far more often you haven’t been blacklisted. You’ve been unauthenticated or unaligned — which is mechanical, checkable, and fixable in an afternoon with the records above. The remedies are different, so it’s worth knowing which one you have before spending a week on the wrong one.

The 20-minute self-audit

No tools to install. You need a Gmail address you can send to, and access to your domain’s DNS (usually wherever you bought the domain).

Send a test from your business address to Gmail, then open “Show original”. SPF, DKIM, DMARC: three PASSes? Is the DKIM domain yours?
Look up your SPF record. Exactly one? Does it name every service that sends as you? Does it end in -all? Fewer than ten lookups?
Look up _dmarc.yourdomain.com. Missing is your first to-do. Present but p=none with no rua= address means you’re monitoring nothing.
Open each tool that sends as you and find its domain-authentication page. Green ticks all round, or a “via” label waiting to happen?
Submit your own website contact form. Did it arrive? Inbox or junk? Open its headers: which address is it from, and what passed?
Sign up for Google Postmaster Tools and verify your domain. Note your domain reputation and spam rate.
Pull the bounce and complaint rates from your last campaign. Hard bounces above 2% or complaints above 0.1% mean the list needs work before anything else does.
Check what your marketing mail goes out from — your main domain or a subdomain — and whether unsubscribing takes exactly one click.

Twenty minutes, and you’ll either have a clean bill of health or a short, specific list — either of which beats another quarter of rewriting subject lines.

If that list produced more red than you’d like, Zayn will run the full check for free: SPF, DKIM and DMARC reviewed and corrected, your website’s form delivery tested end-to-end, every sending tool aligned to your domain, and the reputation numbers explained in plain English. Book a call and we’ll show you exactly what your customers’ mail servers see when your name arrives.

Your customers aren’t ignoring you. Their inbox just can’t tell it’s you.