How do spam filters work?
An inbound spam filter checks each message in layers. It first judges the sending server's connection and reputation, then checks SPF, DKIM and DMARC, then scores the content and scans attachments. The combined verdict decides whether the message is delivered, sent to junk, quarantined or rejected. No single check decides on its own.
On this page 9 sections
A spam filter is a series of checks, not a single switch. Each check adds evidence for or against a message, and the filter combines that evidence into one decision. Knowing the layers helps you read headers, fix false positives and choose between the filtering built into your mailbox and a separate gateway.
What happens to an email before it reaches your inbox?
Inbound filtering runs in roughly this order. Different products name the steps differently, but the shape is the same.
| Layer | When it runs | What it looks at | Typical result |
|---|---|---|---|
| Connection checks | While the sending server connects | IP address, blocklists, reverse DNS, sending rate | Reject or slow down the connection |
| Recipient checks | During the SMTP conversation | Does the address exist? | Reject unknown recipients |
| Authentication | After the message is received | SPF, DKIM, DMARC | Pass, fail, or policy action |
| Reputation | Throughout | Sender domain, IP, links, history | Raise or lower the score |
| Content and heuristics | After receipt | Headers, body, links, language, patterns | Spam score |
| Attachment scanning | After receipt | File types, malware signatures, behavior | Block or quarantine |
| Verdict and action | At the end | All of the above | Deliver, junk, quarantine or reject |
Cheap checks run first. Rejecting a bad connection costs almost nothing. Scanning a large attachment costs much more. So filters drop the obvious junk early and save the heavy work for what's left.
Connection checks: who is knocking?
Before a message's content is even sent, the receiving server knows the sending server's IP address. That alone carries a lot of information.
IP blocklists
Many filters query DNS-based blocklists. RFC 5782 describes how they work: the filter reverses the IP address, adds the list's domain, and looks it up in DNS. If an answer comes back, the address is listed. For example, 192.0.2.99 is checked as 99.2.0.192.bl.example. Lists are run by different organizations with different listing rules, so filters usually weigh several of them rather than trusting one.
Server hygiene
Filters also look at basic signs of a properly run mail server:
- Does the IP address have reverse DNS, and does it match a forward lookup?
- Does the server greet with a sensible host name?
- Is it sending at a normal rate, or hammering many recipients at once?
- Does it follow the SMTP protocol correctly, or cut corners the way some spam software does?
None of these proves a message is spam. Together they help separate real mail servers from infected home computers and throwaway servers.
Recipient validation
Ideally, a filter knows which addresses exist on your domain and rejects mail to the rest during the SMTP conversation. Not every service does this, so ask your provider. Rejecting at this stage matters. If a filter accepts mail for unknown users and bounces it later, it sends bounce messages to forged addresses. That's backscatter, and it can hurt your own reputation.
Reputation: has this sender behaved before?
Reputation is history. A filter builds or buys knowledge about IP addresses, sending domains and the domains of links inside messages. A domain registered yesterday, linked from a message sent by a server with no track record, starts with little trust.
Bulk mail gets its own handling. Microsoft 365, for example, assigns a bulk complaint level to messages from bulk senders, and acts on messages that meet or exceed a threshold you configure. Newsletters aren't malicious, but people often don't want them, so many filters treat them as a separate category.
Authentication: is the sender who it claims to be?
Next, the filter checks whether the domain in the message is real:
- SPF checks whether the sending server is allowed to send for the envelope sender's domain.
- DKIM checks a cryptographic signature added by the sending domain.
- DMARC, now defined in RFC 9989, checks that SPF or DKIM passed for a domain aligned with the visible From address. It also tells receivers what the domain owner wants done with failures: nothing, quarantine or reject.
The results are written into an Authentication-Results header, described in RFC 8601. That header is the first place to look when you want to know why a message was treated the way it was. Paste a message's headers into the Email Header Analyzer to read it without decoding by hand.
Authentication proves where a message came from. It doesn't prove the message is safe. A phishing email from a newly registered lookalike domain can pass SPF, DKIM and DMARC perfectly. For what the three records stop and don't stop, see what is email spoofing.
Content and heuristics: what does the message look like?
Once a message passes the early checks, the filter looks inside it. Common signals include:
- Headers that are malformed, missing or inconsistent with each other.
- Links whose visible text doesn't match the real destination, or links to domains with a bad reputation.
- Phrases, layouts and images associated with known campaigns.
- Language or country of origin, where an admin has chosen to filter on them. Microsoft 365 offers both as optional anti-spam settings.
- Signs of mass mailing, such as many near-identical messages arriving at once.
Each signal adds to or subtracts from a score. Microsoft says its spam filtering "learns from known spam and phishing threats and user feedback from our consumer platform, Outlook.com," and that feedback from admins and users keeps it trained, which is why reporting missed spam and false positives helps over time. The final score is compared with thresholds to pick an action.
Heuristics cause most false positives. A legitimate invoice can look a lot like a fake one. If good mail is getting caught, our guide on false positives explains how to find the cause.
Attachment scanning: is the file dangerous?
Attachments get their own layer, because they're a common way to deliver malware.
- File-type rules. Many filters block risky types outright. Microsoft's common attachments filter uses best-effort true type matching, which reads the file's contents rather than trusting the extension, so renaming
invoice.exetoinvoice.pdfusually doesn't help the attacker. - Signature scanning. Antivirus engines compare files with known malware.
- Macro checks. Office documents with macros can be blocked or flagged, since macros can run code.
- Sandboxing. Some products open the file in an isolated virtual machine and watch what it does. Microsoft calls this detonation in Safe Attachments, part of Defender for Office 365, and notes that scanning typically completes within 15 minutes.
Password-protected archives are a known gap: a scanner can't look inside a file it can't open. Treat unexpected encrypted attachments with suspicion. Our guide to dangerous email attachment types lists the file types worth blocking.
What happens after the verdict?
The filter now picks an action:
- Reject during SMTP. The sender gets an error and knows the mail wasn't delivered.
- Deliver to the inbox.
- Deliver to junk. The user sees it in a separate folder.
- Quarantine. The message is held outside the mailbox until someone releases it or it expires.
- Delete silently. Most products allow this, but it's hard to audit, so use it sparingly.
Quarantine is the safety net for uncertain verdicts. In Microsoft 365, malware and high-confidence phishing are always quarantined, and spam is kept for 15 days by default in the default policy, configurable from 1 to 30 days, according to Microsoft Learn. Users only find mistakes if they look, which is why quarantine digests matter. For more, read what is email quarantine.
Built-in filtering vs a gateway: what's the difference?
Microsoft 365 and Google Workspace both filter mail by default. A gateway is a separate service that your MX records point to, so it filters mail before your mailbox provider receives it.
| Item | Built-in filtering | Inbound gateway (MX-level) |
|---|---|---|
| Where it runs | Inside your mailbox provider | In front of it, at the MX |
| Setup | Already on | MX change plus connector or gateway settings |
| Covers | Mailboxes on that platform | Any mail server: Microsoft 365, Google Workspace, cPanel, Exchange |
| Outage handling | Depends on the platform | Can hold mail while your server is down |
| Main risk | One vendor's view of threats | Bypass if the mailbox provider still accepts direct mail |
A gateway changes what the mailbox provider sees. Every message now arrives from the gateway's IP address. Microsoft strongly recommends Enhanced Filtering for Connectors in this setup, and warns that skipping it leads to misclassified inbound mail. Google's inbound gateway setting does a similar job, and Google notes that Gmail doesn't enforce the sender's DMARC policy for mail arriving from the gateway, so the gateway must do it.
Both providers also let you reject mail that doesn't come through the gateway. Do that, or attackers can deliver straight to your mailbox provider and skip the gateway. Our comparison of Microsoft 365 built-in filtering vs a gateway and the guide to secure email gateways vs API-based tools go deeper.
Next steps
- Open the headers of a recent spam message and a recent false positive in the Email Header Analyzer. Note which checks passed and failed.
- Check your quarantine settings: who gets notified, how often, and how long messages are kept.
- If you use a gateway, confirm your mailbox provider rejects mail that doesn't come through it.
- Run MX Lookup to see which service receives your mail first. If you're considering an MX-level filter, how iBlockSpam works explains the setup.
To see what an MX-level filter looks like from the customer side, the iBlockSpam portal demo shows a dashboard with sample data: mail delivered and held, quarantine counts and the setup checklist.
Read more email security basics.
Frequently asked questions
Why did a legitimate email end up in spam?
Usually because several weak signals added up: a sending server with a poor reputation, failed or missing SPF, DKIM or DMARC, wording that looks like bulk mail, or a link to a little-known domain. Check the message headers to see which checks failed, then fix the cause or release and allow the sender.
Do spam filters read the content of my email?
Automated filters scan content to score it, look for known malicious links and inspect attachments. This is machine processing, not a person reading your mail. Ask any provider where mail is processed and how long it's kept. iBlockSpam processes mail in the United States and keeps message history for 30 days.
What is the difference between junk and quarantine?
Junk mail is delivered into the user's mailbox, in a separate folder. Quarantine holds the message outside the mailbox, so the user never sees it unless they or an admin release it. Filters usually quarantine higher-risk mail, such as malware and likely phishing, and send borderline mail to junk.
Should I run a gateway filter and Microsoft 365 filtering together?
You can, as long as Microsoft 365 is told about the gateway. Microsoft recommends Enhanced Filtering for Connectors so it sees the real sender's IP address. Without it, every message appears to come from the gateway, and Microsoft's authentication and reputation checks give poor results.
Can a spam filter stop every phishing email?
No. Filters lower the volume a lot, but some phishing comes from real, compromised accounts that pass every authentication check, or from new domains with no history. That's why you pair filtering with multifactor authentication, staff training and a simple way to report suspicious messages.
Sources
- RFC 5782: DNS Blacklists and Whitelists
- RFC 8601: Message Header Field for Indicating Message Authentication Status
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- Microsoft Learn: Anti-spam protection
- Microsoft Learn: Safe Attachments in Microsoft Defender for Office 365
- Microsoft Learn: Quarantined email messages in Microsoft 365
- Microsoft Learn: Manage mail flow using a third-party cloud service with Exchange Online
- Google Workspace Help: Set up an inbound mail gateway
See how your domain measures up
Run a free Email Health Check: MX, SPF, DKIM, DMARC and transport security in one scan, with the raw records shown. No sign-up.
Keep reading
What is an email quarantine, and how should you use it?
What an email quarantine is, personal vs admin quarantine, digest emails, retention limits, and how to release messages without letting phishing back in.
8 min read Choosing a filterSecure email gateway vs API-based email security: which do you need?
How an MX-based secure email gateway and API-based cloud email security each work, where each one wins, the trade-offs, and when to run both together.
9 min read Email security basicsWhat is DANE for SMTP, and do you need it?
DANE for SMTP explained: TLSA records, why DNSSEC is required, how it compares with MTA-STS, Exchange Online's DANE support, and how to check a domain.
9 min read