Most mail that lands in spam was not flagged for its content. It was flagged because the sending domain failed one of three authentication checks: SPF, DKIM, or DMARC. Those three records, published in the domain’s DNS, tell receiving servers whether the message is genuinely from who it claims to be from. Content still matters, but authentication decides delivery first, and a sender with broken records will lose mail that a sender with clean records delivers without effort.
The Three Checks at a Glance
| Check | What it proves | Where it lives | Typical failure |
|---|---|---|---|
| SPF | The sending server is authorized by the domain | A TXT record listing allowed servers | Server not on the list |
| DKIM | The message was not altered after sending | A public key in DNS, matched against a signature in the headers | Signature missing or invalid |
| DMARC | SPF or DKIM matches the visible From domain, and states what to do on failure | A TXT record at _dmarc | No policy, or alignment fails |
Think of them as three separate jobs. SPF is the guest list. DKIM is the wax seal. DMARC is the written instruction for what the receiver does when either of the first two fails.
SPF: The Guest List
SPF (Sender Policy Framework) is a TXT record on the sending domain that lists the servers allowed to send mail for it. When a message arrives, the receiving server looks up the domain’s SPF record and checks whether the connecting server’s IP address appears on it. A match passes. An unlisted server fails, and the message is treated as suspicious.
Two details break SPF more than any others. First, every tool that sends mail for a domain must be on the list: the mailbox provider, the newsletter platform, the support desk, the shop’s order system. A marketing tool added in an afternoon without an SPF update starts failing checks the same day.
Second, SPF lookups are capped at 10 DNS queries per check, a limit set by the standard. Records that chain through many third-party includes can exceed that cap and fail with a “permerror” even though every server on the list is legitimate.
Forwarding also breaks SPF, because the forwarding server is rarely on the original domain’s list. That is why a message can pass when sent directly to you and fail when it reaches you through a forwarded address.
DKIM: The Wax Seal
DKIM (DomainKeys Identified Mail) works differently. The sending server signs selected headers and the body with a private key and attaches the signature to the message. The domain publishes the matching public key in DNS. The receiving server verifies the signature, and a valid signature proves the signed content was not altered in transit.
DKIM survives forwarding better than SPF, because the signature travels with the message rather than depending on the sending server’s address. It breaks when a mailing list or gateway rewrites the subject line, adds a footer, or otherwise changes signed content. That is a common cause of legitimate list mail landing in spam: the list modified the message after it was signed, and the signature no longer matches.
DMARC: The Rulebook
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together and adds a policy. It requires alignment: either SPF or DKIM must authenticate a domain that matches the domain in the visible From address. A message can pass SPF for one domain and still fail DMARC if the From header shows a different one, which is exactly the trick used in lookalike-domain phishing.
A DMARC record also states a policy: p=none means report only and take no action, p=quarantine means send failures to spam, and p=reject means refuse them outright. Domains can also ask for aggregate reports (rua), which receiving servers send back, showing which servers are passing and failing. The safe rollout is none first, watching reports to find every legitimate sender, then quarantine, then reject.
Why Gmail and Yahoo Started Enforcing Them
In February 2024, Gmail and Yahoo began requiring bulk senders — those sending roughly 5,000 or more messages a day to Gmail accounts — to authenticate with SPF and DKIM, publish a DMARC record, and support one-click unsubscribe. Google also publishes a spam-rate bar: bulk senders should keep user-reported spam below 0.1% and must stay under 0.3%.
Smaller senders are not held to the bulk-sender bar, but the same checks still shape their delivery. A small shop with no SPF record and no DKIM signature now looks, to a receiving server, like the phishing mail those rules were written to stop. Authentication has moved from best practice to the price of admission.
What a Reader Can and Cannot Fix
A reader cannot fix a sender’s broken records, and no amount of marking “not spam” repairs a domain with no DMARC policy. What a reader can do is teach their own filters and remove their own obstacles:
- Mark a wrongly filtered message as “not spam” — this trains the filter for that sender
- Add regular senders to contacts, which most providers treat as a trust signal
- Create a filter that routes a trusted sender’s mail to the inbox and never to spam
- Check blocked-address lists and old filters that may be diverting mail
- Check account storage: a full mailbox stops new mail from arriving at all
If mail from one sender vanishes while everything else arrives, the sender’s authentication is the prime suspect, and the fix belongs to them. If mail from many senders lands in spam, the reader’s own filters, blocks, or storage are worth checking first.
Final Verdict
Spam filtering looks like a judgement about content, but most of the decision is authentication. SPF proves the server is authorized, DKIM proves the message is intact, and DMARC proves the visible sender matches the authenticated one and states what happens when it does not. Senders who publish all three and keep complaint rates low reach the inbox. Readers who understand the three checks can tell, in minutes, whether a missing message is their problem or the sender’s — and that distinction decides whether the fix is a filter or an email to the sender’s support desk.
