Microsoft Warns: Attackers Are Spoofing Domains From Inside Office 365 Tenants (And How to Check If You're Vulnerable)

1. The Hook: Microsoft's January 2026 Bombshell

On January 6, 2026, Microsoft published a security advisory that sent shockwaves through the email security community. The advisory, posted to the Microsoft Defender for Office 365 blog, described a class of attacks that most organisations had assumed was impossible: attackers sending phishing emails that appear to originate from inside an organisation's own Office 365 tenant.

Not from a lookalike domain. Not from a compromised account. From inside the tenant, exploiting how Microsoft 365 routes email when certain DNS configurations are in place. The emails pass basic authentication checks, land in inboxes without warning banners, and look indistinguishable from legitimate internal messages.

The attack is devastatingly effective because it exploits a combination of three things most organisations consider “good enough”: a DMARC record set to p=none, an SPF record with a soft fail (~all), and MX records that don't point directly to Microsoft 365. Together, they create a gap that attackers are actively exploiting at scale.

If your organisation uses Office 365 in any capacity, even partially, you need to understand this vulnerability and check your exposure today.

2. What's Actually Happening

The core of this vulnerability lies in how Microsoft 365 handles inbound email routing. When an organisation's MX records don't point to Office 365 (because they use a third-party email gateway, on-premise Exchange, or a hybrid deployment), Microsoft's mail flow architecture creates an opening that attackers can exploit.

Here's what makes this so dangerous: when an attacker sends an email through a compromised or rogue Office 365 tenant, the email originates from Microsoft's own infrastructure. This means:

• The sending IP belongs to Microsoft: it's on SPF include lists for millions of domains
• The email passes SPF checks if the target domain includes spf.protection.outlook.com in their SPF record (which nearly all O365 customers do)
• The email appears internal: Exchange Online treats it as coming from within the Microsoft ecosystem
• No external email warning banners are triggered in many configurations
• DMARC p=none does nothing: the receiving server notes the authentication result but takes no action

The result is a phishing email that looks, feels, and routes like a legitimate internal message. Recipients have no visual cues that anything is wrong. The email sits in their inbox alongside real messages from colleagues, and the sender address shows a real person within their organisation.

3. The Attack Chain (Step by Step)

Understanding the full attack chain helps explain why this is so difficult to detect and so easy to exploit. Here's how it works:

Step 1: The Attacker Sets Up a Rogue Tenant

The attacker creates or compromises an Office 365 tenant. This is trivially easy: Microsoft offers free trial tenants, and compromised tenants are available on dark web marketplaces. The attacker doesn't need access to your tenant. They just need any Office 365 tenant.

Step 2: The Attacker Crafts the Spoofed Email

From their rogue tenant, the attacker sends an email with a forged From: header matching your domain — for example, [email protected]. The email is crafted to look like a legitimate internal communication: a password reset request, an invoice approval, a shared document notification.

Step 3: The Email Routes Through Microsoft's Infrastructure

Because the email originates from an Office 365 tenant, it's sent through Microsoft's mail servers. The sending IP address is a legitimate Microsoft IP, which is included in most organisations' SPF records viainclude:spf.protection.outlook.com.

Step 4: SPF Soft Fail Is Ignored

If the target domain's SPF record uses ~all (soft fail), which is the default recommendation from many providers, the SPF check returns a “soft fail” result. This is recorded but not acted upon. The email is not rejected.

Step 5: DMARC p=none Takes No Action

The receiving server evaluates DMARC. Even if alignment fails (the From: domain doesn't match the authenticated domain), the DMARC policy is p=none. The server notes the failure in aggregate reports but delivers the email to the inbox.

Step 6: The Email Lands in the Inbox

Because the email came from Microsoft's infrastructure, passed (or soft-failed) SPF, and DMARC took no action, the email is delivered. In many configurations, it doesn't even trigger an “external sender” warning because the MX records point to a third-party gateway that may not add these headers.

The victim sees an email from their CEO, CFO, or IT department. They click.

4. Who's Vulnerable

Not every Office 365 customer is equally exposed. The vulnerability requires a specific combination of misconfigurations. You're most at risk if you fall into any of these categories:

MX Records Not Pointing to Office 365

This is the primary risk factor. If your MX records point to a third-party email security gateway (Mimecast, Proofpoint, Barracuda, etc.) or to on-premise Exchange servers rather than to*.mail.protection.outlook.com, your mail flow creates the routing gap that attackers exploit.

This is paradoxically common among security-conscious organisations. They deploy advanced email gateways for additional filtering, but the gateway architecture introduces this vulnerability if DMARC isn't enforced at p=reject.

Hybrid Exchange Deployments

Organisations running a hybrid Exchange deployment, with some mailboxes on-premise and some in Exchange Online, are particularly vulnerable. The hybrid mail flow configuration often involves complex connector setups that can inadvertently create routing paths attackers can exploit.

Third-Party Email Gateways Without Proper Connector Configuration

If you use a third-party email gateway with Office 365, inbound connectors must be properly configured to restrict which IPs can submit mail to your tenant. Misconfigured connectors can allow attackers to route email through your gateway and into your tenant without proper authentication checks.

DMARC at p=none with SPF ~all

This is the universal condition. Regardless of your MX configuration, if your DMARC policy is p=noneand your SPF record ends with ~all, you're telling receiving servers: “If someone spoofs my domain, note it in a report, but deliver the email anyway.” Attackers are listening.

5. The Tycoon2FA Connection

This vulnerability isn't being exploited by lone actors sending one-off phishing emails. It's being weaponised by sophisticated Phishing-as-a-Service (PhaaS) platforms, most notably Tycoon2FA.

Tycoon2FA is a phishing kit that has been tracked by security researchers since late 2024. What makes it particularly dangerous is its ability to bypass multi-factor authentication (MFA) by acting as a real-time proxy between the victim and Microsoft's legitimate login page.

Here's how Tycoon2FA combines with the O365 routing vulnerability:

• Step 1: The platform sends phishing emails through rogue O365 tenants, exploiting the internal routing vulnerability described above
• Step 2: The email contains a link to a phishing page that looks identical to the Microsoft login page
• Step 3: When the victim enters their credentials and MFA code, Tycoon2FA captures them in real-time and immediately uses them to authenticate to the real Microsoft 365 environment
• Step 4: The attacker gains full access to the victim's mailbox, SharePoint, OneDrive, and Teams

The scale is staggering. Security researchers have identified thousands of Tycoon2FA campaignsrunning simultaneously, each targeting hundreds of organisations. The platform is available as a subscription service, and anyone with a few hundred dollars can run enterprise-grade phishing campaigns.

The combination of internal-looking spoofed emails and MFA bypass creates a near-perfect attack chain. The victim sees an email from a trusted colleague, clicks a link that looks legitimate, enters their credentials on what appears to be the real Microsoft login page, and the attacker is in.

6. Why DMARC p=none Is Not Protection

Let's be absolutely clear about this, because it's the single most important takeaway from Microsoft's advisory: DMARC p=none does not protect your domain from spoofing.

Microsoft's own documentation states it plainly:

“A DMARC policy of p=none does not protect against spoofed messages. It only monitors and reports on authentication failures without taking any action to prevent delivery.”

Yet organisations continue to treat p=none as a security control. It isn't. Here's what each policy level actually does:

• p=none: “Monitor mode.” Send me reports, but deliver everything. No protection.
• p=quarantine: “Send failures to spam/junk.” Users may still find and open them, but they're flagged. Partial protection.
• p=reject: “Block failures entirely.” Spoofed emails never reach the recipient. Full protection.

Many organisations deployed p=none with the intention of moving to enforcement “soon.” That was two, three, sometimes five years ago. The policy is still at p=none. Meanwhile, attackers have built automated toolkits specifically designed to exploit this gap.

The purpose of p=none is to be a temporary stepping stone. You deploy it to start receiving aggregate reports, identify all your legitimate sending sources, fix authentication issues, and then move to enforcement. It was never meant to be a permanent state, but for half of all domains with DMARC, that's exactly what it's become.

7. The Numbers: A Shocking Enforcement Gap

How widespread is this problem? The numbers from PowerDMARC's January 2026 Global DMARC Adoption Report paint a sobering picture:

Let that sink in. Nearly half of all domains with DMARC are running at p=none, offering zero spoofing protection despite having a DMARC record in place. That's millions of domains worldwide that have done the work to publish a DMARC record but stopped short of the step that actually matters.

The report also found:

• 46% of domains with DMARC are still at p=none
• Only 33.4% have reached p=reject, the gold standard
• 15.6% are at p=quarantine. Better, but emails may still be opened from spam folders
• Healthcare and education sectors have the lowest enforcement rates, despite being prime phishing targets

For Office 365 customers specifically, the numbers are even more concerning. Many organisations adopted DMARC specifically to meet Microsoft's bulk sender requirements (announced in 2025), which only require p=none. They checked the compliance box and moved on, unaware they were leaving their domain wide open to the very attack Microsoft later warned about.

8. How to Check Your Domain

Before you can fix the vulnerability, you need to know exactly where you stand. Here's a step-by-step guide to checking your domain's exposure:

Option 1: Use Our Free O365 Vulnerability Checker (Recommended)

We built a tool specifically to check for this vulnerability. It analyses your MX records, SPF policy, and DMARC enforcement level and tells you instantly whether you're exposed.

1. Go to domainsecurityscanner.com/tools/o365-vulnerability-checker
2. Enter your domain name
3. Review your results: the tool checks all three vulnerability conditions (MX configuration, SPF policy, DMARC enforcement)
4. Follow the fix recommendations if any issues are found

Option 2: Manual DNS Check

If you prefer to check manually, here's what to look for:

Check your DMARC policy:

dig TXT _dmarc.yourdomain.com

Look for the p= tag. If it says p=none, you're not enforcing DMARC.

Check your SPF record:

dig TXT yourdomain.com

Look for the v=spf1 record. If it ends with ~all (soft fail), spoofed emails will pass. If it ends with -all (hard fail), they'll fail SPF.

Check your MX records:

dig MX yourdomain.com

If your MX records don't include *.mail.protection.outlook.com, your email isn't routing directly through Office 365, which means you may be exposed to the internal routing vulnerability.

9. Fix Step 1: Move DMARC to Enforcement

This is the most impactful change you can make. Moving from p=none to an enforcement policy closes the primary gap that attackers exploit. Here's the recommended progression:

Phase 1: Audit (Week 1-2)

Before changing anything, ensure you're receiving and reviewing DMARC aggregate reports. Your currentp=none record should have a rua= tag:

v=DMARC1; p=none; rua=mailto:[email protected];

Review the reports to identify all legitimate services sending email on your behalf. Look for any that fail SPF or DKIM alignment. These need to be fixed before you enforce.

Phase 2: Quarantine at 10% (Week 3-4)

Start enforcement gradually using the pct= tag:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected];

This sends 10% of failing emails to spam while allowing 90% through. Monitor for any legitimate emails being quarantined and fix authentication issues.

Phase 3: Quarantine at 100% (Week 5-6)

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];

