False positives and ham protection

A false positive is a legitimate message that a filter files as spam. Across the entire literature of spam filtering, this is treated not as a minor error but as the error - the one worth designing the whole system around. And it is the error a sender has the most power to prevent, because the things that cause it are mostly the deterministic, controllable signals: authentication, consistency, consent, and list hygiene.

This page pulls together, from the rest of this library, how false positives actually arise at each layer of the filtering stack and what a legitimate sender does about each one. It is the defensive counterpart to the mechanism pages: not “how to beat a filter,” but “how to not look like the thing the filter is built to stop.”

The 60-second version

• Every serious filter treats a false positive as far worse than a missed spam - Graham called missing legitimate mail “an order of magnitude worse” than receiving spam.
• False positives are not random. The big causes are broken authentication, inconsistent sending identity, look-alike bulk content, no recipient consent, and triggering connection-level deferrals.
• The single highest-leverage control is authentication (SPF, DKIM, DMARC) - it is deterministic, you own it, and it generates ham-protective score reductions.
• Bulk is not spam, but it looks identical to spam to a near-duplicate filter. The defense is genuine consent plus being whitelisted, which every collaborative system supports.
• Filters build in ham-protective machinery - negative-scoring rules, whitelist flags, not-spam operations - and your job is to make that machinery fire for you.
• A filter’s idea of “ham” is learned from the wanted mail your recipients already accept, so consistency with that baseline matters.

Why false positives dominate the design

This is unanimous across the sources, and it explains why filters behave the way they do. Graham (2002): “For most users, missing legitimate email is an order of magnitude worse than receiving spam, so a filter that yields false positives is like an acne cure that carries a risk of death to the patient.” He sharpened it in 2003, treating false positives as bugs rather than a tunable rate: “I approach improving the filtering rate as optimization, and decreasing false positives as debugging.”

The academic work formalized the same intuition. Androutsopoulos et al. modeled the asymmetry with a cost parameter λ, where blocking a legitimate message is λ times worse than passing a spam, and found that in the harshest scenario (λ = 999, blocked mail deleted unrecoverably) the naive-Bayes filter “is not viable” without additional safety nets - concluding that “additional safety nets are needed for the Naive Bayesian anti-spam filter to be viable in practice.”

Two consequences follow for senders. First, filters are deliberately biased toward letting mail through (recall Graham’s doubled ham counts and innocent-leaning defaults in Bayesian spam filtering) - so a legitimate message has the benefit of the doubt if it does not generate spam-like signal. Second, the most dangerous false positives are the ones Graham described: “False positives yielded by statistical filters turn out to be mails that sound a lot like spam.” If your legitimate mail reads, looks, and behaves like bulk spam, you are forfeiting the very bias designed to protect you.

How false positives arise, layer by layer

Each layer of the pipeline (see How receiver-side spam filtering actually works) has a characteristic way of misclassifying good mail. Knowing the cause points straight at the fix.

Layer	How a legitimate message gets misfiled	The sender-side cause
Connection / greylisting	Deferred or failed on a temporary 4xx	MTA doesn’t retry; identity changes between attempts
Authentication	Score penalty or DMARC failure	Missing/misaligned SPF, DKIM, or DMARC
Bayesian content	High token probability	Content that statistically resembles spam; token-stuffing
Collaborative / fuzzy	Counted as bulk	Bulk mail without consent or whitelisting
Scoring decision	Total crosses the receiver’s threshold	Accumulated small spam-like signals, no ham-protective offsets

Connection-level deferrals

Greylisting returns a temporary failure to unknown senders (see Greylisting, tarpitting, and rate controls). A correctly behaving sender retries and gets through; the false-positive risk is entirely about behaving correctly. RFC 6647’s documented failure modes are a sender checklist in disguise: MTAs that don’t retry, that treat a 4xx as a permanent bounce, that retry from a different outbound IP, or that use per-message VERP return-paths all make a legitimate retry look like a brand-new (and therefore re-greylisted) sender. The fix is standards-compliant retry plus a stable identity.

Authentication

This is the highest-leverage layer because it is deterministic and yours. Both major engines convert authentication results into score adjustments - SpamAssassin via its SPF, DKIM, and DMARC plugins, Rspamd via its parallel authentication stage with caching. A pass subtracts points (ham-protective); a hard failure adds them. Aligned SPF, DKIM, and DMARC are the closest thing to a sender-controlled “vouch for me” signal in the whole stack. (See DMARC in 2026 for the authentication detail.)

Bayesian content

A statistical filter assigns your message a spam probability from tokens (see Bayesian spam filtering). False positives here come from content that statistically resembles spam - and from self-sabotage. Graham’s finding that obfuscation backfires (c0ck scoring worse than the plain word) generalizes: trying to dodge “spam words” with creative spelling, excessive punctuation, or hidden text makes you look more spammy, not less. The defense is to write like the legitimate mail your recipients already accept, because that is literally what the filter’s ham corpus is made of.

