# How to stop spammers bypassing your filter by delivering straight to your mail server

URL: https://iblockspam.com/blog/block-direct-to-tenant-bypass
Last updated: 2026-10-09
Published: 2026-10-09
Topic: Running email day to day
Author: iBlockSpam Team

> Spammers can skip your MX and deliver straight to Microsoft 365, Google Workspace or your server. Lock each one to your filter, test it, roll back.

## Short answer

Changing MX doesn't stop direct delivery, because your mail server still accepts connections. Lock it to your filter: restrict a Microsoft 365 Partner inbound connector by certificate or IP, turn on Reject all mail not from gateway IPs in Google Workspace, or allow port 25 only from the filter's IPs on your own server. Then test from outside.

An MX-level filter only protects mail that goes through it. Many spammers don't look up MX at all: they deliver straight to a server they already know accepts your domain. This guide explains why that works and how to close the route on Microsoft 365, Google Workspace and your own server.

## Why can spammers skip your MX record?

MX records are how honest senders find your mail server ([RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1)). They aren't access control. Three facts make bypass easy:

- **Cloud tenant hostnames are predictable.** Microsoft 365 mail endpoints follow the pattern `<domain>-com.mail.protection.outlook.com`. Anyone can guess yours.
- **Big platforms accept mail for all their customers.** Google's MX hosts accept mail for any Workspace domain unless told otherwise.
- **Your own server answers on port 25.** If it was ever your MX, or its hostname resolves, it's known. RFC 5321 also lets senders fall back to a domain's address record when no MX exists.

Spam that arrives this way skips your filter's spam, malware and spoofing checks, and doesn't appear in its quarantine or logs. If you're not sure bypass is the cause, [why spam gets through Microsoft 365](https://iblockspam.com/blog/microsoft-365-spam-getting-through) shows how to read the verdict in the headers.

## How do you close the route on each platform?

| Platform | Lockdown control | Where | What it blocks |
| --- | --- | --- | --- |
| Microsoft 365 | Partner inbound connector with `RestrictDomainsToCertificate` or `RestrictDomainsToIPAddresses` | Exchange admin center or PowerShell | Any mail for your domains not arriving from the filter |
| Microsoft 365 (extra) | `Set-OrganizationConfig -RejectDirectSend $true` | PowerShell | Unauthenticated mail using your own domain as sender |
| Google Workspace | **Reject all mail not from gateway IPs** | Admin console > Gmail > Spam, Phishing and Malware > Inbound gateway | Mail not from listed gateway IPs |
| cPanel/WHM or other Linux mail server | Firewall on TCP 25, or per-domain Exim ACL | Server firewall / Exim Advanced Editor | Connections not from the filter |
| Exchange Server (on-premises) | Internet-facing Receive connector limited by `RemoteIPRanges` | Exchange Management Shell | Connections not from the filter |

Placeholders below: `<GATEWAY-IP-RANGES>` and `<GATEWAY-TLS-CERT-NAME>` are your filter's delivery IP ranges and certificate name.

### Microsoft 365

Microsoft's guidance for a filter in front of Exchange Online is to "lock down your Exchange Online organization to only accept mail from your third-party service" using a **Partner** inbound connector ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud)).