Ramp up to full quarantine enforcement. All failing emails now go to spam. Continue monitoring.

Phase 4: Reject (Week 7-8)

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s;

The finish line. All failing emails are now rejected entirely; they never reach the recipient. The adkim=s and aspf=s flags enforce strict alignment for maximum protection.

10. Fix Step 2: Harden SPF

Your SPF record is the second critical piece. Here's how to harden it:

Change ~all to -all

The difference between ~all (soft fail) and -all (hard fail) is the difference between “maybe reject spoofed email” and “definitely reject spoofed email.”

# Before (weak):
v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

# After (strong):
v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Audit Your Includes

Over time, SPF records accumulate include: entries for services you no longer use. Each include adds to your DNS lookup count (max 10), and unused includes expand the set of IPs authorised to send as your domain.

• Remove includes for services you no longer use
• Verify each include is still necessary by cross-referencing with your email service providers
• Consider SPF flattening if you're approaching the 10-lookup limit
• Never include broad ranges like include:_spf.google.com unless you actually use Google Workspace

Verify Your SPF Record

Use our domain security scanner to check your SPF record for issues, including lookup count, syntax errors, and overly permissive includes.

11. Fix Step 3: Verify MX Configuration

If Microsoft 365 is your primary email platform, your MX records should point to Office 365:

