The block-all-external spoofing rule looked clean in the transport rule wizard: sender is outside the organization, SPF fails, and the message gets rejected. It went live at 09:00. By 10:30 the service desk had 40 tickets from people who could not receive invoice notifications, calendar invites from a partner tenant, or password reset mail from a SaaS payroll platform. None of that mail was forged. The SPF record simply never listed those senders, and the rule did exactly what it was told.
That failure mode is the reason this checklist exists. Exchange Online transport rules that block spoofed senders lean on SPF as their only source of truth, and SPF is a DNS record maintained by humans, often by someone who left the company two years ago. If a sending source is missing from the record, the rule treats legitimate mail as spoof and drops it silently. A Microsoft 365 catch-all mailbox makes this harder to spot, because unknown-recipient traffic and catch-all routing can hide which senders are actually reaching your users. Before you flip a spoofing rule from audit to enforce, you need proof that every legitimate sender passes SPF, that your accepted domain configuration behaves as expected, and that mail flow rules do not collide with each other.
What follows is the order of operations I use on tenant cleanups: inventory every sender, validate the record against real mail flow, confirm how internal relay and catch-all behavior interacts with the rule, then stage and monitor before enforcing. Skip a step and the rule will still work. It will just block the wrong mail.
Why Spoofing Rules Fail Without a Complete SPF Inventory
A transport rule that blocks spoofed mail in Exchange Online is a thin layer of logic sitting on top of one assumption: that SPF tells the truth about who is allowed to send as your domain. The rule itself does very little. It reads the envelope and header senders, checks whether the message came from outside the organization, and then asks whether authentication passed. If SPF returns a fail or a softfail for an external message claiming to be from your domain, the rule acts. If SPF returns pass, neutral, or none, the rule stands down. Every decision the rule makes is inherited from DNS.
That inheritance is why a block-all-external spoofing rule is only as good as the SPF record behind it. Tighten the rule before the record is complete and you do not block forgery, you block business mail. A newsletter platform that sends on your behalf but is missing from the SPF record will fail the check, look exactly like a spoofer, and get rejected or quarantined. The recipients who complain loudest are usually the ones on a marketing list or an invoice system that nobody added to DNS.
Start with the mechanics. Microsoft 365 lacks a native catch-all setting, and it also lacks a native “block all spoofing” switch. What you get is a mail flow rule with conditions such as “sender is located outside the organization” combined with “authentication result” checks on SPF and DKIM. The rule evaluates per message. It has no memory and no inventory. It cannot know that your accounts payable team sends statements through a third-party billing service unless SPF vouches for that service.
The domain configuration underneath matters just as much as the rule. Authoritative accepted domains enable Directory-Based Edge Blocking, and DBEB rejects mail for unknown recipients at the edge before the message ever reaches transport rules. Internal relay domains relay mail for unknown recipients onward instead. If your tenant is set to internal relay when all recipients live in Microsoft 365, Microsoft documentation advises against that choice, and it changes how unknown-recipient mail behaves when a spoofing rule is in play. A catch-all workaround built on internal relay without an on-premises server, or a shared mailbox with aliases designed to preserve an authoritative domain, both alter the surface the rule sees.
Here is the failure pattern to watch for. A message arrives from an external IP, claims your domain in the From header, and fails SPF because the sending service was never added to the record. The spoofing rule fires. If the rule is set to reject, a legitimate invoice never lands. If it is set to redirect to the junk folder or to a moderation mailbox, the sender gets silence and the recipient gets nothing. Multiply that by every SaaS tool, mailing list, and internal relay host in your environment and you have a support queue full of false positives within a week.
The checklist that follows exists to prevent that. Before any spoofing rule goes live, you need a complete inventory of legitimate senders, a verified SPF record that passes for real mail flow, confirmed behavior for internal relay and catch-all paths, and a staged rollout with monitoring. Skipping the inventory step means the rule is guessing, and guessing in transport rules is how legitimate mail dies quietly.
Checklist Step 1: Enumerate Every Legitimate Sender in Your SPF Record
Before you touch a transport rule, build a sender inventory. An SPF record that misses one legitimate source turns into a false positive the moment your spoofing rule goes live, and the complaint lands in your queue, not the rule author’s. Work through the categories below and mark each one as covered, missing, or not applicable.
1. Microsoft 365 itself. Start with the tenant’s own outbound path. If you send from Exchange Online only, the record should end with include:spf.protection.outlook.com. Confirm the domain is an authoritative accepted domain in Exchange admin center and that no leftover on-premises hybrid connector is still injecting mail. A stale hybrid entry is the most common reason a sender passes SPF in testing and fails after cutover.
2. Mailing lists and discussion groups. Lists are the classic false positive. Many rewrite the envelope sender to the list address, so SPF is evaluated against the list domain, not yours. Others forward the original envelope and break SPF entirely. Pull a list of every list server and bulk sender that posts mail claiming your domain, and decide per list whether it needs an include, an ip4 entry, or a move to a subdomain with its own record.
3. SaaS and third-party senders. Walk the billing and procurement records, not just the mail logs. Marketing platforms, ticketing systems, HR tools, e-signature services, and payment processors all send on your behalf. Each vendor publishes an include or a set of IP ranges; use the include where it exists and pin ip4 or ip6 only for vendors that give you static addresses. Anything you cannot confirm belongs in the inventory as unverified, not assumed safe.
4. Application and device relays. Printers, scanners, monitoring systems, and line-of-business apps that send through an SMTP relay need to appear as well. If they relay through Exchange Online, they inherit the Microsoft include. If they relay through an on-premises mail server or a smart host, that host’s public IP goes into the record as ip4. Check the relay’s outbound IP, not its internal address.
5. The catch-all mailbox. A Microsoft 365 catch-all mailbox setup changes the picture. If you run an Exchange Online catch-all through an internal relay mail flow rule, mail for unknown recipients is redirected to one shared mailbox. That redirect preserves the original envelope sender, so SPF still passes or fails on the real sender domain. Confirm that any sender feeding the catch-all is in the inventory; otherwise the redirect quietly delivers spoofed mail into the catch-all inbox instead of the junk folder.
6. Verify the mechanism, not just the name. For every entry, check the syntax: include: for domains that publish their own record, ip4: and ip6: for static ranges, a and mx only where you control the DNS. Do not stack includes you cannot audit. Each include costs DNS lookups against the 10-lookup limit, and a record that silently exceeds it returns permerror, which fails SPF for every sender at once.
Sign off the inventory only when every row reads covered or not applicable. A single unverified sender is enough to make the spoofing rule block real business mail.
Checklist Step 2: Verify the SPF Record Passes for Real Mail Flow
An SPF record that exists is not the same as an SPF record that passes. Before you flip a spoofing transport rule to reject, you need proof that every real sender produces an SPF pass result at the moment it matters. Office 365 catch-all email covers this in more depth. That means DNS-level validation plus live test messages, not a read-through of the TXT record.
Start with the lookup budget. SPF allows a maximum of 10 DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) during evaluation. Each include pulls in another record that may itself contain includes. A typical stack of a marketing platform, a ticketing system, and two SaaS senders can burn 8 to 9 lookups on its own; add one more vendor and the record returns permerror, which most receivers treat as a fail. Use a lookup counter on the exact record published on your sending domain, then on each domain you reference. If you are near the ceiling, flatten the record by resolving vendor includes to explicit ip4 and ip6 mechanisms and rechecking quarterly.
Next, confirm the record resolves and parses. Query the TXT record at the apex of each sending domain, verify there is exactly one SPF record (two records cause permerror), and check the all qualifier. A record ending in -all is the right end state before you block; ~all tells receivers to softfail, which many spam filters score as suspicious but not definitive. Note that SPF breaks on forwarding, so any mailing list or .forward rule that rewrites the envelope sender will fail SPF downstream. That is a DKIM problem, not an SPF one, and your spoofing rule needs to account for it.
Then send test messages from every source in your inventory to a controlled mailbox and read the Authentication-Results header. You want spf=pass with the correct smtp.mailfrom domain. Test from the actual platform, not from your desk: a SaaS sender that routes through its own infrastructure may present a different envelope domain than the one in the From header.
Catch-all configurations are where this gets messy. If you run an Exchange Online catch-all through an internal relay domain and a mail flow rule that redirects unknown-recipient mail to one mailbox, messages sent to nonexistent addresses still arrive, and their authentication results get folded into a shared mailbox that mixes legitimate and spoofed traffic. That noise makes it hard to tell whether a given sender passed. Worse, a shared mailbox with aliases preserves an authoritative domain, so Directory-Based Edge Blocking rejects mail for unknown recipients at the edge and your catch-all never sees it. Test the catch-all path separately: send to a deliberately invalid address from each legitimate sender and confirm the redirect rule fires and the message still shows spf=pass. If your catch-all relies on an internal relay domain, remember that internal relay expects a connector to an on-premises mail server; without one, Microsoft documentation advises against selecting internal relay when all recipients are in Microsoft 365, and unknown-recipient mail is dropped rather than redirected.
Document the pass results per sender, including the envelope domain and the receiving IP range. You will need that baseline in the next step, when the spoofing rule starts generating false positives and you have to tell a broken SPF record apart from a genuine spoof.
Checklist Step 3: Confirm Internal Relay and Catch-All Behavior Before Blocking
Spoofing rules judge the envelope sender, not the mailbox the message lands in. That distinction matters the moment a catch-all or relay path sits in front of your transport rule. Test these paths before you flip a rule to reject, or you will drop mail that looks spoofed but is not.
Start with the accepted domain type. Authoritative accepted domains enable Directory-Based Edge Blocking, and DBEB rejects mail for unknown recipients at the edge. If you have configured an Exchange Online catch-all by switching a domain to internal relay, DBEB no longer rejects unknown recipients, because internal relay relays mail for unknown recipients onward. Microsoft documentation advises against selecting internal relay when all recipients are in Microsoft 365, and for good reason: internal relay expects a connector to an on-premises mail server. The common catch-all workaround uses internal relay without an on-premises server and pairs it with a mail flow rule that redirects unknown-recipient mail to one mailbox. That redirect rule and your spoofing rule now share the same message flow, and order of rule processing decides the outcome.
Walk through the paths in this order.
- Send a message from an external address to a nonexistent address in the internal relay domain. Confirm the redirect rule catches it and the spoofing rule does not reject it first. Rules process top to bottom, so put the redirect rule above the spoofing rule or scope the spoofing rule to exclude the catch-all recipient.
- Send from a legitimate third-party sender whose envelope domain fails SPF to a real mailbox. If the spoofing rule fires on this, your SPF record is incomplete, not the rule.
- Send through any on-premises mail server that relays to Exchange Online. Check whether the connector stamps the original sender or rewrites it. A relay host that rewrites the envelope to its own domain will trip a spoofing rule that blocks external senders failing SPF.
- Test mailing lists and SaaS senders that use their own envelope domain while the From header shows your domain. These are the classic false positives.
- Send to a shared mailbox with aliases. Aliases resolve as known recipients, so DBEB treats them as valid. Confirm the catch-all does not intercept alias mail before it reaches the shared mailbox.
Compare your options before committing. Each has a different effect on spoofing rules.
| Option | What it does to unknown recipients | Effect on spoofing rules |
|---|---|---|
| Authoritative domain with DBEB | Rejects at the edge | Cleanest: no redirect in the path, spoofing rule sees only real recipients |
| Internal relay plus redirect rule | Relays to one catch-all mailbox | Redirect and spoofing rules compete; rule order and scope must be tested |
| Shared mailbox with aliases | Aliases accepted as known recipients | Preserves an authoritative domain and avoids the relay path entirely |
| Internal relay plus on-premises connector | Relays to the on-premises mail server | Connector may rewrite the envelope; spoofing checks can misread the sender |
Two more checks. Confirm no mail flow rule sits above the spoofing rule that silently drops messages, since a drop gives you no NDR and no trace. And verify the catch-all mailbox owner knows that unknown-recipient mail, including spoofed mail, will land there. The catch-all workaround requires an Exchange administrator role to configure, so assign a named owner for the redirect rule and review its hit count weekly. If the count is near zero, you probably do not need the catch-all, and an authoritative domain with DBEB plus a shared mailbox with aliases is the safer configuration.
Checklist Step 4: Stage the Spoofing Rule and Monitor Before Enforcing
Pilot the rule in a non-destructive mode first
Do not flip the spoofing transport rule to Block on day one. Create the rule with the action set to “Apply a disclaimer” or, better, route matching messages to quarantine or to a review mailbox. In Exchange admin center under Mail flow > Rules, build the condition set you intend to ship (for example, “From outside the organization” plus a header or SPF-based check), then set the action to “Redirect the message to hosted quarantine” or “Generate incident report and send it to” a dedicated address. In PowerShell, that means -RedirectMessageTo review@contoso.com or -Quarantine $true on a New-TransportRule cmdlet, with -Mode Audit if you only want the incident report and no delivery change.
Give the pilot at least seven to ten business days. Spoofed mail arrives in weekly cycles: invoice runs on Monday, payroll notifications mid-month, marketing blasts on Thursdays. A three-day sample tells you nothing about monthly senders. During the pilot, keep the rule priority above any internal relay mail flow rules you already run, but below anti-spam and anti-malware processing, so you see what the spoof rule would catch after the hygiene stack has already done its work.
Review false positives by sender class, not one by one
Sort the quarantine or review mailbox by sender domain and by authentication results. The false positives cluster into predictable groups: mailing lists that rewrite the From header, SaaS platforms sending on behalf of your domain, and internal applications relaying through an Office 365 catch-all email setup. Check the Authentication-Results header on each sample. If SPF returns pass but your rule still matched, the condition logic is wrong, not the SPF record. If SPF returns softfail or none for a sender you know is legitimate, the SPF record is incomplete and the rule is exposing it.
Watch specifically for these, since they account for most of the noise:
- Mailing lists (Mailman, Listserv, Google Groups) that forward with the original From address and break SPF alignment.
- SaaS senders (CRM, ticketing, e-signature) that send as your domain but are not yet in the SPF include list.
- Internal relay traffic where an on-premises mail server hands off to Exchange Online and the envelope sender does not match the header From.
- Messages bound for a shared mailbox alias or catch-all mailbox, where the recipient address differs from the primary SMTP address and the rule fires on the wrong attribute.
- Legitimate third-party senders using a subdomain that has its own SPF record you forgot to inventory.
Switch to block only when the numbers hold
Before enforcing, confirm that over the full pilot window the rule caught zero messages with a passing SPF result, and that every quarantine entry with a failing SPF result was verified as spoofed by the sender. Then change the action to “Reject the message with the explanation” or “Block the message” and re-run the same monitoring for another week at reduced volume. Expect a small tail of stragglers, typically monthly reports and seasonal senders, so keep the incident report action attached to the block rule and route it to a monitored mailbox. If a false positive surfaces after enforcement, add the sender to the SPF record or to an exception list in the rule rather than disabling the rule, and document the change. An Exchange administrator role is enough for all of this, but get the change logged in your ticketing system so the next person knows why the rule exists.
Before you flip the spoofing rule from quarantine to reject, export the rule’s incident report for the last 14 days and sort it by sender domain. Every domain that shows up as a false positive is a gap in your SPF record, not a problem with the rule. Fix the record first: add the missing include, confirm the lookup count stays under 10, wait for the TTL to expire, then re-test with a real message from that sender. Only re-enable the block after the test message passes SPF with a pass result in the message headers. Keep a dated note of each change so the next administrator can see why a given include is in the record.
A few operational details are worth locking down before you walk away. If you run an Exchange Online catch-all or any Office 365 catch-all email arrangement, confirm the destination mailbox is a shared mailbox or a licensed user that still receives mail after the rule is enforced, because a redirect that points at a disabled account fails silently. If your tenant uses an internal relay mail flow rule to forward unknown-recipient mail to an on-premises mail server, test that path with a message addressed to a deliberately bogus local part and confirm it arrives rather than landing in the quarantine queue. Schedule a quarterly review of the rule and the SPF record together, since SaaS vendors rotate sending IPs and marketing platforms add new subdomains without telling anyone. Keep the rule’s priority above your general anti-spam policies so the spoof check runs first, and document the exact recipient address the redirect targets. The short version: prove SPF coverage sender by sender, watch the audit log for a full business cycle, then enforce. That sequence turns a blunt block into a rule you can defend when a legitimate sender complains.