Gateway bypass: rejecting direct send and enforcing your own path

MailGuard inspects every message that passes through the gateway. Anything that gets past it is uninspected. There are three ways past, and all three can be closed.

1. Direct send in Microsoft 365

Microsoft 365 accepts mail for your own domains from any sender on the internet if it is delivered to the endpoint your-domain-com.mail.protection.outlook.com. Nobody needs an account, a password or a connector for that. The path is called direct send and is meant for devices on your own network, such as printers and line-of-business applications that cannot authenticate.

For an attacker it is the bypass: they deliver to that endpoint, the gateway never sees the message, and the recipient receives it uninspected. The only protection left is Microsoft's own.

How to close it. One setting in the Exchange Online organisation:

Set-OrganizationConfig -RejectDirectSend $true

After that, Exchange Online rejects mail for your domains that does not arrive over a connector. Conbool's guided setup sets it for you on request, under Settings, Microsoft 365, set up Exchange. You can also set it yourself; the way back is $false.

Check first. Everything that delivers over direct send today stops working afterwards. Typically that means:

• multifunction printers with scan-to-mail
• inventory, time tracking and ticket systems on your own network
• monitoring systems that send alerts by mail

Each of these has two clean replacements: authenticating with its own mailbox over SMTP AUTH, or a dedicated connector for the fixed outbound address of your site. The second is meant for devices that cannot authenticate.

You will find the affected deliveries in the Microsoft 365 message trace: filter for inbound mail with no connector.

2. The MX record points elsewhere

The gateway only receives mail if your domain's MX record points at it. If the old target is still there, everything bypasses the gateway even though the portal looks fully configured.

Conbool checks this daily for every verified domain. If the MX does not point at us, the domain's protection state changes to MX missing and the administrators are notified. You can see the state in the module under MailGuard, overview.

You can check it yourself with:

dig MX your-domain.com

The expected answer is mail.conbool.com.

3. The second MX record

A second MX record with a higher preference number is meant as a fallback. An attacker reads it just like anyone else and deliberately delivers there, because they expect no inspection. If the second record points at your target system rather than at us, it is an open door.

For fallback, Conbool has continuity: it accepts mail and holds it for as long as your mailbox is unreachable. A second MX record at the target system is therefore unnecessary.

What Conbool cannot see

Only Microsoft can see whether mail is being delivered over direct send. A message that never reaches us leaves no trace with us, and we have no access to your tenant's message trace. Checking that gap is therefore yours, and this page is the instruction for it.

What we do see and report is the MX record of every verified domain, daily.