How Email Spam Filters Work: From SMTP Checks to Inbox Placement

An email spam filter is a system that evaluates incoming messages for unwanted or risky mail and helps determine how they should be handled. Filtering can happen at a receiving gateway, within a mailbox provider, or through local and user-level rules.

That broad definition matters because an email does not simply pass or fail one universal spam test.

A message can be temporarily deferred before acceptance. It can be permanently rejected. It can be accepted and later placed in spam or junk. It can reach the inbox but appear under a category such as Gmail Promotions instead of Primary.

Those outcomes are different, and fixing them requires different evidence.

The public sender documentation checked for Gmail, Yahoo, Outlook.com, and iCloud does not disclose a complete weighting or universal ordering of every filtering signal. The useful model is therefore a set of observable states and outcomes, not a secret provider sequence or one universal spam score.

Verified fact: Authentication can establish domain authorization and alignment, but it cannot guarantee inbox placement. The current DMARC specification, RFC 9989, states that a DMARC pass validates authorized use of the author domain but does not guarantee that inbox delivery would be safe or desirable.

Table of Contents

38 sections Show

Where Email Spam Filtering Can Happen

The phrase “spam filter” can describe more than one control in the path between a sender and a recipient.

• During the SMTP transaction: A receiving system can temporarily defer or permanently reject a delivery attempt before accepting the message.
• After SMTP acceptance: A mailbox provider can classify an accepted message into an inbox, spam or junk location, or another mailbox category.
• At the mailbox or user level: Recipient settings, rules, and local filtering can change where accepted mail appears after delivery.

This distinction prevents a common diagnostic mistake: treating every missing, delayed, rejected, categorized, or junked message as the same problem.

For sender-side troubleshooting, the most useful question is not “Did the spam filter block me?” It is “What observable state did the message reach?”

One Email Can Be Deferred, Rejected, Accepted, Filtered, or Categorized

Before asking why an email went to spam, establish what actually happened to it.

Outcome	What It Means	First Evidence to Check
Temporary SMTP failure	The receiving system did not accept the current delivery attempt, but the condition is considered transient.	The exact 4xx SMTP response and sending logs.
Permanent SMTP rejection	The receiving system rejected the delivery attempt with a permanent negative response.	The exact 5xx SMTP response or non-delivery report.
SMTP acceptance	The receiving SMTP system accepted responsibility for the message after message transfer completed successfully.	The final successful SMTP response.
Spam or junk placement	The message was accepted but later classified into a spam or junk location.	Recipient mailbox evidence first. Use provider dashboards to corroborate complaint, reputation, authentication, or delivery patterns.
Inbox category placement	The message reached the inbox but was sorted into a category such as Gmail Promotions.	The recipient’s actual mailbox classification.

These states should not be collapsed into one deliverability number because they describe different events.

A 4xx Response Means the Current Attempt Has Not Been Accepted

RFC 5321 defines a reply beginning with 4 as a transient negative completion response. The requested action was not completed, but the condition can be temporary and the sending system can normally try again later.

Mailbox providers use temporary responses for different operational and policy conditions.

Yahoo’s SMTP error documentation, for example, describes 421 and 451 responses associated with conditions such as unusual traffic patterns, recipient complaints, temporary authentication problems, suspicious behavior, and temporary server conditions.

Gmail’s SMTP error reference documents temporary responses for rate limiting, authentication conditions, DNS problems, reputation issues, and other delivery conditions.

A temporary SMTP failure is not the same as an email being placed in spam. The receiving system has not successfully accepted that delivery attempt yet.

A 5xx Response Means the Delivery Attempt Was Rejected

RFC 5321 defines replies beginning with 5 as permanent negative completion responses. The failed request should not simply be repeated unchanged when the underlying condition is permanent.

A rejection can have many causes.

Yahoo documents permanent errors for invalid recipients, authentication failures, policy conditions, malicious content, and other reasons.

Microsoft currently documents 550 5.7.515 for high-volume senders whose domain in the visible 5322.From address does not meet Microsoft’s required authentication level.

If you have a 5xx response, read the complete diagnostic before rewriting the body or subject line. The receiving system may already have identified a much narrower problem.

A Successful Final SMTP Response Is Not an Inbox Guarantee

After message data has been transmitted, a successful final SMTP response means the receiving SMTP system accepted responsibility for the message under the SMTP protocol.

