Gmail Filtering Internals

The Gmail sender requirements tell you what Gmail checks; this article covers what Gmail does with the result — how placement is actually decided. Two facts dominate everything below and explain why Gmail deliverability resists one-size diagnosis:

1. Reputation is computed on the authenticated sending domain, not the IP — the reverse of most IP-centric receivers. Authentication is the prerequisite that makes a message scoreable at all.
2. Placement is per-user and learned. The same message from the same sender can inbox for one recipient and spam-folder for another, because Gmail lets a user's own report/mark history override the sender's general reputation. There is no single "am I inboxing at Gmail?" answer — only a distribution across recipients.

This is documented, not inferred, primarily from Google's own research (Taylor, CEAS 2006; Taylor/Fingal/Aberdeen, NIPS 2007) and its help and blog pages. The 2006 paper describes a beta-era system; mechanisms have since been rebuilt on machine learning (see ML classification), but the paper is the only place Google has laid out the reputation logic concretely, and its principles — authenticated-domain scoring, user-vote self-correction, a middle band handed to a statistical filter — still describe how the system behaves. Treat the formulas as illustrative of the model, not as today's live code.

The authenticated-domain reputation model

Source: "Sender Reputation in a Large Webmail Service", Bradley Taylor, Google — CEAS 2006 (Third Conference on Email and Anti-Spam). Gmail launched as a beta in April 2004; this describes the reputation system built during that beta.

Why the domain, not the IP

Google rejected IP reputation as the primary key because the IP "is a crude form of authentication": the same sender may not always use the same IP; the connecting IP is not always the true sender because of forwarding; IPs in Received headers can't be authenticated reliably; and multiple domains sharing a set of IPs mean one spamming domain "can ruin the reputation for all the other domains." Instead Gmail classifies mail based on who is sending (the authenticated domain) rather than what the content is. Gmail was noted as "the only one" major reputation system operating on the authenticated domain rather than the IP.

Authentication methods used to establish the domain, and their observed mix on inbound Gmail:

SPF authentication method	Share of SPF-authenticated mail	Mechanism
Plain SPF	52%	Published SPF record
Best-guess SPF	38%	No/failing SPF: assume authenticated if sending IP is in the same range as the domain's A/MX records, or if the sending IP's reverse-DNS name matches the domain claimed in the email
PTR zone	10%	If plain and best-guess both fail: if the sender is a subdomain of the PTR's DNS zone, treat it as if it came from the zone itself (e.g. subdomain.example.com from an IP with PTR host.example.com)

DomainKeys (the predecessor to DKIM) was the other signal; Gmail was an early adopter, motivated partly because SPF breaks under forwarding while a signature survives. Google's recommendation then and now: implement both, so if forwarding or message-munging breaks one, the other still authenticates — "if both are present, it is that much stronger of an authentication signal."

Authentication rates diverged sharply between wanted and unwanted mail — authentication is itself a reputation signal:

Method	Nonspam (wanted)	Spam (unwanted)
Both SPF and DomainKeys	20%	1.5%
SPF only	53%	39%
DomainKeys only	1%	0.5%
Not authenticated	26%	59%
Authenticated (any)	~75%	~40%

How the reputation number is computed

Every delivered message logs an event with its classification and authentication. Four counters accumulate per authenticated domain:

Variable	Meaning
autononspam	times mail from this sender went to the inbox automatically
autospam	times mail from this sender went to the spam folder automatically
manualnonspam	times a user hit Not Spam on this sender
manualspam	times a user hit Report Spam on this sender

Reputation is a number 0–100 — "you can think of the reputation as the probability that a given sender's mail is not spam." 0 is most spammy, 100 most nonspammy.

good       = autononspam + manualnonspam − manualspam
total      = autospam + autononspam
reputation = 100 × good / total

The refined version clamps the manual terms so a small number of votes can't dominate, and guards against divide-by-zero (if total = 0 there is no reputation):

manualnonspam2 = min(autospam,    manualnonspam)
manualspam2    = min(autononspam, manualspam)
good2          = autononspam + manualnonspam2 − manualspam2
reputation     = 100 × good2 / total

Worked examples from the paper:

• weliketospam.com sends 100 spams; 60 land in the spam folder automatically, 40 slip into inboxes as false negatives → reputation 40. 30 users then mark the missed spams → reputation drops to 10.
• weneverspam.com sends 100 messages; 5 wrongly hit the spam folder as false positives → reputation 95. 3 users unmark them → reputation rises to 98.

The reputation doubles as an expected false-positive rate: a sender with reputation 2, given a spam-folder threshold set below reputation 5, means "about 2% of the time you'll have false positives on that sender's mail."

Self-correction, vote-weighting, and recovery dynamics

• Reputations are computed over many days, so a solid domain "can build up a very solid reputation" and "a little blip of spam ... is absorbed as noise." The flip side: a domain that spams for a long time and later cleans up takes a few days to recover.
• Both the Report Spam and Not Spam buttons are critical. Feeding in only spam reports gives the reputation no way to adjust upward after a filter mistake — it can't self-correct. Google calls having both buttons "critical for the success" of the system.
• Not every user votes, and votes are rate-limited. Only a subset of users — "the ones that will provide the best information" — are counted; users who never report spam or nonspam are excluded. To stop heavy-mail users from dominating, each user is limited to one spam report per domain per hour, i.e. up to 24 votes per domain per day.

How the reputation is used (the three-way split)

After authenticating the sender and computing the domain reputation:

1. Reputation above a threshold → deliver all the sender's mail to the inbox.
2. Reputation below a threshold → send all of it to the spam folder.
3. In between (or unknown) → pass the message, along with the reputation value, to a statistical spam filter that makes the final judgement on content.

Crucially, a user can override the general policy for individual sender addresses — this is the documented root of per-user placement divergence.

What the reputation distribution looked like

• Spammy domains cluster tightly around 0; wanted-mail domains cluster in the 90–100 range. Legitimate bulk senders scoring below 90 are "a reflection of less-than-ideal sending practices" — not-quite-good hygiene shows up as a middling score, not a zero.
• Selected domain reputations (2006, illustrative of the model): aol.com 98.5, yahoo.com 95.6/95.0 (SPF/DK), hotmail.com 95.4, ebay.com 95.2 (SPF) vs 98.2 (DomainKeys), earthlink.net 93.3 (SPF) vs 98.0 (DK); flagged spam domains 1.5–3.3.
• The ebay.com SPF/DomainKeys gap is instructive: eBay signed only its transactional mail with DomainKeys, and transactional mail "would likely be more wanted by users than other mail," so the signed stream scored higher — an early illustration of stream separation paying off (see advanced IP segmentation and sending infrastructure practices).

Documented failure modes and the sender rules that follow

Problems the paper calls out, all still live concerns:

• Forwarding: users forward mail (including spam) with tools like procmail that rewrite the envelope sender; the forwarded spam then authenticates as the forwarder and "hurts the reputation of the forwarding domain unfairly." Hence: don't authenticate mail you are only forwarding unless you've filtered spam out first — signing it means taking responsibility for the resulting stream. This is the same problem ARC later addressed.
• Mailing lists: a list domain (the paper's example is Yahoo Groups, signed yahoogroups.com) can carry a good aggregate reputation while individual groups within it are spammy; a blanket trust "will allow some spam through." Also, users often find reporting a list as spam easier than unsubscribing, which hurts the list sender's reputation "worse than it needs to be" — an argument for prominent, low-friction unsubscribe (see List-Unsubscribe).

Recommended sender policies from the paper:

1. Authenticate with both SPF and DomainKeys/DKIM (you may already have best-guess SPF implicitly).
2. Do not authenticate mail you are only forwarding unless you filtered spam first.
3. Keep spammers and zombies off your network and observe good bulk-sending practices — "if a sender is doing something bad such as using single opt-in instead of double opt-in, it simply translates into a poor reputation and a greater likelihood of ending up in the spam folder." Enforcement of Gmail's bulk guidelines is by the users, expressed through the reputation, not by a rulebook.

ML spam and phishing classification

The reputation model above answers "is this sender trusted?"; the content verdict for everything in the ambiguous middle band is made by machine-learning classifiers that have been rebuilt and re-scaled repeatedly.

• "The War Against Spam: A Report from the Front Line" — Taylor, Fingal, Aberdeen, NIPS 2007 Workshop on Machine Learning in Adversarial Environments — frames Gmail spam filtering as a real-world adversarial-ML success story: the overwhelming majority of spam is positively identified with high precision (few false positives). The adversarial framing matters: spammers adapt, so filters must retrain continuously rather than run a fixed ruleset.
• 2014 — TensorFlow-scale rebuild. Google's rule-based filters had reached ~99% accuracy; from 2014 Google augmented them with machine-learning algorithms built on TensorFlow that "continuously regenerate" the spam filters, finding new patterns and adapting "far quicker than previous manual systems." Reported outcome: more than one billion Gmail users avoid spam at roughly 99.9% effectiveness.
• 2017 security-model claims (Google, May 31 2017): over 99.9% accuracy blocking spam and phishing; 50–70% of all mail Gmail receives is spam; classifiers combine thousands of spam, malware and ransomware signals, plus attachment heuristics and sender signatures. Phishing defenses integrate Google Safe Browsing with reputation and similarity analysis on URLs; an early phishing detection model can selectively delay risky messages for deeper analysis, affecting less than 0.05% of messages on average. Click-time warnings, external-reply warnings, and defenses against ransomware/polymorphic malware round it out.
• 2024 — LLM classifiers. Google deployed a large language model trained on phishing, malware and spam that blocks 20% more spam and reviews 1,000× more user-reported spam daily, plus a second "supervisor" model that evaluates hundreds of threat signals when a risky message is flagged. See holiday tightening below.

Sender implication: the classifier is a moving target trained on the aggregate of what users report. There is no content whitelist to satisfy — the filter is optimizing for what users treat as wanted. This is the mechanistic basis for the content guidance in content and design for deliverability: pattern avoidance plus engagement optimization, not a keyword checklist.

Inbox categorization (the tabs)

Categorization is a separate, post-acceptance decision from the spam/inbox verdict. A message that has already earned the inbox is then sorted into one of five default categories (Gmail's "Default" inbox type). Landing in a category tab other than Primary is not a deliverability failure — Promotions is inbox, not spam.

Category	Google's definition
Primary	"Emails from people you know and messages that don't appear in other tabs."
Social	"Messages from social networks and media-sharing sites."
Promotions	"Deals, offers, and other promotional emails."
Updates	"Automated confirmations, notifications, statements, and reminders that may not need immediate attention."
Forums	"Messages from online groups, discussion boards, and mailing lists."

Mechanics:

• Users enable/disable categories via Quick Settings → Default inbox type → Customize; disabling categories entirely requires switching to a different inbox layout. Because the recipient controls which tabs exist, a sender cannot assume any given recipient even has a Promotions tab.
• Senders cannot pre-select a tab. Recipients recategorize by drag-and-drop (with an Undo), which teaches Gmail their preference so it will "sort your email more accurately" over time — again a per-user override.
• Asking engaged readers to drag you to Primary is legitimate and effective; see content and design for the content factors (personalization, conversational style, restrained image/link counts) that push toward Primary vs Promotions.

Category prediction as an ML problem

Source: "Email Category Prediction" — Zhang, Garcia Pueyo, Wendt, Najork, Broder (Google, WWW 2017 Companion). Key points relevant to senders:

• ~90% of consumer email is machine-generated — the target of categorization is templated mail (shopping receipts, promotional campaigns, booking confirmations, bill reminders), not person-to-person mail.
• The approach exploits template discovery and the "causal threads" of email sequences — legitimate machine mail follows predictable patterns (order → shipping confirmation → delivery alert). Predictable, template-consistent sequences classify cleanly; erratic structure does not.
• Model comparison: neural networks (MLPs, LSTMs) vastly outperform a Markov-chain baseline, with LSTMs slightly ahead of MLPs. Named downstream applications include calendar population, shipment alerts, targeted advertising, and spam detection — i.e. categorization feeds back into filtering.

Per-user personalization signals

Beyond the spam/nonspam vote, Gmail runs a per-user importance model and per-user spam controls. These are the mechanisms that make placement individual.

Importance markers (help topic "Importance markers in Gmail"). Gmail predicts which messages matter to each user from:

• how often the user communicates with the sender (frequency);
• which messages the user opens and replies to;
• keywords in emails the user usually reads;
• interactions — starring, archiving, deleting.

Users see a yellow importance marker, can correct it (training the model), and can find flagged mail with is:important. A user can turn off predictive marking ("Don't use my past actions to predict which messages are important") or hide markers entirely — settings changed in the browser but applied app-wide.

Spam controls that feed personalization (help topic on Gmail spam sorting):

User action	Effect on future placement
Report spam	Message added to Spam; "as you report more spam, Gmail identifies similar emails as spam more efficiently." Google receives a copy and may analyze it to protect all users.
Not spam	Recovers the message and trains Gmail that this sender is wanted (the manualnonspam vote).
Block sender	"Even when you remove their emails from Spam, Gmail still automatically identifies their emails as spam." A hard per-user override.
Add sender to Google Contacts	"Gmail stops sending their messages to Spam." A hard per-user allow.
Unsubscribe	Offered inline for opted-in senders — a lower-damage exit than Report Spam.
Filters	User-created rules can label/prioritize a sender's mail.

The through-line: the recipient's own history can override the sender's aggregate reputation in both directions. A sender with a strong domain reputation still lands in spam for any recipient who blocked them or repeatedly reported them; a weak-reputation sender inboxes for recipients who added them to Contacts or hit Not Spam.

Holiday-period tightening

Google publicly tightens filters around high-fraud periods. For the 2024 holiday season (blog, Dec 2024):

• Gmail blocks more than 99.9% of spam, phishing and malware.
• The newly deployed LLM classifier and supervisor model (see ML classification) were launched before Black Friday.
• Result: users reported 35% fewer scams hitting inboxes in the first month of the holiday season vs the prior year.
• Named holiday scam patterns Gmail hardened against: invoice scams (fake invoices soliciting a dispute phone call), celebrity scams (impersonation / false endorsement), and extortion scams (threats citing a home address or personal detail).

Sender takeaway: filter thresholds are not constant across the calendar. A borderline-reputation stream that inboxes in a quiet month can tip into spam during a tightening window — build reputation margin ahead of Q4, don't launch new streams or re-warm into the holiday peak.

Sender takeaways: what actually moves Gmail placement

1. Authenticate so you're scoreable, then build the domain's reputation. SPF and DKIM aligned to the From domain; reputation attaches to that authenticated domain, not your IP. Unauthenticated mail is mostly unscoreable and correlates with spam (~60% of spam is unauthenticated vs ~26% of wanted mail).
2. The one metric that directly drives the model is the user spam vote. Report Spam pushes reputation down; Not Spam / Add-to-Contacts pushes it up. Keep the Postmaster Tools spam rate below 0.10% and never at 0.30% — those are the sender-requirement thresholds that map onto this vote.
3. Reputation is slow in both directions. Days of consistent behavior build it; a single bad blip is absorbed as noise; recovery after sustained abuse "takes a few days." No overnight fix — see reputation incident recovery.
4. Separate your streams. Transactional signed separately from marketing scored higher even in 2006, because the streams have different wantedness. Segment by sending domain/subdomain and content type.
5. Categorization is not deliverability. Promotions is the inbox. Optimize tab placement with content (personalization, conversational tone, fewer images/links), not by trying to game the classifier — you can't pre-select a tab.
6. Per-user personalization defeats one-size diagnosis. Because importance markers, blocks, Contacts, and per-address overrides are all per-recipient, "where does my mail land at Gmail?" has no single answer — only a distribution. Seed-inbox tests sample a handful of fresh accounts with no per-user history and therefore cannot represent what an engaged (or disengaged) real recipient sees. Trust aggregate Postmaster Tools reputation and spam-rate trends over any single-inbox screenshot (see tracking and measurement distortion).

Provenance note: Gmail help answer 6596 ("Gmail inbox tabs and categories") overlaps the Content and Design Gmail-tabs section and the categorization coverage here; it was not extracted separately as it adds nothing beyond answer 3094499 already used above.

Related

• Gmail Sender Requirements — the checkable rules and spam-rate thresholds that feed this model.
• Gmail SMTP Troubleshooting — the reply codes, including the reputation-block messages.
• Google Postmaster Tools — the sender-facing view of domain/IP reputation and spam rate.
• Content and Design for Deliverability — content factors for spam avoidance and Primary-tab placement.
• Foundations of Email Deliverability — the wanted/expected principle underlying the whole reputation model.
• ARC — the later fix for the forwarding failure mode the 2006 paper describes.