RFC 5321.MailFrom vs RFC 5322.From: What's the difference?

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.

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.

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 describes envelope authentication. The DMARC overview explains why the visible author domain becomes the alignment target.

What are the requirements?

RFC 5321 defines MAIL FROM 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 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 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 for the exact domains and Email Security Score for public configuration. Header evidence is still required to see which identities production used.