Why Your Emails Land in Spam: A Teardown for People Who Aren't Developers

A founder messaged me last week with a familiar complaint: "I sent an invoice from our company email and the client said it landed straight in spam. We've never had this problem before."

Nothing about their email had changed. What changed was everything invisible around it — and that's the part almost nobody explains without fifteen acronyms in the first paragraph. So here's the teardown without those. No SPF, DKIM, or DMARC jargon until I've explained the idea it stands for in plain words first.

Think of email like physical mail, not a phone call

When you send a text message, it goes straight from your phone to theirs. Email doesn't work that way. It's more like posting a letter: it passes through several sorting offices (mail servers) before it reaches the recipient's mailbox. At every sorting office, someone glances at the envelope and asks one question — "is this really from who it says it's from?"

That question is the entire spam problem in a sentence. Spammers have always been able to write "From: yourbank@example.com" on an email the same way anyone can write a fake return address on a paper envelope. So mailbox providers (Gmail, Outlook, Yahoo) built a set of checks to verify the return address before they'll trust it. If your domain hasn't set those checks up, you look exactly like a spammer to the sorting office — even though every word in your email is genuine.

The three checks, explained without the acronyms

Check 1 — "Is this server allowed to send mail for this domain?"

Every domain can publish a public list of the mail servers allowed to send on its behalf — think of it as a company saying "only these three delivery trucks are authorized to drop off mail with our logo on it." When an email arrives, the receiving mailbox checks the sending server against that list. No list published, or the sending server isn't on it, and the email looks unauthorized on arrival.

Check 2 — "Was this message tampered with in transit?"

This one attaches an invisible, cryptographic seal to each outgoing email — like a wax seal on a letter that cracks visibly if anyone opens it before it arrives. The receiving server checks the seal against a key the domain has published. A missing or broken seal doesn't just mean the email might have been altered; the bigger problem is unsealed mail simply reads as lower-trust from the start.

Check 3 — "What should happen to mail that fails the first two checks?"

This is a policy the domain owner publishes, telling every mailbox provider in the world what to do with mail that fails checks 1 and 2: let it through anyway, mark it as suspicious, or reject it outright. Most small businesses have never set this policy at all — which means mailbox providers fall back to their own judgment, and their judgment skews toward "when in doubt, spam folder."

That's it. Three checks, three plain questions: who's allowed to send, was it tampered with, and what happens if something fails. (Their real names are SPF, DKIM, and DMARC, in case you ever need to say them to a developer — but you don't need the names to understand the problem.)

What the actual teardown looked like

I ran the founder's domain through a checker and found the pattern that shows up in maybe eight out of ten "why is my email going to spam" cases:

Check 1 existed but was incomplete — the list of authorized senders only included their old email provider from two migrations ago. Their current provider wasn't on it, so every email they sent was technically unauthorized.

Check 2 wasn't configured at all — no cryptographic seal, so every email arrived looking unsealed by default.

Check 3 didn't exist — no policy at all, meaning mailbox providers were making a judgment call on every single message with zero guidance from the domain.

None of this was caused by anything the founder did wrong in the moment. It accumulated silently over two provider migrations and about three years, the way a lot of infrastructure debt does — nobody breaks it on purpose, it just never gets revisited after the initial setup.

Why this matters more than it looks like it should

A broken authorization setup doesn't just cost you the one email that landed in spam. Mailbox providers build a running trust score for every sending domain, based on how consistently your mail passes these checks. Every failed check nudges that score down a little. Enough failed checks, and all your mail — including the messages that would otherwise have sailed straight into someone's primary inbox — starts getting treated with suspicion. It's less "one bad email" and more "a slowly declining credit score for your domain."

The fix, once you know what's actually broken, is usually a few DNS records — genuinely a 20-minute task for whoever manages your domain, not a re-architecture. The hard part was never the fix. It was knowing which of the three checks was actually the problem, since the symptom (mail in spam) looks identical no matter which one failed.

Check your own domain

I built Email Health Checker for exactly this — it runs all three checks against any domain and explains what's missing in plain English, not a wall of DNS record syntax. It's free, takes about ten seconds, and doesn't require you to know what SPF, DKIM, or DMARC stand for before you can act on the result.

If you've ever had someone tell you "your email went to my spam folder" and had no idea why, that's the ten seconds worth spending.