How do you test that your spam filter is actually working?

A dashboard that says "protected" tells you what the service believes. It doesn't tell you what happened to the last message a customer sent you. This guide shows how to prove, with evidence, that your spam filter is in the mail path, doing its job, and delivering clean mail to the right place.

Use it after a new setup, after any routing change, or when you suspect something has quietly stopped working. If you're comparing products before you buy, our spam filter trial checklist covers that; this guide is about accepting a deployment you already have.

What are the three proofs?

Each proof answers a different question. Passing one says nothing about the other two.

A common mistake is to treat a passing Email Health Check as proof of all three. It reads public DNS, so it's a good start for routing and authentication records. It can't see your mail.

Before you start: what do you need?

1. An outside mailbox that has nothing to do with your domain, such as a personal Gmail or Outlook.com account.
2. Admin access to the filter's log or quarantine, and to your mail platform's trace: message trace in Microsoft 365 or Email Log Search in Google Workspace.
3. A list of the addresses that matter most: a normal user, a shared address such as accounts@, and anything customers write to.
4. A simple log. For each test, write the time, sender, recipient, a unique subject such as FILTER-TEST-01, the expected result and the actual result.

Tell your IT contact or provider before sending test messages, so nobody treats them as an incident.

Proof 1: is mail routed through the filter?

Check the MX records

Run the MX Lookup for your domain. Every MX host should belong to the filter. A leftover record pointing at your old server or straight at your mail platform gives senders a way around it, even at a lower priority. If you changed MX recently, allow for the old TTL; see DNS TTL and MX propagation.

Check the headers of a real message

Send a plain message from your outside mailbox to a normal user. Open it, copy the full headers and paste them into the Email Header Analyzer. Read the Received lines from the bottom up: you should see the sender's server, then the filter's servers, then your mail platform. If the filter's servers are missing, that message didn't go through it. Our guide on how to read email headers explains each line.

On Microsoft 365, Enhanced Filtering for Connectors adds an X-MS-Exchange-ExternalOriginalInternetSender header when it identifies the true source, according to Microsoft Learn. Its presence is a good sign the connector and the skip list are working together. See Enhanced Filtering with a third-party filter.

Check that the direct path is closed

MX records are a request, not a wall. A sender can connect straight to your mail platform's own endpoint and skip the filter. Confirm that your platform only accepts inbound internet mail from the filter:

• Google Workspace: the inbound gateway setting has an option to reject all mail that doesn't come from your gateway IPs.
• Microsoft 365: a partner connector restricted to the filter's IP addresses, or an equivalent mail flow rule, does the same job.

Our guide to blocking direct-to-tenant bypass has the steps. Test it only on your own tenant and with your administrator's approval.

Proof 2: is the filter applying its policies?

Use safe, published test samples. Never send real malware or a real phishing kit to production users.

1. Spam handling. Send a message containing the GTUBE string from your outside account. The Apache SpamAssassin project publishes it so you can "verify that the filter is installed correctly and is detecting incoming spam". Many filters recognize it, but not all, so ask your provider first.
2. Malware handling. Attach the EICAR test file. It isn't a virus, and anti-malware engines are designed to detect it. Some outside mail services refuse to send it, so you may need a mail client on a test machine.
3. Your own rules. If you block certain attachment types or countries, send one harmless example that should match.
4. Spoofing of your own domain. If your domain has DMARC at p=quarantine or p=reject (check with the DMARC Checker), ask your provider for a safe way to test that a message forging your domain is held.

For each test, record where the result appears: rejected, held in quarantine, tagged, or delivered. Then find the same message in the filter's log. A result you can't trace isn't evidence.

If a test message is delivered when you expected it to be held, check Proof 1 again before changing any settings. The most common cause is a route that skipped the filter, not a weak policy.

Proof 3: does clean mail reach the right inbox?

Normal mail

Send a plain message to each address on your list, including shared ones. Confirm each arrived in the inbox, not in Junk. A filter can report "delivered" as soon as your platform accepts the message, and your platform can still route it to Junk or its own quarantine afterwards. Check the platform's trace as well as the filter's log.

Released mail

Pick a held test message that is safe to release, such as a GTUBE message. Release it as the user would, then as an admin. Confirm it reaches the mailbox. "Released" in the quarantine doesn't prove delivery until it's in the inbox. Our guide to email quarantine covers who should be allowed to release what.

Access to held mail

Confirm that one user can't see another user's held messages, and that a shared address's held mail is visible only to the people responsible for it. See shared mailbox spam protection for how to assign that role.

Platform protection after the filter

Microsoft says that if you put a non-Microsoft service in front of Microsoft 365, you should enable Enhanced Filtering for Connectors "so detection, reporting, and investigation features in Microsoft 365 are able to correctly identify message sources" (Anti-spam protection FAQ). Don't create a blanket rule that skips Microsoft's filtering for everything from the gateway just to make tests pass. The same page warns that allowlists "create a high risk of attackers successfully delivering malicious email".

What does each failure usually mean?

When a message is missing, our guide on why an email went to spam or quarantine helps you read the verdict.

A one-page acceptance record

Copy this table into your change notes. Don't call the domain verified until every row passes or has a written exception.

An incomplete row means "unverified", not "secure". Repeat rows 1, 2, 3 and 6 after any change to MX, connectors or gateway settings.

When should you run the tests again?

• After setup, before you turn off the old route.
• After any MX, connector, gateway or IP allowlist change.
• After moving to a new mail platform or adding a new domain.
• When users report spam they think should have been caught, or real mail that went missing.

Between changes, DNS monitoring can catch records that drift. iBlockSpam's domain monitoring checks MX, SPF and DMARC weekly on Protect and daily on Protect Plus, and the free Domain Watch does a weekly public DNS check for one domain. Neither sees your mail, so keep the message tests.

Next steps

1. Run the Email Health Check and save the result as row 1 of your record.
2. Send one clean message from outside and check its headers with the Email Header Analyzer.
3. Agree a GTUBE and EICAR test with your provider, then fill in the rest of the table.
4. If you're moving to iBlockSpam, each domain page in the portal has a setup verifier that checks MX routing, your outgoing SPF, DKIM and DMARC from a test message, and the platform steps. You can look around the portal demo first, or get started with one domain. Our cutover plan includes rollback steps.

See more operations guides.