The problem in a nutshell

In a centralized mail flow setup, every inbound message is supposed to travel a single,
well-defined path: the public MX record points at a third-party Secure Email Gateway
(Mimecast, Proofpoint, Cisco IronPort, Barracuda, an on-premises Exchange edge — pick your
flavor), the gateway scans and filters the message, and only then is it handed off to
Exchange Online Protection through an authenticated connector.

In the real world, things are messier. Many organizations notice — sometimes only after
a successful phishing attempt — that mail is reaching mailboxes directly through
EOP, completely bypassing the gateway that was supposed to be the first line of
defense. Often these messages are spoofed, claiming to come from internal addresses such
as ceo@yourcompany.com.

The desired state

What we want to achieve:

• Block Direct Send — anonymous mail using your own domains, sent straight to EOP, must be rejected.
• Restrict the inbound connector — only the SEG’s IPs or TLS certificate may deliver mail.
• Stop spoofing — strict SPF, DKIM and DMARC, plus EOP anti-spoofing in enforcement mode.
• Stay auditable — message trace and Defender reports must show every bypass attempt.

Why does EOP accept mail directly in the first place?

Every Microsoft 365 tenant has a publicly resolvable MX endpoint of the form
.mail.protection.outlook.com. Regardless of where your MX record
actually points, that endpoint is reachable from the internet and — by default —
accepts anonymous SMTP connections for any of your accepted domains.
Microsoft calls this mechanism Direct Send.

Direct Send is officially intended for printers, scanners, and legacy line-of-business
apps that need to drop mail into internal mailboxes without authenticating. Convenient —
but it’s also exactly the mechanism attackers exploit to bypass your gateway and impersonate
internal senders.

The fix is multi-layered: the tenant-wide RejectDirectSend flag, a tightly
restricted inbound connector, a transport rule as a safety net, and proper anti-spoofing
configuration. We’ll walk through each of them.

Prerequisites

Permissions

• Organization Configuration (for Set-OrganizationConfig)
• Exchange Administrator or Global Administrator (connectors and rules)
• Security Administrator (Defender policies and anti-phishing)

Tooling

# Install the Exchange Online module if you haven't already
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser

# Connect
Connect-ExchangeOnline -UserPrincipalName admin@yourcompany.com

Information to gather upfront

• The full list of public IP addresses or ranges used by your SEG, including DR/secondary regions.
• Optionally, the TLS certificate subject / SAN the SEG presents when delivering to EOP — preferred over IP binding.
• All accepted domains of the tenant: Get-AcceptedDomain.
• Document existing inbound connectors: Get-InboundConnector | Format-List.
• Current SPF, DKIM, and DMARC records for each sending domain.

Step 1 — Enable Reject Direct Send

The simplest and most powerful single switch is the tenant-wide
RejectDirectSend flag. When it is enabled, EOP rejects any anonymous
message whose P1 Mail-From address matches one of your accepted domains, unless
it arrived authenticated through an inbound connector. The sender receives the NDR
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization
from unauthorized sources.

1. Check the current state.

   Get-OrganizationConfig | Select-Object Identity, RejectDirectSend

   On existing tenants the default is False. Microsoft has announced that new tenants will get True by default starting in 2026.

2. Enable Reject Direct Send.

   Set-OrganizationConfig -RejectDirectSend $true

   Propagation across all EOP servers takes up to 30 minutes.

3. Verify.

   Get-OrganizationConfig | Format-List RejectDirectSend
   # Expected: True

Step 2 — Restrict the inbound connector to SEG IPs or certificate

RejectDirectSend only covers messages whose sender domain is one of your own
accepted domains. Spoofed mail from foreign domains delivered straight to
EOP would still be accepted. To close that gap, configure your Partner inbound
connector so that EOP only accepts inbound mail from the SEG’s IPs or matching TLS
certificate.

Option A — Configuration in the Exchange Admin Center

1. Open EAC at https://admin.exchange.microsoft.com →
   Mail flow → Connectors → Add a connector.
2. Define the connection:
   • Connection from: Partner organization
   • Connection to: Office 365
3. Authenticate the partner: prefer
   “By verifying that the subject name on the certificate that the sending server uses to
   authenticate with Office 365 matches this domain name” and enter the certificate the
   SEG actually presents. As a fallback — when no TLS certificate is available —
   “By verifying that the IP address of the sending server matches one of the following
   IP addresses” with all of the SEG’s outbound IPs.
4. Enforce delivery rules:
   • Reject email messages if they aren’t sent over TLS
   • Reject email messages if they aren’t sent from within this IP address range (with the SEG IPs)
5. Save and enable the connector.

Option B — PowerShell (idempotent and auditable)

# Example: SEG identifies itself via certificate (recommended)
New-InboundConnector -Name "From Secure Email Gateway" `
    -ConnectorType Partner `
    -SenderDomains "*" `
    -RestrictDomainsToCertificate $true `
    -TlsSenderCertificateName "*.mail-gateway.example.com" `
    -RequireTls $true `
    -Enabled $true

