Three domain fields can look interchangeable in a dashboard while describing different parts of a message. Header From identifies the author domain used by DMARC. Envelope From describes the SMTP sender identity relevant to SPF. Envelope To describes the SMTP recipient domain, when supplied. Start by labeling those roles rather than choosing whichever domain looks familiar.
Build a field dictionary
References: RFC 9990 §3.1.1.10, RFC 9989 §3.2.4, RFC 7208 §2.4.
RFC 9990 section 3.1.1.10 requires header_from and makes envelope_from and envelope_to optional. These fields contain domains, not a complete list of mailbox addresses. A missing optional field means the report did not supply it; it does not prove the SMTP transaction lacked that identity.
The envelope_from element may exist but be empty for a null reverse-path. Preserve the distinction between missing and empty in your parser. Do not fill an empty value from Header From or assume a guessed bounce address was evaluated. RFC 9989 section 3.2.4 relies on SPF validation of the MAIL FROM identity and explicitly refers to RFC 7208 section 2.4 for a null reverse-path: SPF constructs that identity as postmaster at the HELO domain. A passing SPF result for this constructed MAIL FROM identity can contribute to DMARC when its domain aligns with the Author Domain. This is distinct from substituting an independently evaluated HELO result for a nonempty MAIL FROM identity. Preserve the evaluated identity and result before drawing an alignment conclusion.
Read the authenticated identifiers too
References: RFC 9990 §3.1.1.12, RFC 9990 §3.1.1.13.
Compare identifiers with auth_results, which reports the domain actually used during SPF validation and the d and s values used for DKIM validation. The visible author domain is not itself evidence that SPF authenticated it. Likewise, a DKIM d domain can differ from both envelope domains.
Envelope To is useful recipient-domain context. It is not the domain DMARC aligns with SPF or DKIM, and it should not be treated as the message's visible To field. Forwarding, aliases and blind copies can make visible headers a poor account of the SMTP recipient path.
Reproduce a synthetic outcome
References: RFC 9989 §5.3.5.
Assume an applicable valid policy, completed checks and unrelated brand.example/vendor.example organizational domains. Consider header_from=brand.example, envelope_from=bounces.vendor.example and envelope_to=recipient.example. Assume SPF passes for bounces.vendor.example and a DKIM signature passes with d=brand.example. SPF does not align with brand.example because the domains are unrelated. DKIM aligns exactly, so DMARC can pass through DKIM despite the unaligned SPF result.
Changing only envelope_to to another recipient domain does not change that alignment calculation. Changing the passing DKIM d value to vendor.example would remove the aligned DKIM path in this example. These are assumed inputs for a field-level exercise, not a real receiver test or a complete XML report.
Preserve uncertainty in an investigation
Record the reporter, period, source IP, row count and raw field values next to the interpretation. If a dashboard omits the envelope fields, inspect the original report before concluding they were absent. If the report itself omits them, obtain an authorized controlled message from the relevant route instead of manufacturing a value.
A useful worksheet has separate columns for author, SMTP sender, SMTP recipient, authenticated SPF domain, each DKIM domain and DMARC-related results. Reconcile contradictions before changing DNS. The objective is a reproducible identity comparison, not making every column contain your brand name.
Check five reproducible identity cases
References: RFC 9989 §3.2.10.2, RFC 9989 §5.3.5.
Use strict alignment for both mechanisms in this exercise. The base synthetic row has header_from=brand.example, envelope_from=bounces.vendor.example, envelope_to=recipient.example, raw SPF pass for bounces.vendor.example, and raw DKIM pass for brand.example with selector invoice1. Its source IP is 192.0.2.40 and its count is 12. Cryptographic and SPF outcomes are assumed inputs; the exercise checks the identity comparison, not real authentication.
- Variation from the base row: None; Aligned SPF: No; Aligned DKIM: Yes; DMARC: Pass
- Variation from the base row: Only envelope_to becomes another.example; Aligned SPF: No; Aligned DKIM: Yes; DMARC: Pass
- Variation from the base row: Only DKIM domain becomes vendor.example; Aligned SPF: No; Aligned DKIM: No; DMARC: Fail
- Variation from the base row: envelope_from omitted; original raw SPF result retained; Aligned SPF: No; Aligned DKIM: Yes; DMARC: Pass
- Variation from the base row: envelope_from empty; raw SPF identity and result not supplied; Aligned SPF: Not established without the null-path SPF identity and result; Aligned DKIM: Yes; DMARC: Pass
The supplied local strict-equality exercise reproduces five outcomes with aligned DKIM available in the missing- and empty-field cases. It did not establish the SPF outcome for every null reverse-path. The missing-field case deliberately retains an unrelated raw SPF domain; an omitted envelope_from field does not itself make SPF fail. The empty-field case explicitly removes the original raw SPF inputs rather than inventing a null-path identity. For that case, obtain the SPF-validated constructed MAIL FROM identity described in RFC 9989 section 3.2.4 and RFC 7208 section 2.4 before evaluating its alignment. The table's DMARC pass remains supplied by DKIM. For example, assuming an applicable DMARC policy and strict alignment, a passing SPF result for postmaster@brand.example can supply an aligned SPF path for header_from=brand.example even without aligned DKIM. A passing result for postmaster@other.example cannot. These two additional examples are assumed outcomes, not newly executed fixtures. No actual received message is represented.
Keep the exercise within scope
The examples are partial field projections, not schema-valid reports or measured traffic. Local checks use explicitly supplied authentication results and organizational relationships; they do not perform DNS discovery, SPF evaluation, cryptographic verification, report ingestion or receiver delivery tests. Preserve the original report and trusted message evidence before making a production change.