Why your email lands in spam

First signal: is this sender on a list?

Blacklists are the fastest signal a receiver has, so they are consulted first. Lists like Spamhaus ZEN, Barracuda and SpamCop track addresses observed sending spam, hosting botnets or running exploitable servers, and a listing lets a receiver refuse or folder your mail without reading a word of it. If your server's address is listed, nothing downstream matters much: your SPF can be perfect and your message a masterpiece, and the mail still dies at the gate. That is why the first diagnostic for any spam problem is the blacklist checker — it asks ten IP lists about your domain's addresses and three domain lists about the domain itself, from the server's own resolver, the way a receiving server would ask.

Two reading skills matter in the result. The first is weighting: a ZEN or Barracuda listing is a fire, because those lists feed a large share of the world's mail servers; a listing on a small or backscatter-only list may be a footnote, and sometimes describes a neighbour's sins more than yours — shared hosting and freshly reassigned cloud addresses both inherit history. The second is honesty about gaps: a list that fails to answer has given no verdict, and any checker that reports a timeout as "not listed" is inventing good news. Treat an errored list as unknown, fix real listings by removing their cause before requesting delisting — operators refuse, or instantly relist, addresses that are still dirty — and remember that if a provider sends your mail, the addresses that matter are theirs, not your web server's.

Second signal: can the domain prove it?

Suppose the gate opens. Now the receiver asks whether the message is genuinely from the domain in its From header, and it asks DNS, not the message. SPF answers "which servers may send for this domain?" — a list published as a TXT record. DKIM answers "can this message prove it?" — the sending server signs the message, and the receiver verifies the signature against a key the domain publishes. DMARC is the judge that makes the other two count: it requires the visible From domain to align with an SPF or DKIM pass, states the penalty for mail that aligns with neither — monitor, quarantine, reject — and collects the aggregate reports that tell a domain owner who else is sending as them, which is how most spoofing is discovered. The email deliverability check reads all three records and returns the findings in fix order.

What receivers conclude from each combination is brutally simple. No SPF means anyone can claim to be you. No DMARC means failed claims have no stated consequence, and nobody is watching. DMARC at reject, backed by aligned SPF and DKIM, means forged mail is refused and reported — the configuration every serious sender is expected to reach, and the one that makes your legitimate mail the only mail that can successfully wear your name.

One word in that paragraph does more work than the rest: aligned. SPF can pass for the wrong domain — it validates the bounce-address domain, which a mailing platform sets to its own — and DMARC still fails, because the domain that passed is not the domain in the From header your reader sees. This is the single most common reason legitimate mail from a new provider fails DMARC while "SPF is set up": the provider is authenticated as itself, not as you. The fixes are the two standard ones — a custom bounce subdomain so SPF aligns, or DKIM signing with your domain, which survives forwarding and is the stronger of the two — and the aggregate reports are how you spot which senders need them, one misaligned stream at a time.

The traps inside records that look fine

The cruellest spam problems live in setups whose owners believe they are done, because each trap below passes a casual look. An SPF record ending in +all authorises the entire internet to send as the domain — worse than no record, because the permission is official. Two SPF records, often left behind when a second provider is added, void SPF evaluation entirely: the standard allows exactly one. Lookup drift is subtler still — evaluating a record costs DNS lookups for every include and redirect, the limit is ten, and each vendor's included record can grow beneath yours, so a record that was legal at setup can drift over the limit and start returning permanent errors without anyone editing it. And DMARC left at p=none is the most common trap of all: monitoring mode is a sensible first step and a useless final state, collecting reports about abuse that it instructs receivers to deliver anyway.

On the DKIM side, the trap is a false negative in your own checking: keys live under selector names the owner chooses, probing the common selectors finds the keys of major providers, but a key under any other name is invisible from outside. "No selector found" is a reason to check your provider's settings and a received message's headers — never proof that a domain does not sign.

Fix in this order

Work the signals in the order receivers weigh them. First, the listings: check them, fix the cause of any real one — a compromised account, an open form, a vulnerable server — and only then request delisting. Second, the records: merge multiple SPF records into one, end it with -all, count its lookups, and keep the count under ten with headroom. Third, DMARC: publish p=none with a reporting address if you have nothing, read the reports until every legitimate sender aligns, then climb — quarantine, then reject, applied to 100 percent of failing mail. Fourth, DKIM: confirm signing is actually happening, from a real message's Authentication-Results header rather than from settings screens. Each step is small; skipping the order is what wastes weeks, because enforcing DMARC before the senders align breaks real mail, and delisting before the fix guarantees a relisting.

What no record check can tell you

Honesty about the boundary matters. These checks cover identity and measurable reputation — the fixable, mechanical causes of spam placement, and in practice the majority of them. They say nothing about whether people want your mail. Complaint rates, engagement, list hygiene and sending patterns are reputation too, accumulated invisibly inside each big receiver, and no DNS query can read them. If authentication passes, the lists are clean, and mail still folders, the problem is there: in who you send to, how the list was built, and whether recipients open or complain. Fixing that is slower and less mechanical — wanted mail, consistently sent, to addresses that asked for it. The records get your mail believed; only the sending earns it the inbox.

Frequently asked questions