If Microsoft treats your p=reject DMARC policy like quarantine, the first answer is uncomfortable but important: as a sender, you cannot force every receiver to reject mail at SMTP time. DMARC policy is a request to the receiver. The receiver still owns the final delivery decision.
The practical answer is to separate the problem into two cases. If you control the Microsoft 365 tenant receiving the mail, set the anti-phishing policy so sender DMARC p=reject failures are rejected, not quarantined. If you only own the abused sending domain, your job is to prove the abuse, keep DMARC clean, monitor reports, and give recipient security teams enough evidence to change their local handling.
I do not treat DMARC reject as a complete brand protection control. It is one layer. It works best when DMARC reporting, source ownership, DKIM coverage, SPF limits, and recipient-side enforcement are all managed as an operating workflow.
Why reject can still become quarantine
DMARC tells a receiver what the domain owner wants done when a message fails DMARC. It does not make the receiver accept that decision blindly. Receivers weigh false positives, forwarding, local allow lists, user safe sender lists, gateway routing, spoof intelligence, and their own spam models.
That is why older Microsoft behavior frustrated senders. A brand could publish a correct p=reject record and still see forged messages accepted into quarantine. The user might then see the brand name, display photo, or sender identity inside quarantine. That is not the brand outcome most security teams expect when they publish reject.
A DMARC reject policy reduces abuse, but it does not guarantee invisible abuse. Quarantine still creates a user-facing artifact, and some tenants give users permission to preview or release quarantined mail.
Before escalating, confirm that the message is truly using your RFC5322.From domain. DMARC does not stop every message that mentions your company. A scam can put your brand in the display name, subject, body, or comment portion of the From header while using a different actual domain. That is impersonation, but it is not the same as DMARC domain spoofing.
- Real spoofing: The visible From address uses your domain and fails DMARC.
- Display impersonation: The email shows your brand name, but the actual From domain is different.
- Forwarding breakage: A legitimate message is altered by a forwarder or gateway and then fails DMARC.
- Local override: A tenant allow list, contact list, or transport rule changes the final action.
The current Microsoft behavior
Microsoft changed the default story in 2023. In the Microsoft announcement, Microsoft said consumer services reject messages that fail DMARC when the sender policy is p=reject or p=quarantine. For enterprise customers, Microsoft 365 can honor the sender policy by default when the recipient domain's MX points directly to Office 365.
That does not mean every Microsoft-routed message behaves the same way. Tenant settings matter. A tenant can set separate actions for sender DMARC p=quarantine and p=reject. If a third-party gateway sits in front of Microsoft 365, Enhanced Filtering for Connectors becomes important because Microsoft needs the original sending IP context.
|
|
|
|---|---|---|
 Outlook.com | Reject | Microsoft |