# Alternative: SEG identifies itself by IP range
New-InboundConnector -Name "From SEG (IP-bound)" `
    -ConnectorType Partner `
    -SenderDomains "*" `
    -RestrictDomainsToIPAddresses $true `
    -SenderIPAddresses "203.0.113.10","203.0.113.11","198.51.100.0/28" `
    -RequireTls $true `
    -Enabled $true

Step 3 — Add a transport rule as a safety net

Beyond the connector, it’s smart to add a transport rule as a second layer that rejects
any external mail not arriving from your allowed IP range. It protects you
against connector misconfiguration and produces a very clean audit trail in message trace.

Configuration in the EAC

1. EAC → Mail flow → Rules → Add a rule → Create a new rule.
2. Name: BLOCK – Direct internet ingress without SEG
3. Apply this rule if…
   • The sender → is external/internal → Outside the organization
4. Do the following: Block the message →
   Reject the message and include an explanation →
   Reason: “Mail to this organization must be delivered via the official Secure Email Gateway.
   Direct delivery to EOP is not permitted.”
5. Except if:
   • The sender → IP address is in any of these ranges → your SEG IPs
   • or The message headers → includes any of these words → header
     X-MS-Exchange-Organization-AuthAs with value Internal
     (prevents breaking internal hybrid mail flow)
6. Rule mode: start in Test with policy tips, then switch to Enforce after validation.

PowerShell variant

New-TransportRule -Name "BLOCK - Direct EOP Ingress (Bypass SEG)" `
    -FromScope NotInOrganization `
    -ExceptIfSenderIPRanges "203.0.113.10","203.0.113.11","198.51.100.0/28" `
    -ExceptIfHeaderMatchesMessageHeader "X-MS-Exchange-Organization-AuthAs" `
    -ExceptIfHeaderMatchesPatterns "Internal" `
    -RejectMessageEnhancedStatusCode "5.7.1" `
    -RejectMessageReasonText "Mail not delivered via SEG." `
    -Mode AuditAndNotify `
    -Enabled $true

Step 4 — Anti-spoofing and DMARC

The previous steps lock down the transport path. Spoofing attempts that travel correctly
through the SEG (because an attacker hijacked some other domain or abused an open relay)
still need to be caught by authentication checks.

4.1 SPF, DKIM and DMARC for your domains

• SPF: hard fail (-all), only your SEG egress IPs and legitimate cloud senders (e.g. spf.protection.outlook.com).
• DKIM: enable signing for every sending domain in the Defender portal under
  Email & collaboration → Policies → Email authentication settings → DKIM.
• DMARC: at minimum p=quarantine, target p=reject with
  rua=mailto:dmarc-reports@yourcompany.com. Use a DMARC reporting service
  (dmarcian, Valimail, Postmark, etc.) to make the RUA/RUF data actionable.

# SPF record
yourcompany.com.   IN TXT "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:spf.protection.outlook.com -all"

# DMARC record
_dmarc.yourcompany.com.  IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; ruf=mailto:dmarc@yourcompany.com; fo=1; adkim=s; aspf=s"

4.2 Anti-phishing policy (Defender for Office 365)

In the Defender portal under Email & collaboration → Policies & rules
→ Threat policies → Anti-phishing, harden the default policy or create a
dedicated one for high-value recipients:

• Spoof intelligence: Enabled
• Honor DMARC policy: Enabled (so messages with p=reject are actually rejected)
• Action for unauthenticated senders: Quarantine
• Impersonation protection: explicitly cover sensitive mailboxes (CEO, finance, HR)
• Mailbox intelligence: Enabled

4.3 Anti-spam policy

• Bulk Complaint Level (BCL) threshold: 6 or lower
• Spam action: Quarantine
• High-confidence phish action: Quarantine
• Avoid allow lists — they’re a frequent root cause of spoofing slip-throughs.

Step 5 — Enhanced Filtering for Connectors

Because the SEG overwrites the original sender IP, EOP would normally evaluate SPF against
the SEG’s IP rather than the actual sender — meaning every phishing attempt passes SPF
effortlessly. Enhanced Filtering for Connectors (also known as skip listing)
fixes this by telling EOP to look further back in the Received header chain to find the real
sender IP.

1. Open the Defender portal at https://security.microsoft.com/skiplisting
   (or Email & collaboration → Policies & rules → Enhanced filtering).
2. Select the inbound connector you created in Step 2.
3. Choose Skip these IP addresses that are associated with the connector
   and add all public IPs of the SEG (including any intermediate hops).
4. Apply to entire organization after a small pilot phase with a few mailboxes.

Verification & testing

Test 1 — Direct Send from an external host

From an external system, attempt a direct SMTP delivery to the EOP endpoint:

