How to Validate Email Auth After M365 Compromise

After a tenant-wide Microsoft 365 sign-out or a suspected compromise, most admins focus on user accounts and SharePoint access. Email authentication is often overlooked until someone reports that legitimate mail is suddenly bouncing or landing in spam.

This happens more often than it should. When an M365 tenant loses its authentication context, SPF, DKIM, and DMARC can all be affected without any obvious warning in the admin portal.

What Can Break in Email Authentication During an M365 Incident

Three things typically break when a tenant gets deauthenticated or compromised:

DKIM signing stops -- M365 uses tenant-level keys stored in Azure AD to sign outbound mail with DKIM. When a tenant-wide sign-out occurs, those keys can be invalidated or rotated without the admin's knowledge. The result is DKIM failures on mail that was previously passing.

SPF include chains get stale -- If you use third-party email vendors (CRM systems, marketing platforms, support tools) and those vendors rotate their sending infrastructure, your SPF record may suddenly reference an outdated IP range. This is not an M365 problem directly, but it becomes visible after an incident when you are already investigating.

Conditional Access policies can block service account authentication -- If you route outbound mail through a connector or hybrid relay that uses a service account, and a Conditional Access policy change cuts off that account's access during incident response, SPF fails for that relay even though user sign-in is unaffected.

The order of checks matters: SPF first, then DKIM, then DMARC aggregate review.

How to Check Your SPF Record After an M365 Incident

Open a browser and go to any public SPF checker. The easiest is to search for "SPF checker" or use a DNS lookup tool like MXToolbox.

Enter your domain and look for:

A resolved SPF record (not NXDOMAIN or SERVFAIL)
A single "v=spf1" mechanism at the start
No duplicate "include:" mechanisms pointing at the same domain
No "exists:" or complex mechanisms that could cause a permerror

Common permerror causes after an incident

Duplicate mechanisms from hastily added vendor records are the most common cause. If you added a new email vendor during the incident response and the include was already present under a different name, you now have two includes that may resolve to overlapping IP ranges. That causes a soft-fail on every message.

An outdated include pointing at a vendor who has changed their sending infrastructure is the second most common cause. If your vendor rotated IPs or moved to a new infrastructure and did not notify you, your SPF record still points at their old range.

If you use M365 exclusively

Your SPF record should include include:spf.protection.outlook.com. If you also send from Google Workspace, Salesforce, Mailchimp, or any other vendor, each should have its own include. Running more than 10 includes is a sign you are approaching the SPF lookup limit, which causes permerror at receivers and breaks mail delivery entirely.

How to Verify DKIM Signing Is Still Working

DKIM is the most likely to silently break after a tenant deauthentication. Here is how to check it.

Step 1: Check that your DKIM selector records still exist in DNS

Open a terminal and run:


dig selector1._domainkey.yourdomain.com TXT

Replace "selector1" with your actual selector name. Common selector names in M365 are "selector1" and "selector2". You can find the exact selector names in the M365 admin center under Mail flow > DKIM.

If the DNS query returns a TXT record with "v=DKIM1", the record is still present. If it returns NXDOMAIN, the record has been removed from DNS and you need to re-enable DKIM signing.

Step 2: Check that DKIM signing is enabled in M365

In the M365 admin center, go to Mail flow > DKIM. For each domain, confirm the signing status shows "Enabled". If it shows "Disabled", M365 is not signing outbound mail for that domain. Re-enable it and wait 24-48 hours for the change to propagate.

Step 3: Test DKIM signature validity

Use a tool like DKIMValidator.com or Mail-tester.com. Send a test email from an M365 mailbox in your domain to the test address and check the DKIM result. A passing result means the signature is valid and the receiving server will authenticate it.

If DKIM was disabled during the incident, re-enabling it takes time to propagate. During that window, some receivers may show DKIM failures on your mail even though you have already fixed the root cause. Do not assume the problem is still broken just because a test shows a failure within 48 hours of re-enabling.

How to Confirm DMARC Alignment Is Not Affected

DMARC checks alignment, meaning it verifies that the domain in the SPF From header and the domain in the DKIM signature both match the domain shown to recipients. A deauthentication incident can break alignment in subtle ways.

Step 1: Check your DMARC record

Run a DNS lookup on _dmarc.yourdomain.com. You should get a TXT record starting with v=DMARC1. If the record is missing, DMARC is not being evaluated at all.

Step 2: Check aggregate report delivery

This is where monitoring tools earn their value. If reports have stopped arriving, either your rua email address is no longer valid or the sending domain's mail flow has changed. Most receivers send aggregate reports daily, so a gap of more than a few days is worth investigating.

If you do not have a DMARC reporting tool set up, this is the moment to add one. Without aggregate reports, you cannot see what receivers see. You are guessing based on whether users complain or delivery rates drop.

This is exactly what DMARCFlow was built for. Rather than parsing raw report files yourself, DMARCFlow ingests aggregate reports across all your domains and shows authentication health in one view. After a tenant incident, that single view tells you which domains are failing, which authentication mechanism broke, and whether the failure started on the date of your incident. That timestamp comparison is the fastest way to confirm whether an incident caused your authentication problem.

Step 3: Look for alignment failures in your reports

In the aggregate report, find the "fail" rows. A spike in DKIM alignment failures after the incident date is a strong signal that DKIM signing broke. A spike in SPF alignment failures suggests either relay changes or a mismatch between the envelope-from domain and the header-from domain.

The Email Authentication Recovery Checklist

Work through this list in order after any M365 tenant incident:

1. Check SPF record resolves and has no permerrors
2. Verify all vendor includes are still valid
3. Confirm DKIM selector records exist in DNS
4. Enable DKIM signing in M365 admin center if it is disabled

5. Wait 24-48 hours for DKIM propagation
6. Run a DKIM validation test with a tool like DKIMValidator.com
7. Verify your DMARC record is still published
8. Confirm DMARC aggregate reports are still arriving

9. Look for any spike in alignment failures in the most recent reports
10. Send a test email to an external address and check the authentication results in the email header

If steps 3-5 are skipped, you may have no idea that DKIM is not signing until a receiver reports the problem or your delivery rates drop.

---