DomainSecurityScanner
Microsoft Advisory: January 2026

Office 365 Tenant Spoofing Vulnerability Checker

Microsoft's January 2026 advisory revealed that attackers are exploiting misconfigured email routing and weak DMARC policies to send spoofed emails that appear internal to O365 tenants. Check if your domain is at risk. Free, instant, no signup.

DNS-based check that tests MX routing, DMARC policy, SPF mechanism & alignment in seconds.

What We Check

📡

MX Routing Analysis

Critical

Do your MX records point to Office 365 (*.mail.protection.outlook.com)? If not, there's a mail routing gap attackers can exploit to send emails that appear internal.

🛡️

DMARC Policy Enforcement

Critical

Is your DMARC policy set to p=none (monitoring only)? This is the #1 weakness exploited by Tycoon2FA, and spoofed emails pass right through to inboxes.

✉️

SPF All-Mechanism

High

Does your SPF record use ~all (soft fail) or -all (hard fail)? Soft fail means unauthorised emails are flagged but still delivered. Attackers love this.

🔗

DMARC Alignment

High

Are your SPF and DKIM alignment settings strict or relaxed? Relaxed alignment allows subdomain spoofing, giving attackers more attack surface.

How the Attack Works

The O365 tenant spoofing attack exploits a gap between how email is routed and how it's authenticated. Here's the kill chain:

1

Attacker identifies target domain

Attacker scans for domains with DMARC p=none and SPF ~all, which are easily discoverable via public DNS records.

2

Spoofed email sent via external server

Using Tycoon2FA or similar tools, the attacker sends an email from an external SMTP server with the From: address set to an internal user (e.g., [email protected]).

3

Email passes weak authentication

SPF ~all soft fails but doesn't reject. DMARC p=none logs the failure but delivers the email anyway. The spoofed message lands in the target's inbox.

4

Victim sees "internal" email

The email appears to be from a colleague or executive. Outlook displays it as internal with no external sender warnings. The victim clicks the phishing link, entering credentials into a Tycoon2FA capture page that also intercepts MFA tokens.

⚠️

Why This Attack Is So Effective

Unlike traditional phishing, these emails appear to come from inside your own organisation. Outlook doesn't show external sender warnings. The emails pass spam filters because the domain is your own. Combined with Tycoon2FA's ability to intercept MFA tokens, this represents a complete bypass of standard email security and authentication controls.

Who's at Risk

🔴

High Risk

  • → Organisations with DMARC p=none and no plans to enforce
  • → Domains using SPF ~all (soft fail) or ?all (neutral)
  • → Companies using third-party email gateways with MX not pointing to O365
  • → Organisations that haven't reviewed DNS records since migrating to O365
  • → Tenants without conditional access policies or advanced threat protection
🟢

Better Protected

  • → Domains with DMARC p=reject and strict alignment (aspf=s, adkim=s)
  • → SPF configured with -all (hard fail)
  • → MX records correctly pointing to *.mail.protection.outlook.com
  • → DMARC aggregate reporting enabled and actively monitored
  • → Microsoft Defender for O365 with anti-phishing policies enabled

How to Fix It

Follow these steps to protect your domain from the O365 tenant spoofing attack. Each step includes the exact DNS records to add or update.

1

Enforce DMARC Policy

If you're at p=none, progressively move to p=reject. This is the single most impactful change you can make.

# Start with quarantine (Week 1-2)

_dmarc.yourdomain.com TXT

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

# Then enforce reject (Week 3-4+)

_dmarc.yourdomain.com TXT

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

2

Switch SPF to Hard Fail

Change ~all (soft fail) to -all (hard fail) to reject emails from unauthorised servers.

# For Office 365 only

yourdomain.com TXT

"v=spf1 include:spf.protection.outlook.com -all"

# For O365 + other senders (adjust includes)

yourdomain.com TXT

"v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

3

Verify MX Routing

Ensure your MX records point to the correct destination. For direct O365 routing:

# Standard Office 365 MX record

yourdomain.com MX 0

yourdomain-com.mail.protection.outlook.com

# If using a third-party gateway (Mimecast, Proofpoint, etc.)

# Ensure your gateway enforces DMARC and has anti-spoofing rules

4

