# RFC 5321.MailFrom vs RFC 5322.From: What's the difference? > RFC5321.MailFrom is the SMTP return-path identity; RFC5322.From is the visible author identity. Learn how SPF and DMARC use the two domains. RFC5321.MailFrom is the SMTP envelope sender, also called the reverse path. Mail systems use it for delivery-status handling, and SPF normally evaluates its domain. RFC5322.From is the author address inside the message header, usually the address a recipient sees. DMARC connects these layers by comparing the visible RFC5322.From domain with a passing SPF-authenticated MailFrom domain or a passing DKIM signing domain. The two addresses can differ without violating SMTP, but that difference can break DMARC alignment. ## Quick takeaways - RFC5321.MailFrom belongs to the SMTP transaction and becomes the Return-Path after delivery. - RFC5322.From belongs to the message header and identifies the author. - SPF normally authenticates the MailFrom domain, not the visible From domain. - DMARC treats RFC5322.From as the Author Domain. - Different domains can be valid operationally but still fail DMARC alignment. ![Two From identities serve different roles, shown as a four-step technical sequence.](/images/editorial/rfc5321-mailfrom-vs-rfc5322-from/rfc5321-mailfrom-vs-rfc5322-from-visual-guide.svg) *This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. [Open the full-size diagram](/images/editorial/rfc5321-mailfrom-vs-rfc5322-from/rfc5321-mailfrom-vs-rfc5322-from-visual-guide.svg).* ## Who is affected? Anyone diagnosing SPF or DMARC needs to keep the two identities separate. The distinction is especially important for third-party senders, bounce handling, forwarded mail, and messages with a null reverse path. The [SPF overview](/learning/what-is-spf) describes envelope authentication. The [DMARC overview](/learning/what-is-dmarc) explains why the visible author domain becomes the alignment target. ## What are the requirements? [RFC 5321 defines MAIL FROM](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.1.2) as part of the SMTP conversation. Its reverse path identifies where delivery-status notifications should go. Some notification messages use a null reverse path to avoid mail loops. [RFC 5322 defines the From header](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.2) as an originator field that identifies the author or authors. It is part of the message content and remains visible after the SMTP envelope has completed its job. SPF evaluates an SMTP identity, usually the MailFrom domain. DKIM uses the signing domain in its signature. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines how DMARC compares a passing SPF or DKIM identity with the RFC5322.From Author Domain. Relaxed alignment can allow related subdomains, while strict alignment requires exact domain equality. ## When does the requirement take effect? The MailFrom identity is supplied during the SMTP transaction. The From header exists in the message data. A receiver records and evaluates both during delivery, then can add Authentication-Results and a Return-Path field to the stored message. DMARC alignment is evaluated for each received message. A provider configuration change that alters only the return path can therefore change SPF alignment without changing what recipients see. ## How do I implement the requirement? ### 1. Choose a visible author domain Use an RFC5322.From domain that accurately identifies the organization or service represented by the message. ### 2. Configure a controlled return path Use a MailFrom domain that can receive or process bounces and publish an SPF policy for the actual sending infrastructure. ### 3. Align one authenticated identity Configure the return-path domain for SPF alignment, the DKIM signing domain for DKIM alignment, or both. A provider-owned bounce domain can pass SPF without aligning to your From domain. ### 4. Preserve bounce and notification behavior Do not rewrite null reverse paths on delivery-status notifications or direct automated replies toward an address that can create loops. ## How do I validate compliance? Capture a delivered message and compare Return-Path, From, SPF's smtp.mailfrom, DKIM's header.d, and DMARC's header.from. Confirm that the expected method passes and aligns. Repeat for every platform because each can choose different envelope identities. Use the [DNS lookup tool](/tools/dns-lookup) for the exact domains and [Email Security Score](/tools/email-security-score) for public configuration. Header evidence is still required to see which identities production used. ## Frequently asked questions ### Is Return-Path the same as From? No. Return-Path records the SMTP reverse path after delivery. From identifies the author in the message header. ### Which address does SPF check? SPF normally checks the RFC5321.MailFrom domain. When that path is null, SPF has a defined HELO-based fallback. ### Which address does DMARC protect? DMARC uses the RFC5322.From domain as the Author Domain and requires aligned authenticated evidence for it. ### Can the two domains be different? Yes. Different domains are common with third-party bounce handling. For DMARC, at least one passing SPF or DKIM domain still needs to align with the visible From domain. ### Why does changing a custom return path fix DMARC? It can replace a provider-owned MailFrom domain with a domain related to the visible From domain, allowing a passing SPF result to align.