Troubleshoot email authentication in Microsoft 365

Email authentication and the corresponding DNS records help protect your organization from spoofing, phishing, and spam. For an overview of email authentication, see Email authentication in Microsoft 365. When authentication fails, legitimate messages can be quarantined, rejected, or routed to the Junk Email folder. Use the quick-reference troubleshooting tables to identify common symptoms and causes, followed by detailed guidance for each failure scenario.

Quick-reference troubleshooting tables

Use the tables in the following sections to quickly identify the symptom, likely cause, and link to the relevant detailed guidance.

SPF failures

To troubleshoot Sender Policy Framework (SPF) errors, use the information in the following table:

DKIM failures

To troubleshoot DomainKeys Identified Mail (DKIM) errors, use the information in the following table:

DMARC failures

To troubleshoot Domain-based Message Authentication, Reporting, and Conformance (DMARC) errors, use the information in the following table:

Composite authentication failures

To troubleshoot composite authentication (compauth) errors, use the information in the following table:

NDRs for email authentication failures

Use the information in the following table to troubleshoot non-delivery reports (also known as NDRs or bounce messages) related to email authentication failures.

Detailed troubleshooting by protocol

Troubleshoot SPF

SPF validates that the sending mail server is authorized to send on behalf of the domain in the MAIL FROM (envelope sender) address. Common issues include:

• Multiple SPF records for the same domain: Only one SPF TXT record is allowed per domain or subdomain. Multiple records cause SPF permerror.
• Exceeding the 10 DNS lookup limit: Each include, a, mx, ptr, and redirect mechanism counts as a DNS lookup. To reduce lookups, flatten your SPF record or use ip4/ip6 mechanisms.
• Missing authorized senders: When you add a new email service (for example, a customer relationship management (CRM) platform or marketing tool), add its SPF include to your record.
• TTL too low: Set the TTL for your SPF TXT record to at least 3600 seconds (one hour) to avoid DNS lookup timeouts.

For complete setup and troubleshooting instructions, see Set up SPF to identify valid email sources for your Microsoft 365 domain.

Troubleshoot DKIM

DKIM uses a cryptographic signature in the message header to verify the message wasn't tampered with in transit. Common issues include:

• CNAME records not published: After you enable DKIM in the Defender portal, create two CNAME records at your domain registrar. For common mistakes and provider-specific examples, see Troubleshoot DKIM DNS configuration.
• Body hash failure after modification: Intermediary services (for example, mailing lists or transport rules) that modify the message body after DKIM signing cause DKIM failure. Consider configuring the intermediary as a trusted ARC sealer.
• Key rotation: Rotate DKIM signing keys regularly. Use the Rotate-DkimSigningConfig cmdlet in Exchange Online PowerShell.

For complete setup instructions, see Set up DKIM to sign mail from your Microsoft 365 domain.

Troubleshoot DMARC

DMARC builds on SPF and DKIM to verify domain alignment with the From address. Common issues include:

• Domain misalignment: DMARC requires that either SPF or DKIM passes and the authenticated domain aligns with the From address domain.
• Non-Microsoft services failing DMARC: Add the service to your SPF record, or configure the service to DKIM-sign with your domain (preferred). If those options aren't possible, use a subdomain for that service with a separate DMARC record.
• Forwarding scenarios: Forwarded messages commonly fail DMARC because forwarding breaks SPF. Configure Enhanced Filtering for Connectors or trusted ARC sealers to preserve authentication results.

For complete setup instructions, see Set up DMARC to validate the From address domain.

Combined failure scenarios

When multiple email authentication protocols fail simultaneously, troubleshooting requires a systematic approach. Use the following scenarios to diagnose and resolve combined failures.

SPF and DKIM both fail

Example header:

Authentication-Results: spf=fail smtp.mailfrom=contoso.com;
 dkim=fail header.d=contoso.com; dmarc=fail action=quarantine;
 compauth=fail reason=000

Analysis: Both SPF and DKIM authentication failed, so DMARC can't pass (DMARC needs at least one aligned pass). The message is likely quarantined or rejected.

Troubleshooting steps:

1. Identify the sending IP address in the message headers or by using Get-MessageTrace.
2. Verify that the sending IP is included in the domain's SPF record.
3. Verify that DKIM signing is enabled and the DKIM DNS CNAME records exist.
4. Check whether an email gateway is modifying messages (which breaks DKIM) or sending from an IP that isn't in the SPF record.

Fix priority:

1. Fix SPF first (DNS change only; fastest fix). See Set up SPF.
2. Fix DKIM second (might need Microsoft 365 and DNS changes). See Set up DKIM.
3. Verify DMARC alignment. See Set up DMARC.
4. If a gateway is involved, implement ARC.

SPF passes but DMARC fails due to alignment

Example header:

Authentication-Results: spf=pass smtp.mailfrom=service.contoso.com;
 dkim=fail header.d=contoso.com;
 dmarc=fail (SPF not aligned);
 compauth=fail reason=001

Analysis: SPF passes but the SPF domain doesn't align with the From address domain. DKIM also fails. DMARC needs at least one aligned pass, so it fails.

Common cause: Forwarding or relay scenario where the envelope sender domain differs from the From address domain.

Fix: Enable DKIM signing for the From address domain. DKIM alignment provides the aligned pass that DMARC needs.

