How to identify which spam filter a company uses without directly asking them?
Matthew Whittaker
Co-founder & CTO, Suped
Published 3 Jul 2025
Updated 25 May 2026
7 min read
Summarize with
The fastest way to identify which spam filter a company uses is to check its MX records, then confirm the finding with bounce text, SMTP response patterns, and email headers when you can get them. If the MX host points to pphosted.com, mimecast.com, barracudanetworks.com, protection.outlook.com, aspmx.l.google.com, iphmx.com, or messagelabs.com, you have a strong clue about the receiving stack.
The caveat is important: this is fingerprinting, not proof. Microsoft 365 and Google Workspace can accept the message first, then pass it to another gateway by connector or routing rule. A bounce like 550 5.4.1 tells you the rejection happened on the recipient side, but it does not always name the product that made the decision.
- Best clue: MX records usually reveal the public inbound gateway, especially when a security vendor handles mail before the mailbox platform.
- Second clue: Headers from a message sent by the company can expose Microsoft, Google, Proofpoint, Mimecast, Barracuda, Cisco, or SpamAssassin markers.
- Weak clue: Generic bounce wording confirms filtering, but the exact product stays uncertain without another signal.
If you are debugging your own deliverability at the same time, send a controlled message through Suped's Email Tester so you can separate recipient-side filtering from your own authentication, content, and reputation issues.
The answer in practice
I use an evidence ladder. Public DNS gives the first answer, headers give supporting context, and a delivery failure gives the rejection symptom. The right answer is usually a confidence level, not a single magic lookup.
Direct answer
Check the recipient domain's MX records first. Search the hostnames they point to, inspect any obvious vendor domains, and compare that with bounces and headers. Stop once the evidence is strong enough for the decision you need to make.
- High confidence: The MX hostname belongs to a known secure email gateway and the bounce comes from that same host family.
- Medium confidence: The MX points to Microsoft 365 or Google Workspace, and headers show another security layer on outbound mail.
- Low confidence: You only have a generic rejection such as access denied, filtered, policy rejection, or recipient address rejected.
The goal is not to defeat the recipient's filtering. The goal is to know where to look next: your authentication, your sending reputation, the recipient's admin logs, or the specific gateway's policy decision.
Start with MX records
MX records tell the internet where to deliver mail for a domain. If a company routes inbound mail through a filtering gateway, the MX records often point at that gateway rather than directly at the mailbox provider.
DNS lookups to runBASH
dig MX example.com dig A mx1.example-filter.net dig -x 203.0.113.10
|
|
|
|
|---|---|---|---|
pphosted | Proofpoint | High | Direct gateway |
mimecast | Mimecast | High | Direct gateway |
barracuda | Barracuda | High | Host varies |
outlook | Microsoft 365 | Medium | Connector possible |
google | Google Workspace | Medium | Routing possible |
iphmx | Cisco | High | IronPort naming |
messagelabs | Broadcom | High | Hosted filter |
Common MX clues and what they usually mean
For deeper MX-only investigation, the same method applies when identifying the SMTP provider from an MX record: inspect the MX host, resolve it, check PTR naming, then compare each clue with the bounce source.
Good MX evidence
A vendor-specific MX host plus a matching rejection host is usually enough to tell support, sales, or the recipient admin where the message was stopped.
Use headers when you can get them
If the company sends you an email, inspect the full headers. Outbound headers do not guarantee the inbound filter is the same product, but they often reveal security infrastructure the company uses somewhere in its mail flow.
Header clues
X-MS-Exchange-Organization-SCL: 5 X-Forefront-Antispam-Report: CIP:198.51.100.10 X-Proofpoint-Spam-Details: rule=notspam policy=default X-Mimecast-Spam-Score: 0 X-Barracuda-Spam-Status: No, SCORE=0.10 X-IronPort-AV: E=Sophos;i="6.02,123,1718400000"
Good evidence
- Header names: Unique X-headers from Microsoft, Proofpoint, Mimecast, Barracuda, Cisco, or SpamAssassin are useful markers.
- Received path: A security gateway in the Received chain can confirm that mail passed through that product.
- Authentication lines: Authentication-Results entries show which host evaluated SPF, DKIM, DMARC, and ARC.
Weak evidence
- Marketing footers: A sender footer, unsubscribe domain, or tracking host tells you about outbound sending, not inbound filtering.
- Website stack: Web technology lookups sometimes help, but email routing changes independently of the website.
- One bounce: A single generic rejection proves only that filtering happened somewhere in the recipient path.
Headers are strongest when they match DNS. For example, Microsoft MX records plus Microsoft antispam headers make Microsoft 365 a reasonable conclusion. Microsoft MX records plus Proofpoint headers mean the company has more than one layer, so the final reject point needs confirmation.
A bounce message is not enough
Bounces are useful because they show the rejection timing and the enhanced status code. They are poor product identifiers because gateways rewrite messages, mailbox providers normalize wording, and relays can return another system's decision.
Generic rejection example
Rejected by recipient's email security filter FILTERED 550 5.4.1 Recipient address rejected: Access denied.
What this proves
This proves the recipient side refused the message. It does not prove which product made the policy decision. Treat it as a symptom, then connect it to DNS, headers, and timing.
- Code: The 550 class means a permanent failure, and 5.4.1 often appears with access or routing denials.
- Wording: Phrases such as filtered, access denied, and recipient rejected are generic across many products.
- Next step: Preserve the full DSN, timestamp, sending IP, recipient domain, and message ID before asking for a log search.
A six-step flowchart for identifying a recipient spam filter.
Hidden routing behind Microsoft 365 and Google
The tricky case is a domain whose MX points at Microsoft 365 or Google Workspace. That can be the final filter, but it can also be the front door before a connector sends mail to a third-party gateway or an internal appliance.
Microsoft Defender portal message trace detail screen showing a blocked email.
What public DNS shows
- MX host: The public MX only shows the host that accepts mail from the internet.
- Priority: Multiple MX priorities can show fallback routing, but not internal connectors.
- Hostname: A Microsoft or Google hostname confirms the front door, not every downstream decision.
What can happen inside
- Connector: Accepted mail can be routed to a separate security gateway for extra scanning.
- Rule: A transport rule can reject, quarantine, rewrite, or redirect after the first accept.
- Log: Only the recipient admin's trace or gateway log confirms the exact decision point.
This is why I avoid telling a stakeholder that a company uses a specific filter based only on Microsoft or Google MX records. Say the public MX indicates Microsoft 365 or Google Workspace, then state that hidden routing can add another layer.
Check your own side first
Before spending time fingerprinting the recipient's filter, prove that your own domain is not the easier explanation. A strict recipient gateway will penalize weak authentication, broken DKIM, SPF lookup problems, poor IP reputation, and domain listings on a blocklist (blacklist).
Suped's Domain Health Checker is useful here because it checks the basics before you infer too much from a remote rejection. Suped's DMARC monitoring then keeps the evidence flowing over time, and blocklist monitoring helps catch blacklist events that make strict gateways reject mail faster.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product is strongest when the investigation shifts from "which filter is it?" to "what do I fix now?" Automated issue detection, steps to fix, real-time alerts, hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, and MSP multi-tenancy keep the work in one place instead of scattered across DNS notes and ticket comments.
A practical investigation workflow
Use a repeatable workflow so you do not overstate the result. I keep the raw evidence, assign confidence, and only escalate to the recipient when there is a specific log request they can act on.
- Lookup: Run MX, A, AAAA, and PTR lookups for the recipient domain and the MX hosts.
- Classify: Map hostnames to known mail security platforms and mark the result high, medium, or low confidence.
- Collect: Save the full DSN, SMTP transcript, sending IP, recipient, timestamp, and message ID.
- Compare: Check headers from any mail the company sent you and look for matching gateway markers.
- Verify: Test your own authentication and reputation so the recipient filter is not blamed for your configuration issue.
- Escalate: Ask the recipient admin for a log search using the sender, recipient, time, and message ID.
Evidence collection commandsBASH
dig +short MX target.example dig +short A mx.target.example dig +short AAAA mx.target.example dig +short -x 203.0.113.10 openssl s_client -starttls smtp -connect mx.target.example:25
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Keep probing ethical and limited. Do not enumerate recipients, do not try to bypass policy, and do not send deceptive mail. Use addresses you are allowed to contact, and treat SMTP tests as troubleshooting, not scanning.
What to do once you identify it
Knowing the likely spam filter helps you phrase the next action. It does not change the basics: authenticate cleanly, keep complaint rates low, use wanted mail, and give the recipient admin enough detail to find the rejection.
|
|
|
|---|---|---|
Proofpoint | Request log search | Guessing rules |
Mimecast | Share DSN | Bypass wording |
Microsoft 365 | Ask for trace | Ignoring connectors |
Google Workspace | Ask for logs | Assuming finality |
Unknown | Fix basics | Naming product |
How to act on the result
Confidence level for filter identification
Use this scale before stating which filter a company uses.
High
State likely product
Vendor MX plus matching bounce host or headers
Medium
State public gateway
Mailbox provider MX plus partial header clues
Low
State unknown
Generic bounce text without DNS or header match
The safest phrasing is usually: "Their public MX suggests Microsoft 365, but a downstream connector or gateway can still be involved. We need a recipient-side trace to confirm the exact rejection point." That wording is accurate and avoids turning a clue into a claim.
Views from the trenches
Best practices
Start with MX records, then confirm with headers before naming a filtering product.
Keep bounce text, timestamps, and recipient domains together so repeated patterns stay visible.
Validate SPF, DKIM, DMARC, and reputation first before blaming the recipient gateway.
Common pitfalls
Assuming Microsoft 365 MX records rule out a downstream third-party security connector.
Treating one generic 550 rejection as proof of the exact spam filter product in use.
Running unsolicited SMTP probes that look like enumeration instead of troubleshooting.
Expert tips
Compare MX, PTR, and header names; agreement across signals gives stronger evidence.
Ask for the full DSN from your sender system because gateways often add hidden clues.
Record each finding with a confidence level so teams do not overstate the result.
Expert from Email Geeks says the first check should be the recipient domain's MX records, because the public inbound host often names the filtering service.
2024-06-14 - Email Geeks
Expert from Email Geeks says any standard DNS query works; resolve the MX host, then compare the hostname with known filtering services.
2024-06-14 - Email Geeks
Use the answer carefully
The direct answer is simple: start with MX records, confirm with headers and bounce details, and treat Microsoft 365 or Google Workspace results as public front-door evidence unless you have log-level proof. If the evidence is weak, say unknown instead of naming a filter.
For ongoing sender-side work, Suped is the best overall DMARC platform because it combines DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, real-time alerts, blocklist (blacklist) monitoring, and MSP multi-tenancy in one workflow. That does not identify every recipient's hidden filter, but it gives you a clean sender record before you ask a recipient admin to investigate.