That successful response does not tell the sender which mailbox folder or category will ultimately contain the message.

Mailbox providers can apply additional security, policy, reputation, content, and classification decisions after SMTP acceptance.

Accepted does not automatically mean inbox.

Rejected does not mean spam folder.

Deferred does not mean spam folder.

You need to identify the actual state before deciding what to repair.

Gmail Promotions Is Not the Spam Folder

Inbox categorization creates another common source of confusion.

Gmail documents five standard categories for its Default inbox type: Primary, Social, Promotions, Updates, and Forums.

Users can choose which categories are shown and can move messages between categories.

A message appearing in Promotions has therefore reached an inbox category. It has not been rejected, and Promotions should not be described as a spam folder.

This distinction matters because a sender can waste time trying to repair a supposed filtering failure when the actual result is ordinary inbox categorization.

If a message is in Promotions, first ask whether that category is reasonable for the message. Do not diagnose the category itself as evidence of SMTP failure or spam placement.

Authentication Establishes Domain Identity and Alignment, Not Inbox Permission

SPF, DKIM, and DMARC are central to modern email authentication, but they solve narrower problems than many deliverability explanations imply.

They help receiving systems evaluate whether domain identities are being used in authorized and aligned ways. They do not certify that a message is wanted, harmless, relevant, or entitled to a particular mailbox location.

SPF Authorizes Hosts to Use a Domain Identity

RFC 7208 defines the Sender Policy Framework, or SPF.

SPF allows a domain to publish which hosts are authorized to use that domain in relevant SMTP identities. A receiving system can compare the connecting host against that published policy.

An SPF pass therefore answers an authorization question about a particular SMTP identity.

It does not establish that:

• the visible From domain necessarily aligns for DMARC
• the message content is safe
• the recipient requested the message
• the message must be placed in an inbox

DKIM Associates a Cryptographic Signature With a Domain

RFC 6376 defines DomainKeys Identified Mail, or DKIM.

DKIM attaches a cryptographic signature to a message and associates that signature with a signing domain. The signature can be validated using the public key published for that domain.

A valid DKIM signature can also demonstrate that the signed portions of a message survived transit without changes that would invalidate the signature.

That does not mean the message is automatically wanted or safe, and it does not guarantee a mailbox location.

DMARC Checks Alignment With the Visible Author Domain

DMARC builds on SPF and DKIM by evaluating authentication in relation to the domain visible to the recipient in the RFC 5322 From field.

The current base specification is RFC 9989, published in May 2026. It obsoletes RFC 7489 and RFC 9091.

A message can pass DMARC when a passing SPF identity or a passing DKIM identity satisfies DMARC alignment with the author domain.

The critical limitation is explicit in RFC 9989: a DMARC pass validates authorized use of the author domain for that message, but it does not make a positive claim about the desirability or safety of the message. A receiving system can still apply other handling or filtering decisions.

Verified fact: Authentication contributes evidence about domain authorization and alignment.

Editorial judgment: Treating SPF, DKIM, or DMARC as an inbox switch is a reliable way to misdiagnose a filtering problem.

Forwarding Can Change Authentication Outcomes

Forwarding and mailing-list flows can change the conditions under which authentication is evaluated.

SPF can be affected because the forwarding system becomes the server connecting to the next receiver. Message modifications can also invalidate DKIM signatures when signed portions of the message are changed.

RFC 8617 defines the Authenticated Received Chain, or ARC. ARC provides a way for participating intermediaries to preserve authenticated information about prior authentication assessments through an indirect mail flow.

Apple requires ARC headers on forwarded bulk mail sent to iCloud Mail, while Yahoo recommends ARC for forwarded email.

ARC is additional authenticated evidence. It is not an inbox-placement guarantee.

MTA-STS has a different purpose. RFC 8461 defines SMTP MTA Strict Transport Security as a mechanism for publishing SMTP transport-security policy and requiring appropriate TLS connections. MTA-STS is not a replacement for SPF, DKIM, or DMARC, and it is not a direct inbox-placement mechanism.

Mailbox Providers Apply Their Own Sender Requirements

There is no single provider-neutral checklist that guarantees delivery everywhere.

Gmail, Yahoo, Outlook.com, and iCloud publish overlapping requirements, but the scope, thresholds, and enforcement details differ.

