Why DMARC can fail when SPF and DKIM pass

Compare identities, not just green status labels

SPF checks the envelope-sender identity; DKIM supplies a signing domain. DMARC relates a passing result to the visible From domain. One passing, aligned method is sufficient for DMARC; passing methods for unrelated domains are not. Relaxed alignment permits the same organizational domain, while strict alignment requires an exact domain match. Check the configured alignment mode instead of assuming subdomains always align.

Source: Microsoft: Troubleshoot email authentication

Example 1: both methods pass for someone else's domain

The following shortened headers are synthetic. The fictional sender uses example.com as its visible identity, but the service authenticates provider.example. These are distinct domains. Reading only the two pass labels would miss the mismatch.

A useful support request attaches this redacted comparison and asks the sending provider how to authenticate the customer's own domain. It does not ask for SPF to be ‘made green’ again: the result already passes for the service's identity. The unresolved task is the relationship to the domain the recipient sees.

From: Morgan <[email protected]>
Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=provider.example;
  dkim=pass header.d=provider.example;
  dmarc=fail header.from=example.com

Example 2: an aligned signature supplies the missing link

In this revised teaching fixture, the service signs with example.com. The SPF identity remains different, but the passing DKIM identity now matches the visible domain. The change is specific; there is no reason to claim that every domain in a message must match.

Use a fresh message after a configuration change. An old result is a record of the old sending path. Save both specimens with their test times so another administrator can understand what changed without needing your account credentials.

From: Morgan <[email protected]>
Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=provider.example;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Example 3: a subdomain needs the alignment mode checked

Suppose the visible From domain is example.com and the passing DKIM signing domain is mail.example.com. In relaxed mode these share an organizational domain. With strict DKIM alignment, they do not exactly match. If SPF is also unaligned, that difference can determine the DMARC outcome.

Before recommending any policy change, write the exact domains and configured mode in the incident note. Prefer correcting the sender's intended identity. Do not weaken an established domain policy merely to hide an unexplained failure.

Source: Microsoft: Troubleshoot email authentication

A focused investigation and repair checklist

Start with a message received by an account you control. Identify the receiving system's trusted authentication results; messages can contain several result headers from different hops. If you cannot establish which result belongs to the receiver, ask the mailbox administrator before interpreting it.

Keep forwarding paths separate from direct tests. If a direct test works but a forwarded copy fails, capture both paths rather than immediately replacing the domain's records. The difference is evidence for the next investigation.

1. Record the visible From, SPF identity, each passing DKIM signing domain and the observed DMARC result.
2. Check whether the passing identity aligns under the domain's actual policy.
3. Ask the sending provider for its supported custom-domain signing or return-path setup. Do not invent a DKIM key or selector.
4. Have the domain owner review the proposed change and any other services using that domain.
5. Send a fresh controlled test through the affected service, save the receiver's results and compare them with the failing specimen.
6. Recheck other legitimate sending services after shared DNS changes. Keep any unresolved path open in the handoff.

What to include when you ask for help

Provide the affected sending service, redacted domain comparison, policy mode, whether the route was direct or forwarded, the exact diagnostic and the time of the test. Do not include passwords, OAuth tokens or a full customer email body.

If alignment now passes, close that specific issue. Inbox placement and campaign response are separate questions. A clean authentication result is useful evidence about sender identity; it is not evidence that recipients wanted the message or that your campaign will generate meetings.