M365 Tenant Deauthentication Breaks Email Authentication

What M365 tenant deauthentication actually means

M365 tenant deauthentication is a security state, not a settings tweak. Microsoft revokes a domain's verified status inside your tenant, which means Microsoft stops treating that domain as legitimately owned by your organization. This usually follows a confirmed hijacking attempt, suspicious sending activity that triggers Microsoft's automated safeguards, or a domain expiration that lets someone else register and claim it.

The consequence is immediate and cascading: Microsoft stops accepting that domain as a valid sender identity inside your tenant. SPF fails. DKIM signing breaks. DMARC alignment collapses. All three, at the same time, from one event.

If this happens, you will see failures in email delivery and authentication reports before you fully understand the cause. The restore window matters. The longer authentication stays broken, the more receivers downgrade or block your mail.

How email authentication works in Microsoft 365

Microsoft 365 uses three interlocking mechanisms to verify that email genuinely comes from your organization.

SPF (Sender Policy Framework) publishes which mail servers are allowed to send for your domain. In M365, the standard SPF record includes the mechanism include:spf.protection.outlook.com, which delegates the actual server list to Microsoft. When your domain is deauthenticated, Microsoft stops accepting that delegation. Your SPF record may still exist in DNS, but the mechanism it points to no longer validates for your tenant.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to message headers. M365 generates and manages DKIM keys automatically when you enable DKIM signing for a domain. The signature proves the message was not modified in transit and that it originated from a server Microsoft considers authorized for your domain. When your domain loses verified status, Microsoft disables DKIM signing for that domain. Outbound messages stop getting signed.

DMARC (Domain-based Message Authentication, Reporting and Conformance) requires at least one of those mechanisms to align with your From address. The domain in the SMTP envelope (SPF) or the domain in the DKIM signature must match the domain shown in the message From header. If neither aligns, DMARC fails. Because tenant deauthentication breaks both SPF alignment and DKIM signing at the same time, DMARC fails too.

What breaks first

The cascade is predictable. The root cause is the domain verification revocation. The symptoms are:

SPF validation fails at receiving mail servers because the Microsoft mechanism no longer accepts your domain.
DKIM signatures disappear from outbound messages because M365 disables signing for unverified domains.
DMARC alignment fails because neither SPF nor DKIM can produce an aligned result.
If you publish an MTA-STS policy, it may also break because the TLS requirements M365 normally satisfies for your domain are no longer valid.

Most organizations discover this through user complaints about undelivered email or through DMARC aggregate reports showing near-total authentication failure rates for their domain.

Step 1: Diagnose the damage before you touch anything

Do not start restoring records blindly. Confirm which systems are actually affected.

Check your M365 admin center under Settings > Domains. If the domain is missing or shows a status other than Verified, you have confirmed the root cause.

Check your public DNS for each authentication record. Your SPF record should still contain include:spf.protection.outlook.com, but it may no longer be functional. Your DKIM selector record at _domainkey.yourdomain.com may have been removed by M365 when signing was disabled. Your DMARC record at _dmarc.yourdomain.com should still be present, but authentication results will show failures.

If all three records exist in DNS but authentication is failing, the problem is inside M365, not in your DNS. The DNS is fine. The tenant-level authentication configuration is what broke.

Step 2: Restore SPF

If the domain is back in M365 as verified, your first job is SPF.

The standard M365 SPF record is:


v=spf1 include:spf.protection.outlook.com ~all

If you have added custom includes for third-party mail services, make sure those includes are still correct. Stale includes from a provider you no longer use will cause PermError lookups, which receivers handle differently than a hard failure.

After republishing, use a public SPF lookup tool to confirm your record parses cleanly. A malformed SPF record silently fails, causing all SPF checks to return PermError.

Step 3: Restore DKIM signing

Re-enable DKIM signing in the Exchange admin center under Mail flow > DKIM, or via PowerShell:

powershell
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true

Microsoft automatically generates new DKIM keys when you re-enable signing. You do not need to manually create or rotate keys for M365-hosted DKIM. The keys are managed by Microsoft.

After enabling, confirm that your DKIM selector records in DNS match what M365 shows. If you use a third-party email gateway that handles DKIM on your behalf, you may need to publish that provider's public key instead of M365's. Check the selector status in the Exchange admin center DKIM page.

Once both SPF and DKIM are restored, DMARC alignment should naturally return if your From domain matches your verified domain.

Step 4: Verify DMARC alignment across all receivers

SPF and DKIM being technically restored is not the same as authentication working at every receiver. Some receivers may have cached the failure state during the outage. Some may have added your domain to internal risk scores that take time to clear.

The only reliable way to confirm restoration is to monitor DMARC aggregate reports. Aggregate reports arrive daily from participating receivers and show the authentication result for every message they received from your domain, grouped by source IP and result type. If you see aligned SPF and DKIM passes returning at the volumes you expect, the recovery is complete.

Checking aggregate reports manually means logging into each provider's portal, finding the report section, and parsing XML files. If you have reports flowing into DMARCFlow, you can see aligned pass rates across all receivers in one view and identify any remaining failure pockets immediately after restoration. This is not a feature argument. It is the practical reality of verifying recovery across a distributed receiver landscape without a centralized monitoring layer.

Step 5: Confirm MTA-STS if you use it

MTA-STS (Mail Transfer Agent Strict Transport Security) enforces TLS encryption for inbound mail delivery. If M365 handles your inbound mail and you use MTA-STS, check your policy at mta-sts.yourdomain.com. The policy should point to o365.monitoring.outlook.com as the MTA-STS host. If M365 deauthenticated your domain, the MTA-STS validation may also have broken. Restore it alongside the other records.

How to prevent silent re-breakage

After recovery, set up a monitoring rule that alerts you before authentication failures reach users. Track your DMARC aligned pass rate weekly. If you see it dropping below 100%, investigate immediately. Authentication cascades often give you a window of hours to days before users start reporting undelivered mail. A monitoring alert on DMARC aggregate report volume and alignment rate catches the problem in that window.

If your domain was deauthenticated due to a hijacking attempt, also check your domain registrar and DNS hosting for any unauthorized changes. The authentication problem is a symptom. If the underlying domain vulnerability is still present, it will happen again.

---

FAQ

What is the fastest way to confirm all three mechanisms are working after recovery?
Check your DMARC aggregate reports. They show aligned pass and fail results for every receiver in one view. If SPF and DKIM are both aligned and passing for the volume you expect, the recovery is complete.

Can SPF or DKIM break without the other?
Yes. SPF can fail independently if you change hosting providers or add a new sending system without updating your SPF record. DKIM can break if you migrate mail gateways or change your email signing configuration. DMARC requires at least one aligned mechanism to pass, so a single-point failure in either SPF or DKIM will break DMARC alignment.

Does DMARCFlow work with MTA-STS configurations?
DMARCFlow monitors DMARC aggregate reports and does not require MTA-STS to function. If you use MTA-STS, make sure your policy is consistent with your actual mail routing before relying on it for delivery assurance.