Provider	Authentication Baseline	Important Provider-Specific Points
Gmail	SPF or DKIM for all senders. Additional SPF, DKIM, DMARC, and alignment requirements apply above Google’s bulk threshold.	Provider-specific spam-rate guidance, DNS, TLS, message-format, and unsubscribe requirements apply.
Yahoo	SPF or DKIM for all senders. Bulk senders need SPF, DKIM, and passing DMARC.	Yahoo has its own complaint-rate, DNS, unsubscribe, and RFC requirements and does not publish a fixed bulk-sender volume threshold.
Outlook.com	High-volume senders using the same visible From domain must meet Microsoft’s SPF, DKIM, and DMARC requirements.	Microsoft publishes a specific authentication rejection, 550 5.7.515, and provides reputation information through SNDS.
iCloud Mail	Apple’s bulk-mail requirements include SPF, DKIM, and a published DMARC policy.	Apple also requires explicit subscription, unsubscribe support, ARC on forwarded bulk mail, consistent sending identity, DNS, and SMTP error monitoring.

Gmail

Google’s Email sender guidelines require senders to personal Gmail accounts to meet a baseline that includes SPF or DKIM, valid forward and reverse DNS, TLS, compliant message formatting, and Google’s spam-rate requirements.

For senders sending more than 5,000 messages per day to Gmail accounts, Google adds requirements including SPF and DKIM, a DMARC record, and alignment of the visible From domain with SPF or DKIM for direct mail.

Marketing messages and subscribed messages in that higher-volume category must also support one-click unsubscribe and include a clearly visible unsubscribe link in the message body. The standardized one-click mechanism is defined in RFC 8058.

Google’s sender guidelines recommend keeping the user-reported spam rate shown in Postmaster Tools below 0.10 percent and avoiding 0.30 percent or higher. Those figures describe Gmail’s own Postmaster metric. They are not universal spam-filter thresholds.

Google’s sender guidelines FAQ documents current enforcement details for senders that do not meet the requirements.

Yahoo

Yahoo’s Sender Requirements and Recommendations require all senders to authenticate with SPF or DKIM, maintain valid forward and reverse DNS, comply with RFC 5321 and RFC 5322, and keep Yahoo’s spam complaint rate below 0.3 percent.

Yahoo requires bulk senders to use SPF and DKIM, publish a valid DMARC policy, and pass DMARC with the visible From domain aligned with SPF or DKIM.

For marketing and subscribed mail, Yahoo also requires a functioning List-Unsubscribe header that supports easy unsubscribe, a clearly visible unsubscribe link in the message body, and unsubscribe requests honored within two days. Yahoo specifically recommends the RFC 8058 one-click method.

Yahoo’s Sender Hub FAQ says Yahoo does not publish a specific volume threshold for classifying a bulk sender.

The same FAQ documents reputation inputs including IP address, URL, domain, sender, ASN, DKIM, and DMARC information.

Outlook.com

Microsoft currently defines a high-volume sender for its consumer email services as one sending 5,000 or more messages using the same domain in the visible 5322.From address.

For those senders, Microsoft’s 550 5.7.515 documentation says SPF and DKIM checks must pass, a DMARC record must be published, and DMARC validation must pass through aligned SPF or DKIM.

Microsoft tells affected senders to begin troubleshooting with the message header and the SPF, DKIM, and DMARC configuration.

Microsoft Smart Network Data Services, or SNDS, provides reputation-related information for Outlook.com traffic, including detailed data about sending IPs and access to the Junk Email Reporting Program.

iCloud Mail

Apple’s iCloud Mail Postmaster documentation requires bulk senders to send only to recipients who explicitly subscribed, provide an unsubscribe option, add ARC headers to forwarded mail, comply with relevant email standards, maintain reverse DNS, use consistent sending identities, authenticate with SPF and DKIM, publish a DMARC policy, and monitor temporary and permanent SMTP errors.

Apple says iCloud Mail does not offer an allow list for bulk senders.

Apple also states that its filtering decisions use mechanisms including IP and domain reputation, content checks, and user feedback.

Reputation Connects Sending History to Future Treatment

Authentication answers specific identity and alignment questions. Reputation adds historical context.

The exact scoring models are private, but major providers publicly acknowledge reputation as a factor.