M365 direct MX | Policy based | Anti-phishing |
M365 gateway | Connector based | Enhanced filtering |
Tenant override | Local choice | Admin policy |
Microsoft DMARC handling paths to check.
Microsoft Defender portal anti-phishing policy with DMARC reject set to reject.
What to do when the abused domain is yours
When the abused domain is yours, start with evidence. Do not argue from the DNS record alone. Gather message headers, the Microsoft verdict fields, the visible From address, the return path, DKIM signing domains, SPF result, and the final disposition. The goal is to prove whether this is a DMARC failure that Microsoft accepted into quarantine or a different impersonation path.
Then check your own record. I like a record that requests aggregate reports, has a clear enforcement policy, and avoids unnecessary strictness until legitimate sources are clean. Use a DMARC checker to confirm the syntax before pushing changes.
Example DMARC reject recorddns
Name: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
If your domain has many mail streams, do not jump straight to stricter SPF or DKIM mode as a reflex. First identify every legitimate sender and make sure at least one authentication path passes DMARC with a domain match. A strict-looking record with broken sources creates bounces, junk placement, and noisy escalations.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broader domain health check helps here because DMARC depends on SPF, DKIM, DNS consistency, and visible sending patterns. When abuse is active, I also watch blocklists (blacklists) because brand spoofing incidents often coincide with compromised senders, lookalike domains, or poor list hygiene.
DMARC reject response flow from sample collection to source fixes and abuse escalation.
How to configure Microsoft 365 tenants you control
If you administer the recipient Microsoft 365 tenant, handle the problem inside Microsoft Defender and Exchange Online. The cleanest tenant-side fix is to honor sender DMARC policy and set the action for sender p=reject to reject. Set sender p=quarantine to quarantine unless you have a documented reason to do something else.
Sender-owned domain
- Control limit: You publish DMARC, but the receiver chooses the final action.
- Best evidence: Full headers, DMARC failure proof, and samples from affected recipients.
- Main work: Keep legitimate sources clean and track abuse through reports.
Recipient Microsoft tenant
- Control limit: You can reject DMARC failures for inbound mail to your users.
- Best evidence: Message trace, anti-phishing policy, and connector configuration.
- Main work: Set p=reject failures to reject and review quarantine access.
For direct Microsoft 365 MX, review anti-phishing policy first. For a gateway in front of Microsoft 365, review Enhanced Filtering for Connectors. Without that, Microsoft can see the gateway as the apparent sender and make weaker authentication decisions.
- Policy switch: Turn on honoring sender DMARC policy for explicit authentication failures.
- Reject action: Set sender p=reject failures to reject instead of quarantine.
- Quarantine action: Set sender p=quarantine failures to quarantine or junk based on risk.
- Connector check: Enable enhanced filtering when another gateway sits before Microsoft 365.
- User access: Review whether users can preview or release spoofed messages from quarantine.
Transport rules can help for narrow tenant-owned cases, such as rejecting inbound mail that claims to be from your own domain and fails DMARC. Keep those rules tight. Broad header rules create false positives quickly.
How to reduce brand exposure outside your tenant
When the recipient tenant belongs to someone else, you need a playbook that security teams can act on. Send a short abuse packet with one or two message samples, full headers, your DMARC record, the failed DMARC result, and the exact visible From domain. Ask the recipient admin to reject sender p=reject failures or restrict user release for those messages.
This is also where sender hygiene matters. If your own legitimate sources are messy, recipient teams have less confidence that a hard reject will be safe. If all legitimate streams pass DMARC with a domain match, your escalation is much stronger.
Four-part DMARC abuse packet with headers, result, From domain, and recipient action.
For your own rollout, the safer path is gradual enforcement with real report review. A good safe DMARC transition keeps a record of what changed, who owns each sender, and which receivers are still causing friction.
- Use subdomains: Split marketing, transactional, and corporate mail so one mistake is contained.
- Sign everything: Prefer DKIM for every major stream because SPF often breaks during forwarding.
- Fix web forms: Do not send contact form mail using the visitor's address as the visible From.
- Watch reports: Review aggregate reports after each source, DNS, or policy change.
- Document exceptions: Temporary allow rules need owners, dates, and removal criteria.
Where Suped fits
Suped's product is the best overall DMARC platform for most teams handling this workflow because it turns raw reports into source-level issues, owner-friendly fix steps, and alerts. That matters when Microsoft behavior is not the only problem. Most DMARC incidents include a mix of unknown senders, broken DKIM, SPF lookup risk, forwarding, and confusing receiver results.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The useful workflow is simple: monitor every domain, verify each source, fix DMARC failures before enforcement changes, and keep real-time alerts on for sudden spikes. Suped brings DMARC monitoring, SPF, DKIM, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and MSP multi-tenancy into one place.
Hosted policy management is useful when teams want to stage changes without repeated DNS edits. Hosted DMARC also makes it easier to keep policy changes controlled when multiple teams own different senders.
The goal is not to publish reject and walk away. The goal is to know which mail is legitimate, prove which mail is abuse, and give receivers a clean reason to reject failures instead of showing them to users in quarantine.
Views from the trenches
Best practices
Verify real From-domain spoofing before escalating, because display names need a different fix.
Keep DMARC reports active so reject changes have evidence, source history, and owner names.
Ask Microsoft tenants you control to reject p=reject failures in anti-phishing policy.
Common pitfalls
Publishing reject without fixing sender domain match turns legitimate mail into the incident.
Treating quarantine as harmless leaves brand abuse visible to users who review released mail.
Assuming bounces explain everything hides silent junking, quarantine, and connector effects.
Expert tips
Save full headers and verdict fields before opening cases with recipient security teams quickly.
Separate marketing, transactional, and corporate mail so policy changes have less blast radius.
Use strict DKIM coverage for important streams when SPF forwarding breaks domain matching.
Marketer from Email Geeks says DMARC policy is a request, and receivers still choose the final disposition based on local risk controls.
2021-01-21 - Email Geeks
Expert from Email Geeks says the first check is whether the domain is truly forged or the brand only appears in the display name.
2021-01-21 - Email Geeks
The practical answer
Handle Microsoft treating DMARC reject as quarantine by fixing what you control first. If you control the Microsoft 365 tenant, set the anti-phishing policy so sender p=reject failures are rejected, and check connectors if mail routes through a gateway. If you own the abused domain but not the recipient tenant, gather headers, prove the DMARC failure, keep your legitimate sources clean, and escalate with a clear request.
Do not reduce this to a single DNS tag. DMARC reject helps most when reporting is active, authentication is clean, user-facing quarantine is controlled, and abuse response is documented. That is the difference between having a policy and operating one.