1. Make sure a Partner inbound connector exists for the filter, with `-SenderDomains *` and Enhanced Filtering for Connectors enabled.
2. After MX has moved and the old TTL has passed, restrict it. Certificate is preferred:

   ```powershell
   Set-InboundConnector -Identity "<connector name>" `
     -TlsSenderCertificateName <GATEWAY-TLS-CERT-NAME> `
     -RestrictDomainsToCertificate $true -RequireTls $true
   ```

   or by IP:

   ```powershell
   Set-InboundConnector -Identity "<connector name>" `
     -SenderIpAddresses <GATEWAY-IP-RANGES> -RestrictDomainsToIPAddresses $true
   ```

   In the Exchange admin center these are the **Security restrictions** options on the connector. Direct deliveries are then rejected with `5.7.51 TenantInboundAttribution`.

3. If you have an **OnPremises** connector with the same IPs or certificate, you still need the Partner connector. Microsoft notes that the restriction parameters apply only to Partner connectors, and the two can coexist.

4. Optionally, add `Set-OrganizationConfig -RejectDirectSend $true`. It rejects unauthenticated messages sent with your accepted domains as the sender, with `550 5.7.68 TenantInboundAttribution` ([Microsoft Tech Community](https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790)). It doesn't block spam from other domains, so it's a complement to step 2. Microsoft describes Direct Send as an option "only for advanced customers" ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)).

### Google Workspace

1. In **Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway**, confirm every range in `<GATEWAY-IP-RANGES>` is listed under **Gateway IPs**.
2. Select **Reject all mail not from gateway IPs** and save ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway)). Changes can take up to 24 hours.
3. Configure this at the top-level organizational unit.

### cPanel/WHM and other self-hosted servers

- **Only filtered domains on the server:** allow inbound TCP 25 from `<GATEWAY-IP-RANGES>` only (CSF, nftables or your provider's firewall). Keep 587 and 465 open for authenticated users. Outbound mail is unaffected.
- **Shared server:** use a per-domain Exim ACL that refuses unauthenticated mail for filtered domains unless it comes from the gateway. Our [cPanel/WHM guide](https://iblockspam.com/blog/external-spam-filter-cpanel-whm) has an example. Keep the gateway in **Trusted SMTP IP addresses** ([cPanel docs](https://docs.cpanel.net/whm/service-configuration/exim-configuration-manager-basic-editor/)).
- **Exchange Server:** restrict the internet-facing Receive connector's `RemoteIPRanges` to the filter, and keep a separate connector for internal relays.

## What must you sort out before locking down?

1. **Inventory direct senders.** Scanners, ERP/CRM systems, website forms, monitoring tools and some SaaS products deliver straight to your server or tenant. Check message trace or server logs for inbound mail not from the filter over the last few weeks.
2. **Give each a proper route.** In Microsoft 365: authenticated SMTP submission, or an inbound connector from your organization's email server for SMTP relay (our guide to [scan to email with Microsoft 365](https://iblockspam.com/blog/microsoft-365-scan-to-email-smtp) compares the options). In Google: the SMTP relay service. Anywhere: send through the filter.
3. **Confirm MX propagation.** Wait until the old MX TTL has expired and mail is visibly flowing through the filter.
4. **Plan the order for rollback** (below).

## How can you tell if mail is bypassing the filter today?

Before you lock anything down, measure. It tells you how big the problem is and which legitimate senders you would affect.

1. **Pick a few spam messages that reached inboxes** and open their headers in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer). Read the `Received` lines from the bottom up. If the hop just before your mail server isn't your filter, the message went around it.
2. **Search logs by source.** In Microsoft 365, run a message trace for inbound mail over the last few days and look for connecting IPs that aren't the filter. In Google Workspace, use the Email Log Search. On your own server, grep the Exim main log for accepted messages whose host isn't in `<GATEWAY-IP-RANGES>`.
3. **Sort what you find** into spam (to be blocked) and legitimate direct senders (to be moved to a proper route first).

Expect some legitimate entries the first time. Scanners and website forms are the usual ones.

## How do you test the lockdown?

1. From a server that isn't the filter, connect to your mail endpoint on port 25. For example, with the `swaks` tool: `swaks --to user@yourdomain.example --server <your mail endpoint>`.
2. Expected results: Microsoft 365 rejects with `5.7.51`; Google rejects the message; your own server refuses the connection or the recipient.
3. Send a normal message from an outside mailbox and confirm it still arrives, through the filter. Check headers with the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer).
4. Watch quarantine and logs for a day for unexpected rejections from legitimate direct senders.

An [MX Lookup](https://iblockspam.com/tools/mx-lookup) can't prove mail is filtered, and it can't show whether direct delivery is blocked. Only the direct test does. For the full set of routing, filtering and delivery checks, see [how to test that a spam filter is working](https://iblockspam.com/blog/how-to-test-spam-filter-is-working).

## How do you roll back?

Remove the lockdown **before** pointing MX back at the server. Otherwise, internet mail that now arrives directly is rejected.

1. Microsoft 365: `Set-InboundConnector -Identity "<connector name>" -RestrictDomainsToCertificate $false -RestrictDomainsToIPAddresses $false`. Reverse `RejectDirectSend` only if a legitimate sender needs it.
2. Google: clear **Reject all mail not from gateway IPs**.
3. Server: remove the firewall rule or ACL.
4. Then change MX, and keep the filter active until the old TTL has passed.

## What are the common mistakes?

- **Locking down before MX has propagated.**
- **Forgetting a gateway range,** which rejects legitimate filtered mail.
- **Relying on RejectDirectSend alone** in Microsoft 365.
- **Leaving the old server as a backup MX,** which advertises the bypass route.
- **Closing port 25 on a shared server** that hosts unfiltered domains.

## How iBlockSpam helps

The iBlockSpam setup wizard shows the exact IP ranges and certificate name to use in your lockdown, and gives rollback steps in the right order for Microsoft 365, Google Workspace and cPanel/WHM. Domain monitoring alerts you when your MX, SPF or DMARC records change, which catches an MX that has drifted back to your server. iBlockSpam can't apply the lockdown inside your tenant or server for you, and it can't see mail that bypasses it, so the direct-delivery test above is the check to repeat after any change.

## Next steps

1. Send a test message straight to your tenant's or server's own MX host from an outside system and confirm it's refused.
2. Check the public MX answer with the free [MX Lookup](https://iblockspam.com/tools/mx-lookup), and read a delivered message's path with the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer).

If you use iBlockSpam, its [domain monitoring](https://iblockspam.com/features/domain-monitoring) alerts you when your MX records stop pointing at the filter, one of the common ways a bypass opens up again.

Browse more guides on [running email day to day](https://iblockspam.com/blog/topic/operations).

## Frequently asked questions

### Isn't changing the MX record enough?

No. MX records tell honest senders where to deliver. Nothing forces a sender to use them. If your mail server still accepts mail from anyone, a spammer who knows its address can deliver straight to it and skip the filter.

### Does RejectDirectSend in Microsoft 365 solve this?

Only part of it. It rejects unauthenticated mail that uses one of your own accepted domains as the sender. Spam from other domains, delivered straight to your tenant, needs the restricted Partner connector.

### Will locking down break anything?

It can break senders that deliver straight to your server: scanners, line-of-business apps, website forms and some third-party services. List them first and move them to authenticated submission, their own connector, or through the filter.

### How do I know if spammers are bypassing my filter now?

Look at the headers of spam that reached a mailbox. If the hop before your mail server isn't your filter, it was delivered directly. Our Email Header Analyzer shows the path.

## Sources

- [Microsoft Learn: Manage mail flow using a third-party cloud service with Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud)
- [Microsoft Learn: How to set up a multifunction device or application to send email (Direct Send)](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)
- [Microsoft Tech Community: Introducing more control over Direct Send in Exchange Online](https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790)
- [Google Workspace Admin Help: Set up an inbound mail gateway](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway)
- [cPanel docs: Exim Configuration Manager Basic Editor](https://docs.cpanel.net/whm/service-configuration/exim-configuration-manager-basic-editor/)
- [RFC 5321: Simple Mail Transfer Protocol (section 5.1)](https://www.rfc-editor.org/rfc/rfc5321#section-5.1)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/block-direct-to-tenant-bypass (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt