The Identity Stack: From Visible From to DMARC

This chapter explains the identity stack that lets a receiving system connect the domain a recipient sees with the technical identities behind a message. The central question is not simply whether SPF or DKIM “passed,” but whether one of those authenticated identities is aligned with the visible From domain and covered by a DMARC policy. By the end, you should be able to trace a DMARC pass or failure and state what that result proves without mistaking it for a guarantee of inbox delivery.

Suppose a message arrives showing news.example.com in its From address. The receiving system can ask several different questions. Did the connecting server have permission to send for the domain used in the SMTP envelope? Did a valid cryptographic signature identify a domain responsible for the message? Does either of those domains correspond to news.example.com in the way the domain owner requires? These questions concern related identities, but they are not the same question and they do not produce the same result.

The distinction matters because email contains more than one domain identity. A sender may use a vendor's domain in the transport envelope while displaying the organization's domain to the recipient. A signature may be valid but belong to an unrelated service. Conversely, a message may have a valid aligned DKIM signature even when its SPF result fails. DMARC is the mechanism that evaluates this relationship rather than treating any isolated authentication success as proof that the visible identity is authorized.

Three Identities, One Visible Claim

The visible From domain is called the Author Domain. It is extracted from the From header that the recipient's mail application displays. The choice is deliberate: that is the domain a person is likely to associate with the message, and it is the identity most directly targeted by domain spoofing. DMARC begins with this visible claim, not with the server's IP address or with a hidden transport field.

SPF and DKIM provide the underlying evidence, but they describe different things. SPF, or Sender Policy Framework, uses DNS to publish which systems are authorized to send for a domain. In the DMARC context, the relevant SPF identity is the domain in the SMTP MAIL FROM command, often reflected in the message's return-path. The domain used in the SMTP HELO or EHLO greeting can also be checked by SPF, but DMARC relies on the MAIL FROM identity. If the connecting system is authorized for that domain, SPF can produce a pass and identify that domain as the SPF-authenticated identifier.

DKIM, or DomainKeys Identified Mail, takes a different route. The sender attaches a cryptographic signature to the message. The signature includes a d= value naming the domain that takes responsibility for the signed message and an s= value identifying the selector used to find the corresponding public key. If the signature validates, the domain named by d= becomes the DKIM-authenticated identifier. The result is tied to the signed message rather than only to the server that connected at one moment.

Neither underlying result is yet a DMARC result. An SPF pass says that an authorized system sent for the SPF domain. A DKIM pass says that a signature associated with the DKIM signing domain validated. Neither statement, by itself, says that the domain is the one shown in the visible From field. That is the gap DMARC fills.

A domain owner publishes a DMARC policy record in DNS as a TXT record at a name beginning with _dmarc. The record tells a receiver that the owner wants the Author Domain's use to be evaluated and can express a preference for messages that fail the evaluation. It can also request feedback. When a receiver finds an applicable record, it evaluates the Author Domain against the authenticated identifiers from SPF and DKIM.

The key rule is simple to state: a message passes DMARC when at least one authenticated identifier both passes its underlying authentication check and aligns with the Author Domain. This is why DMARC is not a third name for SPF or DKIM. It is a relationship test over their results.

Consider three illustrative combinations:

• The message displays news.example.com, and SPF passes for bounce.example.com. If the two domains share the relevant Organizational Domain, SPF can satisfy DMARC under relaxed alignment.
• The message displays news.example.com, and DKIM passes for news.example.com. The domains are identical, so the DKIM identifier satisfies strict alignment as well as relaxed alignment.
• The message displays news.example.com, but the only successful authenticated identifier is mailer.example.net. The authentication may be valid, yet the identifier is not aligned with the Author Domain, so it cannot produce a DMARC pass.

This separation explains a common diagnostic mistake. “The vendor authenticated the message” may be true while “the organization's visible domain passed DMARC” is false. The vendor may have authenticated its own domain, or the sender may have configured the right signature but the wrong visible identity. The repair is not necessarily to rewrite the message. It may be to make the transport or signing domain align with the domain the recipient sees.

The mechanisms also provide a degree of redundancy. DMARC needs only one aligned underlying pass, so a message can pass through aligned DKIM even when SPF fails, or through aligned SPF when no aligned DKIM signature is available. That does not make the mechanisms interchangeable. SPF depends on the envelope identity and the connecting path; DKIM depends on a signature, its covered content, and access to the right public key. Their different failure surfaces are part of the reason a domain owner should understand both.

The sequence has an important asymmetry. The sender publishes records and supplies identities, but the receiver performs the checks and makes the result. DNS is not a decorative directory consulted after the fact. It is where the receiver discovers the policy, finds SPF authorization, and obtains the public information needed to validate a DKIM signature. If the necessary DNS queries fail, the receiver may be unable to conclude pass or fail, and the published policy cannot necessarily be applied.

SPF also has a timing complication. SPF can be evaluated early in the SMTP transaction, before the message body is transmitted and before a receiver has discovered the visible Author Domain. If an SPF hard fail causes early rejection, a message that might otherwise have passed DMARC through aligned DKIM can be rejected solely on the SPF result. It may also never appear in a DMARC aggregate report, because the transaction did not reach the point where the receiver could process the visible From domain. A strong-looking assertion at one layer can therefore reduce visibility at another layer when its timing is ignored.

Alignment, Policy, and the Limits of the Result

Alignment comes in two modes. Strict alignment requires the authenticated identifier and the Author Domain to be identical. Relaxed alignment allows them to have the same Organizational Domain. In the common example of foo.example.com as the authenticated identifier and news.example.com as the Author Domain, relaxed alignment can succeed because both are under example.com; strict alignment fails because the full names differ. If the two domains are foo.example.net and news.example.com, they do not share the same Organizational Domain and are not aligned under either mode.

The Organizational Domain is not simply “whatever text remains after removing the leftmost label.” It represents the domain at the top of the relevant namespace hierarchy that has the same administrative authority. RFC 9989 uses DNS policy discovery and a DNS Tree Walk to determine this when necessary. The receiver first looks for a valid DMARC record at the Author Domain. If it does not find one, it walks toward a higher-level domain to find the applicable policy and determine the relevant organizational boundary. The updated process limits the walk to at most eight DNS queries as an anti-abuse protection. That limit is an operational constraint: a domain namespace cannot become arbitrarily deep and still expect every policy location to be discovered through the same walk.

This discovery process also explains why policy records and alignment are related but not identical. A record found at an Author Domain can supply the policy applied to that message, while the Organizational Domain used for alignment may depend on the record's psd setting or on the discovery process. A large organization with delegated DNS management may need explicit records to keep local policy boundaries visible. A receiver's interpretation must follow the defined discovery method rather than assuming that the organization's preferred administrative boundary is obvious from the domain name.

The policy record has two kinds of information. The adkim and aspf settings state whether the owner wants strict or relaxed alignment for DKIM and SPF. The p setting expresses what the owner prefers for messages using the domain but failing DMARC:

• none expresses no handling preference. When combined with aggregate reporting, it places the domain in a monitoring state and should not change existing handling.
• quarantine treats failing mail as suspicious. It does not claim that every failing message is fraudulent; it expresses a stronger concern about the failure.
• reject expresses that the domain owner considers the failing use invalid and requests the strongest handling among these policy values.

Subdomain behavior can be specified separately. The sp setting addresses existing subdomains, while np addresses non-existent subdomains. These distinctions matter in organizations that use many subdomains or delegate parts of their namespace. They also show why reading only the top-level p value can produce an incomplete explanation of what a receiver is expected to do.

A policy is a request within a distributed system, not an unconditional command. RFC 9989 leaves the final handling decision to the Mail Receiver. A receiver may accept a message that fails DMARC, even when the published policy is reject, if local analysis or interoperability concerns make that appropriate. It may also quarantine or reject a message that passes DMARC because a pass says only that the visible domain's use was authorized for that message. Authentication is one input to filtering, not a certificate of content quality or a promise of inbox placement.

The boundary becomes clearer when the protocol is tested against cases it was not designed to solve. DMARC addresses unauthorized exact-domain use, such as a message that claims to be from example.com without an authorized aligned path. It does not directly address a lookalike domain such as a visually similar spelling, a familiar person's name placed in the display-name portion of the From field, or the content of the message itself. It also does not validate the local part of the address. A DMARC pass for example.com cannot establish that the mailbox name before the @ is the person or department a recipient expects.

Malformed or multiple From domains create another boundary. DMARC depends on being able to identify the Author Domain reliably. If a message has no usable domain or more than one domain in the From field, normal validation may not be possible. Such messages can also be crafted to confuse processing or to display a spoofed domain to a user. Receivers need additional handling for those cases; they are not ordinary examples of a clean DMARC fail.

Relaxed alignment has a security trade-off as well as an interoperability benefit. If an attacker or an unwitting user controls a subdomain's SPF or DKIM records, that subdomain may align with the parent Organizational Domain under relaxed rules. For example, an authenticated identifier under evil.example.com can align with an Author Domain of example.com even if the parent domain owner did not intend that sender to represent the parent. Careful subdomain delegation, explicit policy records, and strict alignment where appropriate can reduce this risk. The choice depends on how much organizational flexibility the domain needs and how tightly its subdomains are governed.

The complete interpretation of a DMARC result therefore has several steps. First identify the Author Domain in the visible From field. Then identify which SPF and DKIM results actually passed, including their domains. Next determine whether the applicable policy exists and which alignment mode it specifies. Finally check whether at least one passing identifier aligns and remember that the receiver still makes the local disposition decision. Skipping any of these steps turns a layered result into a misleading label.

That is what a DMARC pass proves: for this message, a supported authentication mechanism produced an authenticated domain that aligned with the visible Author Domain under the applicable rules. It does not prove that the message is wanted, that its content is safe, that the sender's list was acquired responsibly, that every receiver will place it in the inbox, or that the domain's broader infrastructure is healthy. Those questions belong to the operational and feedback layers of deliverability. Authentication establishes an important identity relationship; it does not complete the trust decision.

References

• Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• M3AAWG Email Authentication Recommended Best Practices
• DMARC Aggregate Reporting