Google Postmaster Tools documents IP and domain reputation data in its current and legacy dashboard environment, along with spam rate, authentication, feedback-loop, compliance, encryption, and delivery-error information.

Google also warns that Postmaster data is not real time and may be unavailable or incomplete on low-volume days.

Postmaster Tools is moving toward its newer v2 environment. Google’s transition documentation says the legacy interface will eventually be retired and that the existing Domain and IP Reputation dashboards are planned for replacement. Treat dashboard names and availability as mutable product details.

Yahoo documents multiple reputation inputs, including IP, URL, domain, sender, ASN, DKIM, and DMARC information. It also states that user spam reports can affect overall reputation.

Apple says iCloud Mail tracks IP and domain reputation alongside content checks and user feedback.

Microsoft SNDS says Outlook.com deliverability is based on reputation and provides data intended to help senders understand and manage that reputation.

None of those sources establishes one universal formula.

There is no defensible provider-neutral rule such as:

• one complaint causes a fixed reputation loss
• every bounce rate above one percentage is unsafe
• a domain becomes trusted after a fixed number of days
• sending a fixed number of messages each day guarantees healthy reputation

Provider-specific measurements should stay provider-specific.

Complaints and Unwanted Mail Are Stronger Evidence Than Trigger-Word Lists

Major mailbox providers consistently tell senders to reduce unwanted mail and recipient complaints.

Google tells senders to monitor user-reported spam through Postmaster Tools and recommends sending mail to recipients who want to receive it.

Yahoo’s Complaint Feedback Loop provides reports for qualifying DKIM-signed mail when users mark messages as spam, allowing enrolled senders to suppress those recipients from future campaigns.

Microsoft’s Junk Email Reporting Program can provide reports when Outlook.com users junk messages.

Apple does not offer a feedback-loop service, but it tells bulk senders to maintain subscriber lists, remove addresses that repeatedly bounce, and honor unsubscribe requests.

Practical recommendation: If complaint signals rise, investigate who is receiving the mail, why they are receiving it, whether the mail matches what they agreed to receive, and whether they can leave the list easily before searching for copy tricks.

Content and Links Can Matter Without a Magic Spam-Word List

Receiving systems can evaluate message content and linked destinations, but that does not create a reliable public list of words that automatically determines spam placement across providers.

Yahoo’s SMTP documentation describes content-based blocks involving malware, phishing, ransomware, malicious software, and links or URLs associated with those threats.

Apple identifies content checks as one of several mechanisms used by iCloud Mail when making filtering decisions.

Gmail’s SMTP error reference includes responses associated with suspicious message content, linked domains, malicious content, and other policy conditions.

These sources establish that message content and URLs can matter.

They do not establish a deterministic equation such as:

FREE + SALE + three exclamation marks = spam

Treat public trigger-word lists as editorial heuristics at most, not as documentation of Gmail, Yahoo, Outlook.com, or iCloud’s private filtering rules.

Content testing can still help isolate a problem, but it should be treated as a controlled diagnostic experiment rather than a method for discovering forbidden words.

Open Rate Is Not an Inbox-Placement Measurement

A low open rate can tell you that campaign performance changed.

It cannot, by itself, tell you why.

Google’s Gmail sender guidelines explicitly say that Google does not track open rates, cannot verify the accuracy of open rates reported by third parties, and does not consider low open rates alone an accurate indicator of deliverability or spam-classification problems.

If open rate falls, do not immediately conclude that Gmail filtered the messages.

Check SMTP acceptance, provider-specific diagnostics, complaints, authentication, reputation data where available, and actual recipient placement evidence first.

Diagnose the Failure Before Changing the Message

The fastest useful diagnostic question is not “Which word triggered the spam filter?”

It is:

Where did the message stop behaving as expected?

Practical recommendation: Work from the earliest observable failure toward the later and less observable stages.

1. Check Whether the Receiver Accepted the Message

Start with your sending logs, mail transfer logs, or delivery report.

Look for the final SMTP response for the relevant delivery attempt.

• A 4xx response indicates a temporary negative result for that attempt.
• A 5xx response indicates a permanent negative result for that request.
• A successful final response after the message transfer means the receiving SMTP system accepted responsibility for the message.

Do not classify those three outcomes as the same type of spam problem.

2. Read the Exact SMTP Diagnostic

