RFC 5322 — Internet Message Format

RFC 5322 defines the format of an email message — the headers, the body, and the syntax rules both follow. It obsoletes RFC 2822, which obsoleted RFC 822, the 1982 original.

It is not an email-authentication document, but every one of them depends on it, and DMARC specifications refer to RFC5322.From constantly.

Why it matters for DMARC

DMARC is built on one distinction this document makes possible: the difference between the From: header field defined here and the envelope sender used during SMTP delivery.

• RFC5322.From — the address your recipient sees, defined by RFC 5322
• RFC5321.MailFrom — the envelope sender, defined by RFC 5321, and what SPF actually checks

Nothing requires those two to match. That gap is why a message can pass SPF and still be a convincing forgery, and it is the entire reason DMARC exists: it requires SPF or DKIM to pass and to align with RFC5322.From.

The other thing it explains

RFC 5322 permits multiple addresses in a From: header. DMARC does not know what to do with that, and receivers handle it inconsistently — which is why every practical guide says use exactly one.

Where it shows up in practice

Read any authentication specification and you will see RFC5322.From and RFC5321.MailFrom used as shorthand. They are not two names for one thing — they are two different addresses defined in two different documents, and the whole design of DMARC follows from the gap between them.

That naming convention is itself defined elsewhere (RFC 8601, which specifies the Authentication-Results header), but it is RFC 5322 that gives the From: field its meaning.

Display names are not authenticated

RFC 5322 allows a From: header to carry a display name alongside the address:

From: "Your Bank Security" <attacker@example.net>

DMARC authenticates the domain in the address. It has nothing to say about the display name, which most mail clients show in preference to the address. A message can pass DMARC completely and still show a misleading name — that is a display problem, not an authentication failure, and no DMARC policy will stop it.

Read it: rfc-editor.org/rfc/rfc5322