Enable Additional O365 Protections

  • ✓ Enable Microsoft Defender for Office 365 anti-phishing policies
  • ✓ Configure Impersonation Protection for executives and key users
  • ✓ Enable External Sender Tagging to flag emails from outside your tenant
  • ✓ Set up Conditional Access Policies requiring compliant devices for email access
  • ✓ Enable Safe Links and Safe Attachments in Defender
  • ✓ Review and monitor DMARC aggregate reports weekly

Frequently Asked Questions

What is the Microsoft O365 tenant spoofing vulnerability?▼
The O365 tenant spoofing vulnerability is a security flaw where attackers exploit misconfigured email routing and weak DMARC policies to send emails that appear to come from within an organisation's own Office 365 tenant. Because the emails appear internal, they bypass many security filters and are highly convincing to recipients. Microsoft published a security advisory about this attack vector on January 6, 2026, identifying it as a major threat to enterprise email security.
How do attackers exploit misconfigured email routing?▼
When an organisation's MX records don't point to Office 365 (e.g., they use a third-party email gateway or have stale DNS records), a mail routing gap is created. Attackers send spoofed emails through external servers that mimic the organisation's domain. Because the domain's DMARC policy is typically set to p=none (monitoring only) and SPF uses ~all (soft fail), the spoofed emails pass basic authentication checks and are delivered to Office 365 inboxes as if they were sent internally.
What is the Tycoon2FA phishing platform?▼
Tycoon2FA is a Phishing-as-a-Service (PhaaS) platform that has become the primary driver behind O365 tenant spoofing attacks. It provides attackers with turnkey tools to create convincing phishing pages that can bypass multi-factor authentication (MFA). The platform specifically targets Microsoft 365 tenants by exploiting misconfigured email authentication, allowing attackers to send phishing emails that appear to come from inside the target organisation.
Why is DMARC p=none dangerous for Office 365?▼
DMARC p=none is a monitoring-only policy that tells receiving mail servers to deliver all emails regardless of authentication failures, and just send reports. While intended as a first step in DMARC deployment, many organisations never progress beyond p=none. For Office 365 tenants, this means spoofed emails that fail SPF and DKIM checks are still delivered to user inboxes. Attackers specifically target domains with p=none because they know their spoofed emails will land in inboxes without being quarantined or rejected.
How do I check if my domain is vulnerable?▼
Use our free O365 Tenant Spoofing Vulnerability Checker above. Enter your domain and we'll instantly check four critical areas: (1) whether your MX records point to Office 365, (2) your DMARC policy enforcement level, (3) your SPF all-mechanism setting, and (4) your DMARC alignment configuration. You'll get a clear verdict of VULNERABLE, AT RISK, or PROTECTED along with specific fix steps including copy-paste DNS records.
What MX records should I have for Office 365?▼
For Office 365, your MX records should point to *.mail.protection.outlook.com (e.g., contoso-com.mail.protection.outlook.com). The exact hostname depends on your tenant. If you use a third-party email security gateway (like Mimecast, Proofpoint, or Barracuda), your MX records will point to that gateway instead. In that case, ensure the gateway is properly configured to enforce DMARC and that your DMARC policy is at p=quarantine or p=reject.
Should I use SPF hard fail or soft fail?▼
You should use SPF hard fail (-all) whenever possible. Soft fail (~all) was designed as a transitional mechanism during SPF deployment, but many organisations never switch to hard fail. With ~all, emails from unauthorised servers are flagged but still delivered, giving attackers a clear path to spoofing. Hard fail (-all) tells receiving servers to reject emails from servers not listed in your SPF record. The only exception is during initial SPF setup where you may temporarily use ~all while confirming all legitimate sending sources are included.
How do I move from DMARC p=none to p=reject?▼
Moving from p=none to p=reject should be done in stages: (1) Start with p=none and add rua= to receive aggregate reports. Monitor for 2-4 weeks to identify all legitimate email sources. (2) Move to p=quarantine with pct=25 to quarantine 25% of failing emails, then increase to pct=50, then pct=100. (3) Monitor reports for any legitimate emails being quarantined and fix their SPF/DKIM. (4) Finally, upgrade to p=reject with pct=100 and add strict alignment (aspf=s; adkim=s). The entire process typically takes 4-8 weeks for small organisations and 2-3 months for large enterprises.

Check your domain now

Enter your domain above to see if you're vulnerable to the O365 tenant spoofing attack. Free, instant, no signup required. For a comprehensive security audit, run a full domain scan.

Or run a full domain security scan