With an applicable policy and a completed evaluation, SPF and DKIM can both pass while DMARC fails under RFC 9989 §5.3.5. That happens when the domains those mechanisms authenticated do not align with the domain people see in the From address.
Each mechanism answers a different question. SPF checks whether the connecting source is authorised for the evaluated envelope identity. DKIM verifies a signature associated with a signing domain. DMARC then checks whether a passing identity has the required relationship with the visible From domain. The way to diagnose this problem is to compare those identities, not count the green pass labels.
Collect the identities from a received message
Obtain an original message from the receiving system, including its trusted authentication results. An arbitrary header saying pass can be supplied by an untrusted sender; identify the receiving boundary that generated the evidence under RFC 8601 §7.1.
Record these fields:
- Evidence: Visible From domain; What it establishes: The Author Domain, meaning the domain in the visible From address
- Evidence: SPF result and evaluated MAIL FROM identity; What it establishes: Whether the connecting source was authorised for that envelope identity
- Evidence: Each DKIM result and its d= domain; What it establishes: Which domain's signature verified
- Evidence: Applicable aspf and adkim modes; What it establishes: Whether exact or relaxed domain relationships are required
- Evidence: Trusted DMARC result and diagnostic context; What it establishes: The receiver's observed evaluation
Under RFC 5321 §4.4, for ordinary messages, the delivered Return-Path can help identify the envelope return identity. Correlate it with trusted SPF results and route evidence instead of assuming a display field tells the whole SMTP story.
Worked example: two passes, no aligned identity
This is a synthetic illustration assuming an applicable valid policy and completed checks, not a captured customer message:
- Field: From; Observed value: accounts@example.com
- Field: SPF; Observed value: pass for bounce.example.net
- Field: DKIM; Observed value: pass with d=example.org
- Field: DMARC alignment; Observed value: Neither passing domain aligns with example.com
Both mechanisms succeeded at their own jobs. Neither establishes the required relationship with example.com, so they do not provide a DMARC passing path for that visible From domain.
A supported fix might configure a customer-domain DKIM signature. Another possibility is a supported custom envelope domain that produces a passing aligned SPF path. Which option is available depends on the actual sending product and route.
Do not invent DNS values. Obtain the supported configuration from the service, publish it at the correct owner names, enable the relevant sending feature and send a new test through the same application workflow.
Apply strict and relaxed alignment correctly
With strict alignment, the relevant domains must match exactly under RFC 9989 §3.2.10.2, for either mechanism. The relevant DKIM and SPF identifiers are specified in RFC 9989 §4.4.1 and RFC 9989 §4.4.2, respectively. With relaxed alignment, DMARC uses the applicable organisational-domain relationship and discovery rules in RFC 9989 §4.10.2.
For a simple illustrative case, a passing envelope identity at bounce.example.com can align with a From domain of example.com under relaxed SPF alignment. It does not satisfy strict SPF alignment because the two names differ.
Do not generalise organisational-domain discovery into a rule that always takes the last two labels. Domain boundaries and current DMARC discovery rules matter. Check the actual policy and implementation for more complex domain structures.
When multiple DKIM signatures exist, inspect all relevant signatures. One unaligned passing signature does not invalidate a separate aligned passing signature. Conversely, the presence of your domain in a failed signature does not create a passing path.
Find the supported identity settings in the sending service
This often appears after a team starts using a CRM, billing tool or campaign service. The vendor says authentication is enabled, but some recipients reject the messages. Both statements can be true if the platform authenticates its own domain while the business displays yours.
Ask the operator to show one affected message and explain the visible sender, the envelope sender and the signing domain. A useful resolution demonstrates that the actual business workflow sends through a supported aligned identity. A screenshot showing two green checks is insufficient.
Keep the application owner involved. The right fix may be a setting or plan-specific capability in that service, rather than a change in the employee-mail platform.
Test the correction through the original route
Send a controlled replacement message through the affected service. Compare its From domain, envelope identity and every relevant DKIM signature with the prior sample. Keep the trusted receiver result and the configuration change together.
If a simple direct test passes but the business route still fails, inspect forwarding, gateways and message modifications. They can change which authentication path survives. Also distinguish a DMARC pass from inbox placement; the receiver can apply additional filtering under RFC 9989 §5.4.
Use the Microsoft 365 guide or Google Workspace guide where those systems are the actual senders. If the message uses another application, investigate that application's own route. Use aggregate reports to look for the same pattern across observed traffic.
Decide what the failure tells you
An alignment failure establishes a technical result. It does not, by itself, establish whether the message was legitimate, an unauthorised service, a forwarding casualty or an impersonation attempt.
Require an owner and business purpose for a sender before approving new trust. Shared infrastructure and a recognisable provider name are useful clues, but they do not prove that your organisation authorised the account or workflow.
Record the accepted scope of the fix. An aligned signing identity can satisfy DMARC while the account is later compromised or the application generates unsafe content. Continue account controls, application validation and independent approval of sensitive transactions.
The practical takeaway
Close the issue when the affected workflow produces a new message with a trusted passing aligned result. Keep the identity comparison and the configuration change together. This explains both why the original message failed and why the correction works.
Make the next decision explicit
For the two-pass fixture, record “no aligned passing path” rather than “SPF broken.” Choose the service-supported identity to repair and leave the change pending until a new same-workflow message verifies. If policy discovery or DNS processing is incomplete, do not force the observation into a pass/fail label; RFC 9989 §5.3.6 treats required DNS errors separately. No customer configuration or delivery test was performed.