Collaborative and fuzzy

This is where well-run bulk senders most often get hurt, and the cause is structural, not content-based: wanted bulk looks identical to unwanted bulk. A double-opt-in newsletter accumulates the same DCC counts, Pyzor reports, and Rspamd fuzzy weights as a spam blast of equal size (see DCC, Pyzor, and Razor and Fuzzy hashing and near-duplicate detection). DCC is explicit that “only mail targets can say whether a message is solicited,” and that rejection “generally requires a whitelist of solicited bulk mail sources.” You cannot declare yourself wanted; the recipient does. The defense is genuine consent so recipients don’t report you, plus the whitelist paths below.

The ham-protective machinery you should make fire

Filters do not only look for spam - they build in explicit mechanisms to protect wanted mail. A sender’s job is to be eligible for them.

• Negative-scoring rules. SpamAssassin rules can carry negative scores (“negative = ham-like”), and its default plugin set includes ham-protective ones like WelcomeListSubject and WLBLEval. A valid DKIM signature, a recognized welcome-list subject, or good local reputation each pull the total down.
• Whitelist flags. Rspamd reserves FUZZY_WHITE (flag 3) for legitimate content with a negative weight, and supports IP-based whitelists that bypass fuzzy checks entirely.
• Not-spam operations. Pyzor includes an explicit whitelist-as-not-spam action alongside report-as-spam; DCC recipients whitelist solicited bulk “by adding your IP address, SMTP envelope sender, RFC 2369 SMTP List-* headers, or other characteristics of your mail.”
• Authenticated-submission exemption. RFC 6647 says greylisting “SHOULD NOT be applied… for authenticated client hosts.”

The thread running through all of these: they key off stable, recognizable sender characteristics - your IP, your envelope sender, your List-* headers, your DKIM domain. Consistency is what lets a recipient or a receiver pin a whitelist entry to you.

What a legitimate sender actually does

Synthesized from the above, the practices that prevent false positives - all sender-side, all sourced to mechanisms in this library:

1. Authenticate completely and consistently. Aligned SPF, DKIM, and DMARC. This is the one deterministic, sender-owned layer that generates ham-protective signal at every engine.
2. Keep a stable sending identity. Consistent outbound IPs, envelope sender, and List-* headers. Stability is what whitelists, reputation tracking, and greylisting databases latch onto; churn looks like a new (untrusted) sender every time.
3. Send only with genuine consent. Consent is the only thing that separates wanted bulk from spam in the eyes of collaborative networks, because the content and volume are indistinguishable.
4. Practice list hygiene. Honor unsubscribes promptly, remove hard bounces, and keep complaint rates low - complaints and spam-traps are exactly the reports that drive up your collaborative-network signal.
5. Don’t try to dodge content filters. No token-stuffing, hidden text, or obfuscated “spam words” - it raises your statistical score, per Graham’s own findings.
6. Retry correctly on temporary failures. Standards-compliant 4xx handling so greylisting costs you one delay, not a lost message.
7. Be recognizable enough to get whitelisted. Everything above compounds into the outcome that actually protects bulk senders: recipients and providers add you to their not-spam lists instead of reporting you.

A note on what you cannot control

Honesty matters here, because over-promising is its own failure. You cannot lower a stranger’s Bayesian token probabilities, change their score threshold, train their classifier, or tell their DCC server your mail is solicited. The content and collaborative layers are largely out of your hands. That is precisely why the deterministic layers must be flawless: the controllable signals (authentication, consistency, consent) are the only ones you can guarantee, so they have to carry the weight. And no amount of sender-side discipline makes any filter perfect - the same research that prizes low false-positive rates also shows the content layer can be fooled (the LLM-rephrasing result in Bayesian spam filtering), which is exactly why receivers run layers and why your authentication and reputation matter even when content scoring slips.

What this means for you, and what Egressif does

False positives are the failure mode senders fear most and influence most. The levers are unglamorous and entirely on the sending side: authenticate properly, send consistently, get genuine consent, keep lists clean, retry correctly. Do those and you arrive at every receiver’s filter generating the ham-protective signals the system was built to reward.

Egressif’s work is precisely those controllable layers - aligned SPF/DKIM/DMARC, a stable and recognizable sending identity, standards-compliant retry behavior, and list hygiene that keeps complaint rates low. The aim is straightforward: when your mail meets any filter, the negative-scoring rules and whitelist paths fire in your favor and there is nothing spam-like to accumulate. We do not claim to eliminate false positives - no one honestly can - and we cannot reach into another operator’s filter. What we can do is make sure your mail never gives one an easy reason to misclassify it.