How to identify which spam filter a company uses without directly asking them?
Published 3 Jul 2025
Updated 7 Oct 2026
13 min read
Summarize with
Updated on 7 Oct 2026: We clarified current MX hostnames, hidden API-based filtering, and the evidence needed to identify a company's public email gateway.
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 trusted email headers when available. A service-specific MX hostname is a strong clue about the public receiving gateway, while a mailbox-provider hostname identifies the receiving platform. Public evidence does not reveal every filtering layer or its settings.
Filter identification gives a confidence level about the public gateway. Microsoft 365 and Google Workspace can sit within a longer route that includes connectors, routing rules, or another gateway. A bounce such as 550 5.4.1 shows a permanent failure, but the exact response text and the host that generated it matter more than the code alone.
- Best clue: MX records usually reveal the public inbound gateway, especially when a security vendor handles mail before the mailbox platform.
- Second clue: Trusted headers can reveal mail servers and spam-scoring markers, but distinguish the company's outbound route from its inbound filtering.
- Weak clue: Generic bounce wording shows a delivery problem, but the exact product stays uncertain without another signal.
If you are debugging your own deliverability at the same time, send a controlled message to Suped's Email Tester. Suped's product checks the message received at its test address for sender-side issues; it does not reproduce the target company's filtering policy.
How to identify a company's spam filter
Use an evidence ladder. Public DNS gives the first answer, SMTP behavior adds another clue, headers give supporting context, and a delivery failure shows 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. Inspect the hostnames they point to, compare any vendor-specific naming with SMTP greetings, bounces, and headers, then 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 (SEG) and the responding SMTP host matches that service. Confidence applies to the public gateway, not its private rules.
- Medium confidence: The MX identifies Microsoft 365 or Google Workspace, but evidence for additional filtering is incomplete. Name the public receiving platform and leave other layers unconfirmed.
- Low confidence: You only have a generic rejection such as access denied, filtered, policy rejection, or recipient address rejected.
The goal is to locate the next useful check, not to defeat the recipient's filtering. That check can involve your authentication, your sending reputation, the recipient's admin logs, or the public 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. Query the domain after the @ in the recipient's address, including any subdomain; it is not always the company's website domain.
DNS lookups to runBASH
# MX lookup with dig dig MX example.com # Alternative with nslookup, including on Windows nslookup -type=mx example.com # Resolve a hostname returned by the MX lookup dig A mx.target.example dig AAAA mx.target.example # Reverse lookup for the returned address dig -x 203.0.113.10
|
|
|
|
|---|---|---|---|
A verified service-specific hostname | Secure email gateway | High with matching SMTP evidence | Does not reveal downstream filters |
*.mail.protection.outlook.com or *.mx.microsoft | Microsoft 365 | High for the receiving platform | Connectors and API checks remain hidden |
smtp.google.com or aspmx.l.google.com and its alt1-alt4 hosts | Google Workspace | High for the receiving platform | Routing rules and mailbox checks remain hidden |
A custom hostname under the recipient's domain | Self-hosted server or branded gateway | Low until corroborated | Hostname alone does not identify the operator |
MX clues identify the public receiving service
Microsoft's published receiving domains include both MX suffixes above, and Google documents smtp.google.com as its current MX value. Check the current Microsoft endpoint documentation and Google MX record documentation when comparing hostnames.
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.
Read the preference number as delivery order: senders try the lowest number first. Several MX hosts with different priorities often provide failover for one service, so they do not automatically indicate several filters. A, AAAA, and PTR records can support a match, but generic cloud names and shared addresses keep those clues weaker than a vendor-specific MX host. Match the complete hostname suffix, not a brand word embedded in an unrelated domain. SPF includes and DKIM signing domains describe outbound authorization or signing, so they do not establish the inbound filter.
Good MX evidence
A verified service-specific MX host plus a matching rejection host identifies the public receiving service. The reported rejection can still originate downstream, so preserve the full SMTP response before locating the decision point.
Inspect the SMTP greeting and TLS certificate
The MX host's 220 greeting and EHLO response can expose a product family or service hostname. A STARTTLS connection can also reveal certificate names, including Subject Alternative Name (SAN) entries. These are supporting clues because administrators can customize banners, providers can use generic certificates, and shared infrastructure can hide the tenant's filtering policy. The certificate issuer identifies the certificate authority, not the spam filter.
Inspect SMTP and STARTTLSBASH
openssl s_client -starttls smtp \ -connect mx.target.example:25 \ -servername mx.target.example -showcerts -crlf EHLO probe.example QUIT
Treat banners as supporting evidence
- Match: A greeting hostname that agrees with the MX record strengthens the identification.
- Mismatch: A generic banner or shared certificate does not disprove the MX finding.
- Limit: Stop after the greeting and EHLO check. Do not test recipient addresses or attempt policy bypasses.
Inspect trusted email headers
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. Your own receiving service also adds headers to the message, so identify which organization added each clue before attributing it to the company.
Illustrative routing and spam-score headers
Received: from relay.sender.example (relay.sender.example [198.51.100.10]) by mx.receiver.example with ESMTP; Thu, 8 Oct 2026 09:12:00 +0000 Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example X-Spam-Status: No, score=0.1 required=5.0
Good evidence
- Header names: Service-specific X-headers and X-Spam-Status scores are clues only when their source is trusted. Generic spam-score fields do not uniquely identify a product.
- Received path: A security gateway in the trusted Received chain can confirm that mail passed through that product.
- Authentication lines: Trusted Authentication-Results entries name the authentication service and record checks such as SPF, DKIM, and DMARC. ARC results, when present, concern the authenticated forwarding chain, not the spam verdict.
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 generic 5xx rejection indicates permanent failure; a 4xx response indicates temporary failure. Neither identifies the product by itself.
Start with the topmost Received field added by a system you trust, then trace downward only as far as that trust holds. A sender can insert fake Received fields before submission, so untrusted lower lines should not decide the result. Apply the same trust check to Authentication-Results and custom X-headers, as described in RFC 8601.
Headers are strongest when they corroborate DNS for the same mail direction. Headers on a company's outbound message support conclusions about its outbound route. Without headers from a message received by that company or recipient-side logs, they do not confirm the filter used for incoming mail.
Interpret bounce messages and SMTP status codes
Bounces and sending logs can show rejection timing, the responding host, and the enhanced status response. They are poor product identifiers because gateways rewrite messages, mailbox providers normalize wording, and relays can return another system's decision. A 4xx SMTP response is temporary, including some greylisting or throttling responses; a 5xx response is permanent for that delivery attempt.
Rejection text that does not prove spam filtering
Rejected by recipient's email security filter FILTERED 550 5.4.1 Recipient address rejected: Access denied.
What this proves
This 550 response reports a permanent delivery failure. The sender's label does not establish a content-filter verdict or identify a product. Check the recipient address and connect the exact remote response to the responding host and SMTP stage. A rejection during RCPT TO occurs before message content is transmitted.
- Code: The first digit of 550 puts it in the permanent 5xx class. RFC 3463 defines X.4.1 as "No answer from host" in the network and routing category. Microsoft uses 550 5.4.1 for a different, documented recipient-validation rejection.
- Wording: When Exchange Online generates this exact access-denied response, Microsoft's 550 5.4.1 documentation identifies directory-based edge blocking (DBEB) for an invalid or unrecognized recipient. Verify the address before treating it as a spam rejection.
- Next step: Preserve the full delivery status notification (DSN), timestamp with time zone, sending IP, recipient, message ID, and responding host. Retain Reporting-MTA, Remote-MTA, Status, and Diagnostic-Code fields when present, plus the SMTP stage from sending logs.
Spam filter identification workflow using MX records, SMTP hostnames, email headers, bounce messages, and connector checks.
Hidden routing behind Microsoft 365 and Google Workspace
The tricky case is a domain whose MX points at Microsoft 365 or Google Workspace. That host is the public entry point, but accepted mail can still follow a connector or routing rule to another gateway or an internal system.
Microsoft 365 administrators open Mail flow > Message trace in the Exchange admin center. Microsoft documents this location in its message trace FAQ. The image below is illustrative; use the current console's event details to confirm an actual rejection.
Illustrative Microsoft 365 message trace showing a failed email and filtering details.
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 preferred and 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: The recipient admin's trace or gateway log is needed to confirm an internal decision point. A sender's SMTP transcript confirms the public host and response it observed.
Do not name 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.
API-based filtering without MX changes
Some integrated cloud email security uses mailbox APIs instead of a separate SMTP gateway. Post-delivery checks can inspect messages in a mailbox and move or remove them afterward without becoming another SMTP hop. Microsoft documents DNS mail routing and Graph API access as different approaches in its API integration guidance. Public MX records and Received headers therefore cannot identify every filtering layer.
A 250 response after the end of DATA means the receiving server accepted responsibility for the message, as defined in RFC 5321. It does not confirm inbox placement. A 250 reply to RCPT TO alone does not mean the message was accepted.
- Mailbox rules and blocked-sender settings can produce different results for recipients at the same company.
- A Delivered status in Exchange Online message trace can include junk-folder or quarantine outcomes. Inspect the event details, as explained in Microsoft's message trace FAQ.
- Public DNS cannot expose private API integrations or each mailbox's filtering settings.
- Without recipient-side evidence, record the public receiving service and mark additional filtering layers as unconfirmed.
Check your own side first
Before spending time fingerprinting the recipient's filter, check your own sending domain and IP. Authentication failures, broken DKIM, SPF lookup errors, poor sender reputation, and IP or domain listings on a blocklist (blacklist) are possible causes of rejection. Passing authentication does not guarantee inbox placement.
Suped's Domain Health Checker checks sender-side configuration before you infer too much from a remote rejection. Suped's DMARC monitoring helps review authentication results reported by participating receivers, and Suped's blocklist monitoring helps investigate IP or domain blacklist listings. A listing matters to this rejection only if the recipient uses that list.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped's product to review authentication issues and the suggested fixes before repeating a legitimate delivery test. DMARC aggregate reports do not expose the recipient's full filtering stack, per-message rejection reason, or inbox placement.
A practical investigation workflow
Use a repeatable workflow so you do not overstate the result. Keep the raw evidence and assign confidence. Public checks often identify the receiving gateway without contacting the company; request recipient-side logs only when you need to confirm a hidden decision point.
- Lookup: Query MX for the exact recipient domain. Resolve each MX hostname with A and AAAA lookups, then use PTR lookups for the returned IP addresses.
- Classify: Identify the public receiving service using verified hostname suffixes. Record separate confidence for that service and for any additional filtering layer.
- Collect: Save the full DSN and SMTP transcript, including the sending IP, recipient, timestamp with time zone, message ID, and responding host. Record whether rejection occurred at RCPT TO or after DATA.
- Compare: Inspect trusted headers and label each clue as inbound or outbound evidence. Exclude fields added by your own receiving service when identifying the company's infrastructure.
- Verify: Test your own authentication and reputation so the recipient filter is not blamed for your configuration issue.
- Escalate: If public evidence is insufficient, request a recipient-side log search with the sender, recipient, time zone, message ID, and responding host. Preserve an unknown result until it is confirmed.
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
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Keep probing ethical and limited. Do not enumerate recipients, try to bypass policy, or send deceptive mail. Use addresses you are allowed to contact, and treat SMTP tests as troubleshooting, not scanning.
What to do after identifying the public gateway
Knowing the likely spam filter helps you phrase the next action. It does not expose the rules that handled the message. Filtering can use sender authentication, reputation, content analysis, recipient behavior, machine learning, or local policy. Keep complaint rates low, send wanted mail, and give the recipient admin enough detail to find the rejection. Junk-folder delivery of wanted mail is a false positive; investigate it separately from an SMTP rejection or an invalid address.
|
|
|
|---|---|---|
Identified secure email gateway | Keep the exact SMTP response; request a log search if needed | Guessing private filtering rules |
Microsoft 365 | Ask for Exchange admin center trace event details | Ignoring connectors or mailbox API checks |
Google Workspace | Ask for recipient-side delivery logs when needed | Treating MX records as a complete filter inventory |
Unknown | Check sender configuration and preserve the evidence | Naming a product without corroboration |
How to act on the result
Confidence level for filter identification
Apply confidence to the public receiving service separately from any hidden filtering layer.
High
Name the public receiving service
Verified service-specific MX plus matching responding host
Medium
Name the platform; qualify extra layers
Receiving platform identified; extra filtering unconfirmed
Low
State unknown
Generic bounce text without DNS or header match
Record the result precisely: "Their public MX identifies Microsoft 365. A downstream connector or mailbox API check can still affect delivery. Recipient-side logs are needed to locate any internal rejection."
