Email deliverability: why your mail lands in spam

Mail lands in spam when the receiving server's filtering stack decides it cannot sufficiently trust the message — and that decision is built from layers: is the sender authenticated, what is the sending domain's and IP's track record, is the infrastructure configured like a real mail operation, and does the content look like what recipients want. No single record fixes deliverability, but the layers are not equally weighted, and most of the heavy ones are things a domain owner directly controls.

This guide walks the receiver's decision stack in honest proportion — including the parts vendors tend to overstate — and ends with what you can actually do about each layer.

The receiver's decision stack

When your message arrives at Gmail, Microsoft 365, or any serious mail operation, it passes through roughly this evaluation:

Layer	The question being asked	Who controls it
Authentication (SPF, DKIM, DMARC)	Is this really from the domain it claims?	You
Domain and IP reputation	What has this sender's mail been like historically?	You (domain), partly your provider (IP)
Blacklists (DNSBLs)	Is the sending IP or domain on a known-bad list?	Mostly your provider
PTR / FCrDNS	Does the sending server identify itself consistently?	Your provider
Content and engagement	Does this look like mail recipients want?	You

None of these is a binary gate on its own (with the partial exception of authentication, below). They combine into a score, and the folder decision falls out of the score.

Authentication: the closest thing to a hard gate

SPF, DKIM, and DMARC prove your mail is really yours. For years they were "best practice"; the major mailbox providers have since made them entry requirements. Google and Yahoo began enforcing sender requirements in 2024: all senders to Gmail need SPF or DKIM and a valid PTR record, and bulk senders (5,000+ messages/day) need SPF and DKIM and a DMARC policy, plus one-click unsubscribe and a spam-complaint rate under 0.3%. Microsoft followed with equivalent requirements for Outlook consumer domains in 2025.

Authentication does not get you into the inbox — plenty of perfectly authenticated spam exists. It keeps you out of the failure path, and it is the foundation reputation is built on: without it, the good history your mail earns cannot be reliably attributed to your domain.

Domain and IP reputation

Receivers keep history. How often is mail from this domain marked as spam? Opened? Deleted unread? Sent to addresses that do not exist? That history — domain reputation and IP reputation — is the biggest ongoing factor in the folder decision, and it moves slowly in both directions.

If you send through a hosted provider or ESP, the IP reputation is largely theirs (shared with their other customers, for better or worse). The domain reputation is entirely yours, follows you across providers, and cannot be reset by switching services. It is the asset the rest of this guide is really about protecting.

Blacklists: real, but smaller than the panic

DNS blacklists (DNSBLs) list IPs and domains observed sending spam. A listing on a major list — Spamhaus above all — genuinely hurts. But two facts put blacklists in proportion. First, hundreds of DNSBLs exist and most carry little or no weight with real receivers; being listed on an obscure list usually means nothing. Second, if you send through a major provider, the sending IPs are theirs — a shared-pool listing is your provider's problem to fix, not something you can fix in DNS.

Check the big lists, ignore the noise, and treat an unexplained major-list listing as a symptom to investigate rather than the disease itself.

PTR and FCrDNS: the handshake test

A legitimate mail server's IP address resolves backwards to a hostname (the PTR record), and that hostname resolves forwards to the same IP — forward-confirmed reverse DNS, or FCrDNS. Servers that fail this test look like compromised machines, and some receivers (Gmail explicitly) refuse or heavily penalize their mail. If you use hosted email, your provider handles this and you will never think about it. If you run your own mail server, it is a hard prerequisite — and it is set where your IP lives (your hosting provider), not in your domain's DNS.

Content and engagement

Last and — despite the folklore — least mechanical: the message itself and how recipients react to it. Modern filters lean far more on engagement (complaints, opens, deletes, replies) than on trigger words; the era of "FREE!!!" keyword-matching is long gone. The content layer is mostly a proxy for a simpler question: did these people ask for this mail, and do they want it? No DNS record fixes a "no" there.

The compounding cost of p=none

One deliverability cost is easy to miss because nothing visibly breaks: a DMARC policy of p=none (or no DMARC at all) means anyone on the internet can send mail with your domain in the From: line, and receivers will deliver it.

Spoofed mail gets marked as spam — recipients are not fools — and those complaints accumulate against the domain being displayed: yours. Your legitimate mail then sends into a headwind you cannot see the source of. The longer a spoofable domain is worth spoofing, the worse the compounding. This is the deliverability case for reaching DMARC enforcement, separate from the security case — and the reason p=none should be a phase with an exit, not a resting state. The safe path up is the staged one in the DMARC guide; the data that paces it comes from DMARC reports.

The silent killers: domain and certificate expiry

Two failure modes sit outside every deliverability guide because they are not gradual — and both are just calendar dates:

• Domain registration expiry. When the registration lapses, DNS goes with it: MX, SPF, DKIM, DMARC, everything, at once. Inbound mail starts bouncing; outbound authentication collapses. Renewal usually recovers it within days, but expired domains are also snapped up by squatters — and a domain that briefly resolved to a parking page does its reputation no favors.
• SSL/TLS certificate expiry. An expired certificate will not, by itself, route your mail to spam. But mail full of links to a site throwing browser security warnings reads as phishing to recipients and filters alike, and an expired certificate on the mail server can break inbound delivery for senders enforcing TLS. It is the cheapest possible signal of an unmaintained operation.

Both have the same fix: know the dates before they arrive. Monitoring for them is trivial — which is exactly why lapses are embarrassing.

Two myths that waste your time

"We have SPF, so we're authenticated"

SPF alone verifies an address your recipients never see, and it breaks on forwarded mail — the details are in the SPF guide. Without DKIM and DMARC alignment, SPF does not even protect your visible From: address from forgery, and it no longer meets the major providers' bulk-sender requirements. SPF is one leg of a three-legged stool; a one-legged stool is a stick.

"We're in spam, so we must be blacklisted"

The blacklist check is worth doing — it takes seconds — but it is the least likely explanation for an SMB on hosted email, whose sending IPs belong to Google or Microsoft and are not sitting on Spamhaus. The likelier culprits, in order: an authentication problem (a broken SPF record, unaligned DKIM), a domain reputation problem, or a recipient-engagement problem. Chasing blacklist removal forms while an SPF PermError sits unfixed is the classic misdiagnosis.

Diagnose before you fix

Everything in the stack that belongs to your domain is mechanically checkable: the three authentication records and their alignment, MX configuration, DNS health, presence on the blacklists that matter, and both expiry dates. That is precisely the seven-check scan below — SPF, DKIM, DMARC, MX, DNS, blacklist, and domain/SSL expiry in one pass, with the failing check identified rather than guessed at. Run it first; fix in order of what it finds.