Provider error codes frequently identify a narrower issue than a generic deliverability checklist.

Possible categories include:

• authentication
• reverse DNS
• message formatting
• rate limiting
• recipient validity
• policy
• reputation
• content or link safety

Yahoo publishes detailed explanations for temporary and permanent SMTP errors.

Gmail publishes current SMTP errors and diagnostic codes.

Microsoft’s 550 5.7.515 is an example where the rejection itself points directly toward the required authentication investigation.

3. Check SPF, DKIM, and DMARC Results

If you have a delivered copy of the message, inspect the authentication results recorded by the receiving system.

RFC 8601 defines the Authentication-Results header for communicating authentication results such as SPF, DKIM, and DMARC inside a receiver’s trust environment.

Look for:

• spf=pass, fail, or another SPF result
• dkim=pass, fail, or another DKIM result
• dmarc=pass, fail, or another DMARC result
• the domains associated with those results
• whether the relevant authenticated domain aligns with the visible From domain for DMARC

Do not simply count passes.

A message can have an independent SPF or DKIM pass while still failing DMARC because the passing identity does not satisfy alignment with the visible author domain.

Also be careful when interpreting an Authentication-Results field copied from an arbitrary point in a message path. RFC 8601 explains that authentication results have meaning within an appropriate trust boundary.

4. Compare the Problem by Mailbox Provider

Ask whether the failure is limited to one provider or appears across several.

• Gmail only
• Yahoo only
• Outlook.com only
• iCloud only
• widespread across multiple providers

A provider-specific problem should push you toward that provider’s evidence first.

For Gmail, Postmaster Tools can provide spam-rate, authentication, compliance, feedback-loop, reputation, encryption, and delivery-error information when enough relevant traffic exists. Google says the data is not real time and can be absent when volume is low.

For Outlook.com, use SNDS where applicable to inspect IP-level reputation information and junk-reporting data.

For Yahoo, compare SMTP diagnostics with its sender requirements and complaint feedback data if you are enrolled.

For iCloud, Apple specifically tells senders to review temporary and permanent SMTP errors in their mail logs when investigating delivery problems.

5. Separate Spam Placement From Inbox Categorization

If the receiver accepted the message, verify where actual recipient mailboxes placed it.

Do not record Gmail Promotions as spam.

Do not record a 5xx rejection as spam placement.

Do not record a temporary 4xx deferral as spam placement.

Combining these outcomes destroys the diagnostic value of your data.

6. Check Complaint and Recipient-Quality Signals

Review the evidence available to you, including:

• provider complaint data where available
• invalid-recipient patterns
• unsubscribe handling
• whether recipients requested or reasonably expect the mail
• changes in traffic composition
• changes in sending volume

Yahoo documents delivery problems associated with excessive unknown recipients and recipient complaints.

Google recommends permission-based sending, easy unsubscribe, consistent sending rates, gradual volume increases, and monitoring server responses, spam rate, and reputation.

Apple requires explicit subscription for bulk mail sent to iCloud Mail customers and recommends removing addresses that repeatedly bounce.

7. Isolate Message or URL Problems Last

Once SMTP acceptance, authentication, provider requirements, reputation evidence, and recipient quality have been checked, controlled content tests become more informative.

Change one meaningful variable at a time.

For example:

1. Keep the sender infrastructure and test audience constant.
2. Remove or replace one linked domain or one suspect content element.
3. Send the controlled version to an appropriate test audience.
4. Compare SMTP responses and actual placement evidence.
5. Repeat only when the result gives you a reason to test another variable.

This is a hypothetical diagnostic method, not evidence that any particular word or URL caused a real provider decision.

The goal is to isolate a condition, not to find a pattern that beats a filter.

Fix Legitimate Delivery Problems in Evidence Order

Practical recommendation: For a legitimate sender, investigate and repair problems in this order:

1. Fix SMTP or configuration failures that prevent successful acceptance.
2. Correct SPF, DKIM, DMARC, DNS, or alignment problems identified by the evidence.
3. Meet the current requirements of the affected mailbox provider.
4. Stop sending to invalid, unsubscribed, or clearly unwanted recipients.
5. Investigate complaint and reputation problems using provider evidence where available.
6. Stabilize legitimate sending patterns and scale cautiously.
7. Investigate content and linked domains after earlier checks are healthy.
8. Recheck the same provider-specific evidence after making changes.