yourdomain.com.  MX  0  yourdomain-com.mail.protection.outlook.com.

Having MX records point directly to Office 365 allows Microsoft Defender to apply its full suite of anti-spoofing protections, including:

• Inbound DMARC enforcement: Microsoft honours your DMARC policy on inbound mail
• Composite authentication: additional signals beyond SPF/DKIM/DMARC
• External sender identification: “External” tags on messages from outside your org
• Spoof intelligence: AI-based detection of spoofing attempts

If You Use a Third-Party Gateway

If you intentionally route email through a third-party gateway (Mimecast, Proofpoint, etc.), ensure:

• The gateway enforces DMARC on your behalf (check with your vendor)
• Enhanced Filtering for Connectors is configured in Exchange Online to preserve the original sender IP
• Your DMARC policy is at p=reject (this is even more critical with third-party gateways)
• External sender warnings are enabled in Outlook/Exchange

12. Fix Step 4: Review Mail Flow Connectors

Mail flow connectors in Exchange Online control how email enters and leaves your tenant. Misconfigured connectors are a common enabler for spoofing attacks.

Check Inbound Connectors

In the Exchange Admin Centre (admin.exchange.microsoft.com), review your inbound connectors:

• Restrict by IP: Inbound connectors from partner organisations should be restricted to specific IP addresses or certificate thumbprints
• Remove unused connectors: Old connectors from decommissioned services can create backdoors
• Verify connector scope: Ensure connectors don't accept mail from any IP for your domain

