Envelope sender, From address and signing domain: read the email identity chain

A mail system can report SPF pass and DKIM pass while DMARC still fails. That outcome is not contradictory. Each mechanism begins with a different identity, and DMARC adds a relationship test between a passing identity and the domain in the message's From address.

The reliable way to investigate a message is to record the identity chain before changing DNS. Start with the domain the recipient sees in From. Then record the domain used for SPF and every domain found in a DKIM signature. Only after that should you assess alignment and the message-level DMARC result.

Name the three identities before reading the results

Consider this fictional message:

From: Billing Team <statements@billing.example.com>
Return-Path: <bounce+739@mailer.example.net>
DKIM-Signature: ... d=billing.example.com; s=outbound1; ...

The From domain is billing.example.com. DMARC calls it the Author Domain. The envelope sender is represented here by the Return-Path domain mailer.example.net; for the MAIL FROM check of this ordinary message, that is the identity SPF evaluates under RFC 7208 §2.4. A separate HELO check can also occur under RFC 7208 §2.3; Return-Path handling is specified in RFC 5321 §4.4. The DKIM signing domain is the value of d=, which is billing.example.com in this example.

A display name such as Billing Team is not an authentication identity. Reply-To is not the Author Domain either. Those fields can matter to a fraud investigation, but they do not replace the domains DMARC compares.

Record results and alignment separately

A raw SPF pass means the connecting source was authorised for the SPF identity that was evaluated. A raw DKIM pass means a signature verified for its d= domain and the covered message material. Neither result, by itself, says that its domain has the required relationship with From.

DMARC therefore needs two columns for each path:

• Path: SPF; Authentication question: Did SPF pass for the evaluated envelope identity?; Alignment question: Does that identity align with the Author Domain?
• Path: DKIM; Authentication question: Did this signature pass for its d= domain?; Alignment question: Does that d= domain align with the Author Domain?

Under RFC 9989 §3.2.10.2, strict alignment requires exact domain equality. Under RFC 9989 §4.10.2, relaxed alignment uses the applicable organisational-domain discovery relationship. Do not approximate that boundary by taking the last two labels, because public suffix rules can make that shortcut wrong.

Work through a pass and a misleading raw pass

The following is a synthetic teaching example, not a customer message. Assume an applicable valid policy, completed checks, trusted receiving results and known alignment modes; RFC 9989 §5.3.5 defines the resulting pass/fail rule.

• Observation: From; Message A: alerts@example.com; Message B: alerts@example.com
• Observation: SPF result; Message A: Pass for bounce.vendor.example.net; Message B: Pass for bounce.vendor.example.net
• Observation: SPF aligned?; Message A: No; Message B: No
• Observation: DKIM result; Message A: Pass with d=example.com; Message B: Pass with d=vendor.example.net
• Observation: DKIM aligned?; Message A: Yes; Message B: No
• Observation: Message-level DMARC; Message A: Pass through DKIM; Message B: Fail

Message A passes DMARC because one DKIM signature both verifies and aligns. Its unaligned SPF result does not cancel that valid path. Message B has two raw authentication passes, but neither authenticated domain aligns with the Author Domain, so there is no passing DMARC path.

This table is also a useful change record. It shows whether the repair belongs in the envelope identity, the signing configuration or the visible From domain. A green icon without these domains is not enough evidence to authorise a DNS change.

Inspect every DKIM signature

A message can carry more than one DKIM signature. An outbound service, a gateway and an intermediary can each add one. Evaluate each signature independently. One aligned passing signature can provide the DKIM path even when another signature is unaligned or fails.

Do not infer the selector from a provider name. Read the s= value from the actual DKIM-Signature header, combine it with that signature's d= domain, and query the resulting DNS name under RFC 6376 §3.6.2.1. Publishing a key only makes verification material available. The sending system must still create a valid signature with the corresponding private key.

Indirect mail can alter signed content or the envelope path. Forwarding can therefore affect SPF, while list modifications can affect DKIM. Treat the observed path as evidence to investigate, not proof that the original sender or intermediary was malicious.

Use trusted receiving evidence

Authentication-Results can summarise the identities and results, but trust depends on where the header was added. A sender can insert a header that claims success. Under RFC 8601 §7.1, use the result produced by the receiving system you administer, or another boundary whose handling you understand.

When the message was rejected before delivery, a delivered copy may not exist. Use the rejection response, provider logs and any receiving telemetry available. Do not invent missing identities from an error code alone.

Turn the identity chain into an operational record

For every material sender, retain:

1. the business owner and application;
2. the From domains it is authorised to use;
3. the observed envelope identity;
4. every observed DKIM d= domain and selector;
5. the authentication result for each path;
6. the alignment mode and conclusion;
7. a representative test date and message identifier.

That record separates business authorisation from protocol evidence. It also prevents a common mistake: changing the organisation's root SPF record to solve a DKIM alignment problem, or changing DMARC policy when the sender configuration is the real defect.

Once the identity chain is clear, use the alignment troubleshooting guide to repair a failing path and the sender inventory to assign ownership.

Keep the conclusion within the evidence

For message A, write SPF pass/unaligned and DKIM pass/aligned as separate facts. For B, do not convert two unrelated raw passes into a DMARC pass. Retain each signature independently and do not infer the SMTP identity solely from the display name. These cases and the abbreviated signature are teaching examples, not valid signature material or executed verification.