Why a domain that passes every check still lands in spam

Passing every record check is the floor

A domain with a valid SPF record, aligned DKIM signing and a DMARC policy of reject has established one thing: messages claiming to be from it can be attributed to it reliably. That is a precondition for good placement and not a cause of it.

Attribution is what makes the rest possible. Until a receiver can be sure which domain sent a message, it has nowhere to file the reputation it builds, so an unauthenticated sender is judged largely on the address it connected from. Once authentication is in place, the receiver has a stable identity to accumulate a history against — and that history, not the records, is what decides where the next message goes.

What actually decides placement

Inbox placement is a per-receiver judgement, made against several inputs that are largely invisible from outside your own systems.

Sender reputation is held both on the sending IP address and on the sending domain, and the two are separate: moving to a new address does not reset a poor domain reputation, and a clean domain on a badly behaved shared address inherits the problem. Volume patterns matter, because a domain that sends fifty messages a day and suddenly sends fifty thousand looks like a compromise regardless of intent.

Recipient behaviour is the input with the most weight at large mailbox providers, and the one senders most often ignore: whether people open the mail, reply to it, move it out of spam, mark it as spam, or delete it unread. Complaint rate and the rate of delivery to addresses that no longer exist are both tracked. The message content and the domains it links to contribute, as does whether the mail resembles other mail the recipient has engaged with.

What a seed test measures

A seed test — also called a placement test — sends a copy of a message to a set of mailboxes held across several providers and reports which folder each copy landed in. It is the only way to observe placement directly, because no receiver publishes it and no header records it.

Used well, it is a comparative instrument. Run the same test before and after a change and the difference tells you something real: whether a template change, a new sending address or a fixed authentication problem moved placement at a given provider. It is also the fastest way to detect an outright block, which shows as consistent absence rather than a spam folder.

What a seed test cannot tell you

• Where your actual recipients' copies landed. A seed mailbox is a different mailbox with a different history at the same provider.
• Anything about engagement, because seed accounts never open, reply to or file mail. At providers that weigh engagement heavily, a seed result is a measurement of a sender with no relationship at all.
• A percentage that generalises. A result across a few dozen seeds is not a rate across a list of hundreds of thousands, and treating it as one produces a number with no meaning.
• Per-recipient filtering, which is personal. Two people at the same provider can genuinely get different outcomes for the same message.
• Which tab a message lands in at providers that categorise the inbox, which is a categorisation decision rather than a filtering one and is often reported inconsistently.
• Why. A seed test reports an outcome and no reasoning; the diagnosis has to come from the records, the headers and the score.

What SenderProbe's inbound test measures

SenderProbe's inbound deliverability test is a diagnostic of one message, not a multi-provider placement test, and it is worth being clear about the difference. The workspace gives you an address, you send a message to it, and the message is analysed as a receiving server would analyse it.

The result is a score out of ten, together with the spam-filter total and the threshold that would have blocked it, broken into four sections: filter, authentication, blacklist and content. That answers what a receiver would find wrong with this message, sent from this host, using these records. It does not claim to answer which folder a specific provider would have used, because that depends on a reputation history no test can stand in for.

The two are complementary rather than alternatives. The inbound test tells you what to fix; observed placement tells you whether fixing it changed anything.

Reading the result

Start with the authentication section, because a failure there invalidates the interpretation of everything else — a receiver that cannot attribute the message is judging it far more harshly than the content rules alone suggest.

Then read the blacklist section, which is binary and actionable in a way the rest is not: either the connecting address is listed or it is not, and if it is, that is the first thing to resolve. Then read the filter total against its threshold, paying attention to the margin rather than the number. Finally read the content findings, which are the slowest to change and the most likely to be structural to a template rather than specific to a message.

Re-test after each change rather than after all of them. The point of a diagnostic is to attribute an improvement to a cause, and a batch of six simultaneous changes tells you only that something worked.

When everything passes and placement is still poor

This is the ordinary case for a sender whose records are correct, and the remaining causes are almost always about behaviour and history rather than configuration — list hygiene, bounce handling, complaint rate and how recipients respond.

Separating traffic by subdomain is the one structural change worth making early, because it is the only way to stop the reputation of one kind of mail deciding the fate of another. Each subdomain gets its own DKIM selector and inherits the parent's DMARC policy unless it publishes its own.

• List quality. Addresses acquired without explicit consent produce complaints and spam trap hits, and no configuration change outweighs that.
• Bounce handling. Continuing to send to addresses that have returned a permanent failure is one of the most reliable ways to be filtered.
• Complaint rate. Register with feedback loops where a provider offers them, and act on what they report by removing the complainant immediately.
• Mixing traffic. Sending transactional receipts and bulk marketing from the same domain means the reputation of the marketing decides where the receipts go. Separate them onto distinct subdomains with their own DKIM selectors.
• A sudden volume change on an address with no history. Warm up gradually rather than starting at full volume.
• Engagement decay. A list that was clean two years ago and has not been pruned since is now a list of people who do not open your mail, which is itself a signal.
• Shared sending infrastructure. On a shared address, another customer's behaviour is part of your reputation, and the only fix is a dedicated address with its own warm-up.

; transactional mail, kept away from bulk reputation
mail.example.com.                3600 IN TXT "v=spf1 include:_spf.example.net -all"
s2026a._domainkey.mail.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; bulk mail, with its own selector and its own history
news.example.com.                3600 IN TXT "v=spf1 include:_spf.example.org -all"
bulk2026._domainkey.news.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."