Enable Enhanced Filtering

If you use a third-party gateway, enable Enhanced Filtering for Connectors (also called “skip listing”) in Microsoft Defender for Office 365. This preserves the true source IP of incoming email, allowing Microsoft's anti-spoofing protections to work correctly even when email routes through a gateway.

Review Outbound Connectors

While outbound connectors are less relevant to this specific vulnerability, misconfigured outbound routing can cause legitimate emails to fail authentication at the receiving end, leading you to keep DMARC atp=none longer than necessary.

13. The Full Security Checklist

Here's a comprehensive checklist with the exact DNS records you need at each stage of remediation:

# SPF (soft fail - does not block spoofing):
v=spf1 include:spf.protection.outlook.com ~all

# DMARC (monitoring only - does not block spoofing):
v=DMARC1; p=none; rua=mailto:[email protected];

# SPF (hard fail - rejects unauthorised senders):
v=spf1 include:spf.protection.outlook.com -all

# DMARC (quarantine - sends failures to spam):
v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];

# SPF (hard fail with audited includes):
v=spf1 include:spf.protection.outlook.com -all

# DMARC (reject with strict alignment):
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected];

# MX (pointing to O365):
yourdomain.com.  MX  0  yourdomain-com.mail.protection.outlook.com.

Want to verify all of this automatically? Run your domain through our O365 Vulnerability Checker and our full domain security scanner to get a complete picture.

14. Frequently Asked Questions