Connect to Exchange Online PowerShell and run the following command:

Set-DkimSigningConfig -Identity contoso.com -Enabled $true

Gateway or relay modifying messages

Example header:

Authentication-Results: spf=pass smtp.mailfrom=gateway.fabrikam.com;
 dkim=fail (body hash did not verify) header.d=contoso.com;
 dmarc=fail (no aligned pass)

Analysis: The message passed through a gateway or security service that modified the message body (for example, by adding a disclaimer or scan notice). The modification invalidated the DKIM signature. SPF passes for the gateway domain but doesn't align with the From domain.

Fix options (in priority order):

1. Configure ARC on the gateway (recommended): ARC preserves authentication results through message modification. See Configure trusted ARC sealers.
2. Configure the gateway to DKIM-sign after modification: The gateway adds its own valid DKIM signature with your domain after any content changes.
3. Add the gateway to Enhanced Filtering for Connectors: Preserves the original sending IP for authentication evaluation. See Enhanced Filtering for Connectors.

Forwarding breaks authentication

Example header:

Authentication-Results: spf=fail (sender IP is 10.0.1.x)
 smtp.mailfrom=woodgrovebank.com;
 dkim=pass header.d=woodgrovebank.com;
 dmarc=fail (SPF failed, DKIM not aligned)

Analysis: A forwarded message fails SPF because the forwarding server's IP isn't in the original sender's SPF record. DKIM might pass if the message wasn't modified, but alignment with the From domain might still fail.

Fix: Configure trusted ARC sealers. Microsoft 365 already trusts ARC seals from major providers (for example, Google and Yahoo). If authentication still fails after ARC is in place, review your anti-phishing policy settings.

Common real-world scenarios

Send on behalf of in Outlook

What the user sees:

From: [email protected] on behalf of [email protected]

Root cause: SPF softfail or fail because the sending IP isn't authorized in the SPF record.

Fix: Add the sending IP or service include to the SPF record:

v=spf1 ip4:<sending-IP> include:spf.protection.outlook.com ~all

Marketing automation fails DMARC

Example header:

Authentication-Results: spf=pass smtp.mailfrom=northwindtraders.com;
 dkim=pass header.d=northwindtraders.com;
 dmarc=fail (no aligned pass) header.from=contoso.com

Root cause: The marketing service (for example, Marketo or HubSpot) sends from its own infrastructure. SPF and DKIM both pass for the service domain, but neither aligns with the From address domain (contoso.com).

Fix options:

1. Configure the service to DKIM-sign with your domain (preferred).
2. Add the service's SPF include to your domain's SPF record (provides aligned SPF pass).
3. Use a subdomain for marketing mail (for example, marketing.contoso.com):
   • Configure SPF and DKIM for the subdomain at the service.
   • Set relaxed alignment in your DMARC record: aspf=r; adkim=r.
   • Add a subdomain policy to DMARC: v=DMARC1; p=quarantine; sp=none; rua=mailto:[email protected].

Cloud email security gateway breaks authentication

Example header:

Authentication-Results: spf=pass smtp.mailfrom=tailspintoys.com;
 dkim=fail (body hash did not verify) header.d=contoso.com;
 dmarc=fail

Root cause: A non-Microsoft email security service (for example, Proofpoint or Mimecast) modifies the message, which breaks DKIM. The gateway's SPF passes for its own domain but doesn't align with the From domain.

Fix options (in priority order):

1. Configure the gateway for ARC (recommended; requires gateway support).
2. Configure Enhanced Filtering for Connectors to skip the gateway's IP in authentication evaluation. See Enhanced Filtering for Connectors.
3. Configure the gateway to preserve or re-sign DKIM after processing.

Partner domain emails quarantined despite valid authentication

Example header:

Authentication-Results: spf=pass smtp.mailfrom=wingtiptoys.com;
 dkim=pass header.d=wingtiptoys.com;
 dmarc=pass header.from=wingtiptoys.com;
 compauth=fail reason=001

Root cause: All standard authentication passes, but Microsoft's composite authentication still fails. Spoof intelligence is likely flagging the partner domain due to cross-tenant trust issues.

Fix: Add the partner domain to the spoof allow list by using the Tenant Allow/Block List. Connect to Exchange Online PowerShell and run the following command:

New-TenantAllowBlockListSpoofItems -SpoofedUser "*@wingtiptoys.com" -SendingInfrastructure wingtiptoys.com -SpoofType External -Action Allow

Decision matrix

Use the following table to quickly identify the required action based on the authentication state:

Diagnostic tools

Use the following tools to diagnose email authentication issues:

Read authentication results in message headers

To diagnose authentication failures, examine the Authentication-Results header in the affected message. For a complete description of all fields and reason codes, see Authentication-Results message header.

Example header

Authentication-Results: spf=fail (sender IP is 192.168.50.50)
 smtp.mailfrom=contoso.com; dkim=pass (signature was verified)
 header.d=contoso.com; dmarc=fail action=quarantine
 header.from=contoso.com; compauth=fail reason=000

Key fields

Related content

• Email authentication in Microsoft 365
• Set up SPF
• Set up DKIM
• Set up DMARC
• Configure trusted ARC sealers
• Anti-spam message headers
• Spoof settings in anti-phishing policies