Why Phishing Emails Land in Microsoft 365 Inboxes Despite SPF, DKIM, and DMARC All Passing

The short answer

Phishing emails land in Microsoft 365 inboxes because SPF, DKIM, and DMARC verify who sent the email, not what the email says. An attacker who controls a domain with valid authentication can send convincing phishing that passes all three checks. Microsoft 365 receives the message, sees it authenticated correctly, and delivers it.

That is the authentication gap. DMARC aggregate reports are the tool that surfaces it, because they show every source sending mail on behalf of your domain, including sources you did not authorize.

What SPF, DKIM, and DMARC actually check

Think of email authentication like checking someone's ID at a building entrance. The guard verifies the ID is real and belongs to the person presenting it. That does not tell you whether the person is there to do something harmful.

• SPF checks that the sending mail server is authorized to send for the claimed domain. It does not check the email content.
• DKIM adds a cryptographic signature proving the email was not modified in transit. It does not verify the sender's intentions.
• DMARC ties SPF and DKIM results to the From header domain, ensuring the sending organization actually owns the domain used in the email's From field.

All three protocols deal with sender identity. None of them evaluate links, attachments, language, or anything a human would actually read in the message.

Why phishing passes all three checks

When all authentication checks pass, Microsoft 365 treats the message as legitimate from a domain-ownership standpoint. The reason phishing still gets through usually falls into one of these patterns.

Compromised accounts and legitimate senders

An attacker who has taken over a real email account, or a legitimate marketing platform configured for a real domain, sends email that passes every authentication check. The domain is real, the SPF record covers the sending IP, the DKIM signature is valid. The email arrives with full authentication credentials because it came from exactly that infrastructure.

Brand impersonation with valid authentication

Attackers register domains that are visually similar to legitimate brands and configure them with proper SPF, DKIM, and DMARC records. A domain like microsft-support.com or paypa1.com can pass authentication if the attacker has set it up correctly. Microsoft 365 anti-phishing has separate detection logic for lookalike domains, but that logic is not part of the authentication layer.

Third-party senders with good authentication

Organizations often use third-party email services for marketing, transactional email, or CRM integrations. These services typically have proper authentication configured. If one of those services is compromised or abused, the phishing passes DMARC because the authentication is genuinely valid.

Internal spoofing within a tenant

Microsoft 365 intra-org email does not go through external DMARC filtering. If an attacker compromises an account inside a tenant, they can send phishing to other users that appears to come from colleagues, executives, or trusted partners, entirely bypassing external authentication checks.

Why Microsoft 365 anti-phishing does not catch these

Microsoft 365 has its own anti-phishing engine that runs separately from the authentication layer. That engine analyzes message content, sender behavior, link reputation, and other signals. But when an email passes authentication, the anti-phishing engine has to work harder to flag it, and false positives are costly for a platform handling millions of legitimate messages.

The gap is not a bug. It is a consequence of authentication and content analysis being separate systems. The authentication layer says "this domain owns this message." The content layer then has to decide whether to act on it. That decision can be fooled by sophisticated messages, credential-harvesting pages, and precise impersonation.

How to detect phishing that passes authentication

DMARC aggregate reports are the most direct way to see who is sending email on behalf of your domain. They show every source that sent mail claiming to be from your domain, whether it passed or failed authentication, and in what volume. Unlike content-based filters, aggregate reports tell you about authentication patterns before any individual message triggers a block.

When you see authentication passes from sources you do not recognize, that is a signal worth investigating. It could be a third-party sender you forgot to document, a legitimate integration that changed IPs, or an attacker using your domain with proper authentication configured.

A few specific patterns to watch for in aggregate reports:

• High-volume authentication passes from a source you have not authorized
• Authentication passes from domains that look visually similar to yours
• Sudden spikes in sent volume from a particular source you do not regularly monitor
• Authentication passes for subdomains you do not use for sending email

If your domain uses a p=quarantine or p=reject policy and you are still seeing passes from unknown sources, those passes warrant immediate investigation. With DMARCFlow you can monitor aggregate reports on a schedule and alert on these patterns as they emerge, rather than discovering them after phishing has been sent.

Additional layers beyond authentication

Authentication passing is one signal. A complete anti-phishing posture layers additional controls:

• Link analysis scans URLs at delivery time and blocks known malicious infrastructure
• Attachment sandboxing opens attachments in isolated environments to observe behavior
• Behavioral analysis flags messages that deviate from a sender's normal patterns
• User training remains the last line of defense for messages that slip through

No single layer catches everything. The authentication layer establishes trust in sender identity. The content layer evaluates what the sender is actually trying to do.

FAQ

Does passing SPF, DKIM, and DMARC mean an email is safe?

No. These protocols verify sender identity, not message content or intent. A phishing email can pass all three if it was sent from infrastructure that legitimately owns the claimed domain.

Can phishing bypass Microsoft 365 even with perfect SPF/DKIM/DMARC?

Yes. Microsoft 365 anti-phishing is separate from the authentication layer. If an attacker uses legitimately authenticated infrastructure, the message may reach the inbox without triggering authentication-based blocks.

How do I know if someone is using my domain for phishing?

Check your DMARC aggregate reports regularly. Look for authentication passes from sources you have not authorized. Unexpected passes are a signal that warrants investigation, especially if the volume is high or the sending patterns are unusual.

What does a DMARC aggregate report actually show?

It shows a summary of authentication results for mail claiming to be from your domain: how many messages passed or failed, which sources sent them, and whether they aligned with your domain policy. It does not show email content, only the authentication outcome.

Should I move to p=reject if I am seeing phishing that passes authentication?

Moving to p=reject requires knowing every legitimate source that sends mail for your domain. If you reject before completing that audit, you will lose legitimate email. Start with p=quarantine and use aggregate reports to identify all legitimate sources first.

Bottom line

SPF, DKIM, and DMARC passing means the sending domain owns the message. It does not mean the message is safe. Phishing that passes all three checks is not a failure of email authentication. It is a consequence of authentication doing exactly what it was designed to do. Detecting this attack pattern requires looking at who is sending mail on your behalf, not just whether messages pass or fail authentication. Aggregate reports are the way to do that systematically.