This order deliberately starts with observable failures instead of random changes to subject lines, wording, timing, or other variables that may have nothing to do with the actual problem.

Stabilize Sending Volume Without Treating Warmup as a Guarantee

Large or sudden changes in sending volume can contribute to delivery problems, but there is no universal domain-warmup schedule that applies across mailbox providers.

Google advises large senders to increase volume slowly, send at a consistent rate, avoid sudden bursts, and monitor server responses, spam rate, and reputation while volume changes.

Yahoo documents unusual traffic patterns and rapid traffic from newly configured sending infrastructure among conditions that can contribute to temporary delivery problems.

Those sources support a narrow practical recommendation: increase legitimate sending volume gradually enough that you can observe problems and respond before scaling further.

They do not establish claims such as:

• send exactly 10 emails on day one
• increase by a fixed percentage every day
• run artificial reply traffic for a fixed number of weeks
• a warmed domain is guaranteed to reach the inbox

Provider guidance about gradual, consistent volume should not be converted into an invented universal warmup formula.

Spam-Test Tools Provide Clues, Not Mailbox Ground Truth

Pre-send spam tests can be useful when they expose a condition that you can independently verify.

A test might help identify:

• missing authentication
• malformed headers
• DNS problems
• suspicious linked domains
• message-format issues
• blocklist exposure

The mistake is treating one third-party score as a direct prediction of production inbox placement.

Google’s Postmaster documentation notes that third-party spam reports can differ from Gmail’s data because they do not use the same information and factors.

A third-party test also cannot expose the complete private decision system used for every recipient at Gmail, Yahoo, Outlook.com, or iCloud.

Editorial judgment: A useful spam test gives you a specific condition that can be checked. A score without an explainable cause is much weaker evidence.

FAQ

What Is the Difference Between a Rejected Email and an Email in Spam?

A rejected email was not accepted in the relevant SMTP transaction. Under RFC 5321, a 5xx response represents a permanent negative result, while a 4xx response represents a transient negative result for the request.

An email in spam or junk has normally passed the SMTP acceptance stage and was then classified into a spam or junk location. Rejection and spam placement are therefore different states with different evidence.

Can an Email Pass SPF, DKIM, and DMARC and Still Go to Spam?

Yes.

SPF, DKIM, and DMARC provide authentication and alignment evidence. They do not guarantee that a mailbox provider considers the message wanted, safe, or suitable for an inbox.

RFC 9989 explicitly says that a DMARC pass does not guarantee that delivery to the recipient’s inbox would be safe or desirable, and receiving systems can still apply other handling decisions.

Is Gmail Promotions the Same as Spam?

No.

Promotions is one of Gmail’s inbox categories, alongside Primary, Social, Updates, and Forums. Gmail users can change which categories appear and can move messages between them.

A message in Promotions has not automatically failed delivery or been classified as spam.

Do Spam Trigger Words Still Matter?

Content can matter, but there is no authoritative universal list of individual words that automatically sends an email to spam across major mailbox providers.

Yahoo publicly documents content-based blocks for malicious content and harmful links, while Apple says content checks contribute to iCloud Mail filtering. Gmail’s SMTP error documentation also includes policy responses related to suspicious content and links.

Those sources support contextual content analysis, not a universal trigger-word formula.

How Useful Are Spam Scores and Seed Tests?

They can be useful as diagnostic tools when they identify specific problems such as authentication, DNS, formatting, or URL issues.

They are weaker when reduced to a single inbox probability. Google notes that third-party spam reports can differ from Gmail’s own data because they do not use the same information.

Use test results as evidence to investigate, not as guarantees of production placement.

How Long Does It Take to Recover From a Spam or Reputation Problem?

There is no universal recovery window.

The answer depends on the provider, the underlying problem, current reputation, ongoing traffic, recipient feedback, and whether the original cause has actually stopped.

Google’s Postmaster Tools documentation says that after taking recommended actions to reduce spam, senders may need to wait up to seven days for the user-reported spam rate to return to a level within compliance. That is Gmail-specific reporting guidance. It is not a promise that inbox placement will recover everywhere within seven days.

The useful question is not “How many days should I wait?” It is “Has the evidence that identified the problem actually improved?”