How do spam filters work and why do good emails get caught?

A spam filter scores each message using many weak signals: sender authentication, blocklists, wording, statistics learned from past mail, and shared reputation data. Above a threshold the message is quarantined or rejected. Legitimate mail gets caught when its signals look wrong, usually because authentication records are missing or the sending pattern looks bulk.

What is a spam filter actually checking?

Email filtering is a pile of small tests, and no single one decides. The open source Apache SpamAssassin project is a good public example. It describes itself as a filter that classifies email and blocks spam, defined as unsolicited bulk email, using a scoring framework with plug-ins for heuristic and statistical analysis of headers and body text. Its listed techniques include text analysis, Bayesian filtering, DNS blocklists and collaborative filtering databases.

In plain terms:

• Rules and heuristics match patterns in headers and text, such as a mismatched sender name or a suspicious phrase.
• Bayesian filtering learns from messages people marked as spam or not spam, and scores new mail by how much it resembles each group.
• DNS blocklists let the receiver check whether the sending server's address is listed as a source of abuse.
• Collaborative databases share fingerprints of known spam across many receivers.

Each test adds or subtracts points. The final total is compared with a threshold. Administrators tune that threshold, which is why the same message can pass at one company and fail at another.

Where do SPF, DKIM and DMARC fit?

Email has no built-in proof of who sent a message. RFC 7208 states plainly that existing protocols place no restriction on what a sending host can use as the envelope sender, and defines SPF so a domain owner can publish which hosts may send for it. DKIM (RFC 6376) lets a domain attach a cryptographic signature that the receiver checks against a public key published in DNS. DMARC (RFC 7489) lets the domain owner state what receivers should do when messages fail those checks, from no action through altered delivery to rejection, and asks for reports back.

RFC 7489 is careful on one point: DMARC does not produce or encourage elevated delivery privilege of authenticated email. Passing authentication stops you from looking forged. It does not guarantee the inbox.

Why do good emails get caught?

The common causes are mundane.

1. Missing or broken authentication. A new sending service was added but not included in the SPF record, or its DKIM key was never published.
2. Misalignment. The visible From domain differs from the domain that passed SPF or DKIM.
3. Shared or poor sending reputation. A cheap bulk sender's address is on a blocklist because of other customers.
4. Bulk patterns. Sudden volume from a new address, many near-identical messages, or a link-only body.
5. Content flags. URL shorteners, mismatched link text, image-only messages.
6. Recipient history. If people often mark your mail as spam, statistical filters learn that.

A constructed example

A small company adds an invoicing tool that sends from the company's own domain. Customers stop receiving invoices. The cause: the tool signs with its own domain, not the customer's, and the company's SPF record does not list the tool's servers. Under a strict DMARC policy, receivers see a failure and quarantine or reject. The fix is to publish the tool's DKIM key under the company's domain and update SPF, then watch the DMARC reports to confirm that mail now aligns. This is an invented scenario, but the failure pattern is routine.

How to check or apply this

1. Look up your domain's SPF, DKIM and DMARC records and list every service that sends mail for you.
2. Start DMARC in monitoring mode and read the aggregate reports before tightening policy.
3. Send a test message to a mailbox you control and read the full headers for authentication results.
4. Check your sending IP address and domain against public blocklists.
5. Keep list hygiene: remove bounces and unengaged addresses, and make unsubscribing easy.
6. Separate transactional mail from marketing mail so one stream's reputation does not drag the other.
7. If a business-critical sender is blocked, ask the receiving admin for the filter's rejection reason rather than guessing.

Quick check

Sources

• Apache SpamAssassin project home page
• RFC 7208, Sender Policy Framework (SPF)
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Last reviewed: 18 October 2026.