← RFC Reference

RFC 6854: Group Syntax in From and Sender Header Fields

Why This Exists

RFC 5322 requires the From header to contain one or more mailbox addresses. But some messages genuinely have no single human author:

• Automated system messages — monitoring alerts, build notifications, scheduled reports. No person wrote these.
• Mailing list digests — a digest aggregates messages from multiple authors. Who is the "From" address?
• Group-authored documents — messages drafted collaboratively by a team.
• Noreply addresses — some organizations want to indicate that no reply is expected, without exposing a real address.

RFC 6854 updates RFC 5322 to allow group syntax in the From and Sender headers. Group syntax can contain zero or more mailbox addresses, meaning you can have a From header with a descriptive name but no actual address inside it.

How It Works

Group Syntax Basics

Group syntax was already defined in RFC 5322 for headers like To and Cc. It looks like this:

; Group syntax: display-name ":" [mailbox-list] ";"

; Group with members (already allowed in To/Cc)
To: Engineering Team: alice@example.com, bob@example.com;

; Empty group — no addresses (the key innovation of RFC 6854)
From: Engineering Team:;

The critical new capability is the empty group in From: a display name followed by :; with no addresses between the colon and semicolon.

Requirements When Using Group Syntax in From

RFC 6854 sets strict conditions:

1. A Sender header is required. When the From field uses group syntax (especially empty groups), the message must include a Sender header with a valid mailbox address. This ensures there is always a responsible address for the message.
2. The Sender address must be a real, deliverable mailbox. It must be able to receive replies and bounces.
3. Use sparingly. The RFC explicitly notes this is for cases where no single author can be identified. Normal person-to-person email should continue to use standard mailbox syntax in From.

Practical Examples

; Automated monitoring alert — no human author
From: Monitoring System:;
Sender: noc@example.com
To: ops-team@example.com
Subject: [ALERT] Database connection pool exhausted

; Mailing list digest — multiple authors aggregated
From: Dev List Digest:;
Sender: dev-list-owner@lists.example.org
To: dev-list@lists.example.org
Subject: Dev List Digest, Vol 42, Issue 7

; Group with one member — the named author on behalf of a team
From: Security Team: security-lead@example.com;
To: all-staff@example.com
Subject: Mandatory password rotation notice

How It Differs from Standard From

Key Technical Details

Interaction with DKIM

DKIM signs the From header. When From contains group syntax, DKIM operates on the literal header value. The d= domain in the DKIM signature does not need to match an address in the From group (since there may be none). Instead, DKIM alignment for DMARC falls back to the Sender header or the envelope sender.

Interaction with DMARC

DMARC alignment requires the From domain to match the DKIM d= domain or the SPF-authenticated envelope sender domain. With an empty group in From, there is no domain to align against. In practice, this means:

• DMARC cannot evaluate alignment for empty-group From headers.
• Most DMARC implementations treat this as a non-applicable result.
• The Sender header or envelope sender provides the actual authentication anchor.

This makes empty-group From headers uncommon in practice for internet-facing email, since DMARC is now widely deployed.

Client Display Behavior

Mail clients handle group syntax in From inconsistently:

• Gmail: Displays the Sender address as the From, ignoring the group display name.
• Outlook: May display the group name or the Sender address, depending on version.
• Apple Mail: Typically shows the Sender address.
• Thunderbird: Shows the group display name with the Sender address in parentheses.

The inconsistent display is the main practical limitation of this feature.

ABNF Grammar Update

RFC 6854 updates the RFC 5322 grammar for from and sender fields:

; RFC 5322 original
from = "From:" mailbox-list CRLF

; RFC 6854 update
from = "From:" (mailbox-list / address-list) CRLF

; address-list allows group syntax
; group = display-name ":" [group-list] ";"

Common Mistakes

• Using empty-group From without a Sender header. RFC 6854 requires a Sender header when From uses group syntax with no mailbox addresses. Without Sender, there is no responsible address for bounces or replies, and strict parsers will reject the message.
• Expecting consistent client rendering. Most mail clients were not designed for group syntax in From. Test across Gmail, Outlook, and Apple Mail before deploying. The display may be confusing to recipients.
• Using this for internet-facing marketing or transactional email. DMARC alignment issues make empty-group From impractical for email that needs to pass authentication checks at major providers. Stick to a standard mailbox From for deliverability.
• Forgetting the semicolon terminator. Group syntax requires the closing ;. Without it, the header is malformed: From: Team: is invalid; From: Team:; is correct.
• Confusing group syntax with display names. From: Team <team@example.com> is a mailbox with a display name. From: Team:; is an empty group. They are entirely different constructs with different semantics and requirements.
• Using this when a noreply address suffices. For most automated messages, From: noreply@example.com is simpler, more compatible, and better understood by recipients and spam filters than group syntax.

Deliverability Impact

• Empty-group From breaks DMARC alignment. Since there is no domain in the From address, DMARC has nothing to align. Messages relying on this syntax will fail DMARC checks at most receivers, leading to rejection or quarantine if the sender domain has a strict DMARC policy.
• Spam filters may flag unfamiliar From syntax. Group syntax in From is rare. Spam filters trained on normal email patterns may treat it as anomalous, increasing the spam score.
• Prefer standard From addresses for all external email. Use a real mailbox like noreply@example.com or notifications@example.com. This is universally compatible, passes DMARC, and renders correctly in all clients.
• Group syntax is appropriate for internal or controlled environments. Within an organization where you control the mail infrastructure and clients, group syntax can meaningfully represent team or system authorship. For internet-facing email, the deliverability tradeoffs are not worth it.
• Always include a valid Sender header. Even if delivery works without it in your tests, the Sender header is the fallback for bounces, replies, and authentication. Omitting it risks silent failures at scale.

Related RFCs