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

What are the requirements?

RFC 5321 defines the SMTP reverse path

RFC 5321 section 4.1.1.2 defines the MAIL command and its FROM parameter. The reverse path identifies the source mailbox used for reporting errors related to the transaction. It is part of the SMTP envelope, not part of the message header that a recipient reads.

This is an illustrative SMTP and message-header shape:

MAIL FROM:<bounces@mailer.yourdomain.com>
RCPT TO:<recipient@example.net>
From: Product updates <news@yourdomain.com>
To: Recipient <recipient@example.net>
Subject: August update

The address after MAIL FROM: can differ from the address in From:. The SMTP server processes the envelope commands before it accepts the message fields after DATA.

RFC 5322 defines the visible author field

RFC 5322 section 3.6.2 defines From as an originator field that specifies the author or authors responsible for writing the message. The field is required in an RFC 5322 message.

From: does not direct delivery-status notifications. It describes the message's author identity. If a message has more than one address in From:, RFC 5322 requires a Sender: field that identifies the agent that actually transmitted the message.

RFC 5322 remains the controlling Internet Message Format specification for these fields. RFC 6854 updates RFC 5322's originator-field rules to permit multiple addresses in From under defined conditions.

DMARC compares authenticated domains to RFC 5322.From

RFC 9989 defines the RFC 5322.From domain as the DMARC Author Domain. DMARC passes when at least one aligned authentication mechanism passes: SPF with an aligned RFC 5321.MailFrom domain, or DKIM with an aligned signing domain.

A message can therefore have all of these results at once:

• SPF passes for mailer.vendor.example.
• The visible From: address uses yourdomain.com.
• SPF does not align because mailer.vendor.example is unrelated to yourdomain.com.
• DKIM can still satisfy DMARC if its passing d= domain aligns with yourdomain.com.

Authentication results report the identities used

RFC 8601 defines the Authentication-Results header field used by receivers to report authentication assessments. Its registered properties include smtp.mailfrom, smtp.helo, header.from, and header.d.

A typical delivered-message result can look like this:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces@mailer.yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

The exact wording and fields vary by receiver. Treat a receiver's header as evidence of that receiver's evaluation, not a universal statement about every mailbox provider.

When does the requirement take effect?

There is no rollout date or sender-volume threshold for the distinction itself. RFC 5321 and RFC 5322 were published as Draft Standards in October 2008, and their field roles apply whenever SMTP transports an RFC 5322 message. RFC 6854, published in March 2013, updates RFC 5322's handling of multiple originators.

RFC 9989 was published in May 2026 and defines the current DMARC specification. It obsoletes RFC 7489. DMARC evaluation happens when a receiver evaluates an individual message, subject to that receiver's implementation and local policy.

A DNS or sender-platform change can affect the next message immediately after the relevant systems use the new configuration. DNS propagation and cached records can delay what different receivers observe. A passing configuration screen is useful, but it does not prove that the production message used the expected reverse path or DKIM domain.

How do I implement the requirement?

1. Choose the visible RFC 5322.From domain

Use a From: domain that represents the organization or service the recipient expects. Make the visible address part of the sending-domain design, because DMARC uses its domain as the Author Domain.

2. Identify each platform's RFC 5321.MailFrom domain

For every application, ESP, and transactional sender, find the domain used in its SMTP envelope. A provider may call this a return path, bounce domain, envelope sender, or custom MAIL FROM domain.

Do not copy another tenant's DNS values. The sending provider generates the selectors, CNAME targets, and verification values for its own account.

3. Publish authentication for the production path

Publish SPF for the domain the actual sending infrastructure uses. Configure DKIM using the values generated by the sending platform. If the MailFrom domain cannot align with the visible From domain, configure an aligned DKIM signing domain before relying on DMARC.

Changing a return path can change bounce handling. Confirm that the selected destination can process delivery-status notifications before replacing an existing production setting.

4. Preserve null reverse-path behavior

Do not replace MAIL FROM:<> on delivery-status notifications with an ordinary sender address. RFC 5321 uses the null reverse path to avoid notification loops. Ensure those messages have an appropriate DKIM path if DMARC evaluation matters for them.

How do I validate compliance?

Start with DNS. Confirm the published SPF and DKIM records through the authoritative DNS provider and at least one public resolver. A public Email Security Score can inspect public authentication configuration for a domain. You can also use Palisade's DMARC checker to review the published DMARC record.

Then validate the vendor layer. Check that each sending platform reports its domain authentication or custom return-path setup as verified. This confirms the platform accepted the configuration. It does not confirm that a production message used it.

Next, send a real message through each exact production path and inspect the delivered raw headers. Compare:

• Return-Path, if the receiving system added it, with the expected reverse path.
• From: with the intended visible author domain.
• spf= and smtp.mailfrom= in Authentication-Results.
• dkim= and header.d=.
• dmarc= and header.from=.

Check the public authentication posture before reviewing reports

A delivered message may show that one platform used the intended identities, but it does not inventory every sender using the domain. Start with Palisade's Email Security Score to inspect the public SPF, DKIM, and DMARC posture before comparing it with headers and aggregate-report evidence.

Check your domain's email security score

A public DNS check cannot prove the production sending path, a receiver's private decision, continuous state, or future inbox placement.

For teams with multiple senders or domains, Start with Palisade. Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It proposes the next policy step from the evidence, while a human reviews the evidence and applies any change. Palisade does not change DMARC policy automatically or guarantee that every future message will authenticate.