Send-MailMessage `
    -From "ceo@yourcompany.com" `
    -To "recipient@yourcompany.com" `
    -Subject "Direct Send Test" `
    -Body "Testing the Reject Direct Send flag" `
    -SmtpServer "yourcompany-com.mail.protection.outlook.com" `
    -Port 25

Expected result:

550 5.7.68 TenantInboundAttribution;
Direct Send not allowed for this organization from unauthorized sources

Test 2 — Spoof from a foreign domain bypassing the SEG

External test using a foreign sender domain (e.g. fake@gmail.com) directly to the EOP endpoint:

Expected result:

550 5.7.51 TenantInboundAttribution;
There is a partner connector configured that matched the message's recipient domain

Test 3 — Legitimate mail through the SEG

Send an external test message from Gmail or Outlook.com to an internal recipient. In message
trace, verify that the mail arrived from the SEG IP, was accepted by the inbound connector,
and delivered correctly.

Get-MessageTrace -RecipientAddress "recipient@yourcompany.com" -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
    Select-Object Received, SenderAddress, FromIP, Status, Subject

Test 4 — Header analysis

Inspect a delivered message via File → Properties in Outlook or paste the headers
into the Message Header Analyzer.
The following headers confirm a healthy configuration:

• Authentication-Results-Original shows SPF pass against the real sender IP — not the SEG IP.
• The Received chain shows the SEG as the last hop before EOP.
• X-MS-Exchange-SkipListedInternetSender is set, indicating Enhanced Filtering is working.

Monitoring & reporting

Daily / weekly

• Message trace: filter on status Failed with reason 5.7.68 or 5.7.51 — every hit is a blocked bypass attempt.
• Defender → Reports → Mailflow: Threat protection status and Spoof detections.
• Transport rule reports: Mail flow → Reports → Mail flow rule matches — your safety-net rule from Step 3.
• DMARC aggregate reports: review RUA reports — every unknown source is a signal worth investigating.

Useful KQL queries (Defender for Office 365 hunting)

// Direct Send attempts in the last 7 days
EmailEvents
| where Timestamp > ago(7d)
| where DeliveryAction == "Blocked"
| where DeliveryLocation == "Failed"
| where AdditionalFields has "5.7.68"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, SenderIPv4, Subject

// Mail that did NOT arrive from your SEG IPs
EmailEvents
| where Timestamp > ago(1d)
| where SenderIPv4 !in ("203.0.113.10","203.0.113.11")
| where EmailDirection == "Inbound"
| summarize count() by SenderIPv4, SenderFromDomain

Alerting

• Defender alert policy on Mail flow rule match for the safety-net rule.
• SIEM forwarding (Sentinel, Splunk, etc.) of the EmailEvents table.
• A weekly review report sent to the security team.

Rollback plan

If business-critical mail flows break after activation, the commands below let you revert
quickly. The rollback order is the reverse of the activation order.

# 1. Disable the transport rule
Disable-TransportRule -Identity "BLOCK - Direct EOP Ingress (Bypass SEG)"

# 2. Loosen the inbound connector (drop IP binding)
Set-InboundConnector -Identity "From Secure Email Gateway" `
    -RestrictDomainsToIPAddresses $false

# 3. Disable Reject Direct Send
Set-OrganizationConfig -RejectDirectSend $false

# Confirm
Get-OrganizationConfig | Format-List RejectDirectSend

Final checklist

• Direct Send sources inventoriedSPF analyzed, every printer / app / cloud service sending as your domain documented
• Configuration backup takenGet-OrganizationConfig, Get-InboundConnector, Get-TransportRule exported
• Inbound connector with IP/cert binding activeRestrictDomainsToIPAddresses or RestrictDomainsToCertificate set to $true
• Reject Direct Send enabledSet-OrganizationConfig -RejectDirectSend $true applied and propagated
• Transport rule (safety net) activeReject rule for non-SEG IPs in enforce mode, correctly prioritized
• SPF / DKIM / DMARC enforcedSPF -all, DKIM signing for all sending domains, DMARC at least p=quarantine
• Anti-phishing policy hardenedSpoof intelligence + Honor DMARC + quarantine for unauthenticated senders
• Enhanced filtering configuredSkip listing of SEG IPs at the inbound connector enabled
• Tests performedDirect Send blocked (550 5.7.68), legitimate mail via SEG delivered, headers correct
• Monitoring in placeMessage trace reviews, KQL hunting, DMARC reporting, alerting

References & further reading

• Microsoft Learn — Email routing in Exchange hybrid deployments
• Microsoft Learn — Enhanced Filtering for Connectors
• Microsoft Learn — Configure the default connection filter policy
• Microsoft Tech Community — Introducing more control over Direct Send
• Microsoft Learn — Mail flow rules in Exchange Online
• Defender portal — https://security.microsoft.com/skiplisting
• Exchange Admin Center — https://admin.exchange.microsoft.com