RFC 5321 and RFC 5322 describe different parts of an email message. The simplest way to understand them is:

• RFC 5321 covers the SMTP transaction between mail servers
• RFC 5322 covers the message headers and body seen by users

A message can therefore have:

• an envelope sender used during transport
• a header sender shown in the email client

These are related, but they are not the same thing.

The envelope sender: MAIL FROM, 5321.MailFrom, and Return-Path

During SMTP delivery, the sending server presents a sender address with the MAIL FROM command. This is the envelope sender, also called the reverse-path.

Its main purpose is operational:

• it tells receiving servers where delivery failure reports should go
• it is used by anti-spam systems for checks such as SPF
• after final delivery, it is usually recorded in the Return-Path header

Important points:

• The envelope sender is part of the SMTP envelope, not the visible message content
• The Return-Path header is normally added by the receiving/delivering server, not by the original sender
• The envelope sender does not have to match the visible From: address

The null reverse-path

RFC 5321 defines a special null sender:

<>

This is valid and important.

It is used for:

• bounce messages
• delivery status notifications
• certain other automatic system notices

The reason is to prevent mail loops. If a bounce cannot itself be delivered, the receiving server must not generate another bounce to that bounce. Seeing:

<>

tells the next server that this is already an error-reporting message and that another non-delivery report must not be created.

Does the envelope sender have to exist?

There are two separate questions:

1. Is the address syntactically valid?
2. Does the domain or mailbox actually exist?

Syntax

Under RFC 5321, the envelope sender must be valid SMTP address syntax, except for the special null sender:

<>

Domain existence

In practice, modern servers usually expect the domain part of the envelope sender to be real:

• the domain should exist in DNS
• it should not be obviously bogus
• many systems also expect it to have sensible mail-related DNS such as MX or A/AAAA records

If the domain does not exist, many receivers will reject the message during SMTP with a temporary or permanent failure.

Mailbox existence

This is different from domain existence.

For mail coming from the wider Internet, a receiving server usually cannot reliably prove that the sender mailbox itself exists. Many domains do not expose mailbox validity, and trying to verify it by connecting back to the sender’s server is generally poor practice.

So, in normal Internet mail flow:

• checking that the domain exists is reasonable
• checking that the remote mailbox exists is often unreliable and not recommended

The header sender: From: and RFC 5322

The From: header is the address users usually see in their email client.

Example:

From: Accounts Team <accounts@example.com>

This is governed by RFC 5322, which defines message format and header syntax.

What RFC 5322 requires

The From: field must be:

• present in a normal message
• syntactically valid
• properly formed as an email address or mailbox list

Invalid examples include malformed addresses such as:

john smith example.com
john@
@example.com

Those are not RFC-compliant.

Does the From: mailbox have to be real?

RFC 5322 is primarily about format, not proving whether the mailbox is live.

So, strictly speaking, the standard does not guarantee that:

• the mailbox exists
• the domain accepts replies
• the sender is authorised to use that address

That gap is one reason modern email relies on additional controls such as:

• SPF
• DKIM
• DMARC

These do not “prove the mailbox exists”, but they do help prove that the sending system is authorised to use the relevant domain.

From: versus envelope sender

These addresses often differ legitimately.

Common examples:

• A mailing list sends with:
• From: showing the original author or list identity
• envelope sender pointing to the list’s bounce processor
• A transactional platform sends:
• From: as a customer-facing address
• envelope sender as a dedicated bounce-handling mailbox
• A user sends “on behalf of” another identity:
• From: shows the author
• Sender: may identify the actual transmitting party

This is normal provided the arrangement is properly authenticated and authorised.

Mandatory reserved addresses

The one address that matters most here is:

postmaster@yourdomain

RFC 5321 requires any domain that accepts email to support postmaster as a mailbox name, case-insensitively.

This exists so there is always a recognised contact point for:

• mail system problems
• delivery issues
• abuse or administrative queries related to mail handling

In practice, every mail-enabled domain should ensure that:

• postmaster@domain is deliverable
• it is monitored by a responsible person or team

Why accepting or generating mail from a non-existent mailbox is a bad idea

This depends on whether the issue is on the sending side or the receiving side, but the risks are consistent.

1. It makes spoofing easier

A non-existent sender address is a classic sign of:

• phishing
• malware delivery
• forged email
• bulk spam

If a system allows arbitrary fake sender addresses, attackers gain:

• anonymity
• no accountability
• a lower chance of replies exposing the fraud

2. Replies and failures go nowhere

If the sender mailbox does not exist:

• recipients cannot reply meaningfully
• delivery failures cannot be returned properly
• automated processes break
• support and audit trails become harder to follow

For legitimate business email, this is poor operational practice.

3. It causes backscatter problems

If a server accepts a message and later discovers it cannot be delivered, it may generate a bounce.

If the original sender was forged or non-existent, that bounce may go to:

• an innocent third party
• nowhere useful
• another forged address

This creates backscatter: unwanted bounce traffic generated by accepting mail that should have been rejected earlier.

Best practice is to reject invalid mail during the SMTP transaction where possible, rather than accept first and bounce later.

4. It harms deliverability and trust

Messages using bogus sender identities are more likely to:

• fail reputation checks
• trigger anti-spam scoring
• be quarantined
• be rejected outright

Even if a message is technically accepted, it is less likely to be trusted by modern filtering platforms such as Microsoft 365, Google Workspace, and advanced email security gateways.

5. It breaks alignment with modern email authentication

Modern protection expects some level of consistency between:

• the sending server
• the envelope sender domain
• the visible From: domain
• DKIM signing domain
• DMARC policy

A fabricated or non-existent sender identity often means:

• SPF cannot authorise properly
• DKIM alignment is absent or inconsistent
• DMARC fails or is treated suspiciously

6. It creates audit and compliance issues

For business systems, every outbound message should be attributable to:

• a real user
• a real application
• an authorised shared mailbox
• a defined service identity

Using non-existent senders makes incident investigation, legal disclosure, and abuse handling significantly more difficult.

Best practice

For receiving mail from the Internet

Reject clearly invalid sender domains at SMTP time

A sensible receiving policy is to reject mail when:

• the MAIL FROM domain is syntactically invalid
• the domain does not exist in DNS
• the sender is spoofing one of your own domains without authorisation

This helps stop abuse before the message is accepted.

Accept the null sender when appropriate

Do not reject mail solely because the envelope sender is:

<>

That is required for legitimate bounces and delivery status notifications.

It should still be scanned for spam and abuse, but it is not inherently invalid.

Do not rely on remote mailbox verification

Trying to prove that a sender mailbox exists by querying the remote system is generally poor practice because it can:

• cause delays
• fail against servers that disable recipient verification
• look abusive to remote systems
• create privacy and information leakage issues
• produce false results

For inbound Internet mail, focus on:

• syntax checks
• DNS validity
• SPF
• DKIM
• DMARC
• reputation
• content and behavioural analysis

Reject during SMTP rather than bounce later

If a message is clearly unacceptable, reject it before final acceptance. This avoids generating backscatter and is the cleaner operational model.

For sending mail from your own systems

Only send from real, authorised identities

Users and applications should send mail only as:

• an existing mailbox
• an existing alias
• a shared mailbox
• a service address explicitly authorised by policy

Do not allow authenticated users or devices to submit mail with arbitrary fake sender addresses.

Use a controlled bounce address

For automated or bulk email, it is normal to use a dedicated envelope sender for bounce handling, but it should still be:

• real
• routable
• monitored or processed
• under your control

A valid example pattern would be a dedicated bounce mailbox such as:

bounces@mailer.example.co.uk

or a tokenised return path used by a mailing platform.

Keep From: addresses honest

The visible From: address should represent a real and expected identity. It does not always have to be a human mailbox, but it should be:

• legitimate
• recognisable
• reply-safe, or paired with an appropriate Reply-To: address
• authorised for the sending service

Using fake or abandoned addresses damages trust and deliverability.

Publish and maintain authentication records

Domains used for email should have properly configured:

• SPF
• DKIM
• DMARC

These controls help receivers decide whether the sending system is genuinely allowed to use the sender domain.

Ensure postmaster@domain works

Every mail-enabled domain should accept mail for:

postmaster@domain

This is both standards-compliant and operationally sensible.

Practical summary

• RFC 5321 governs the SMTP envelope, including MAIL FROM
• RFC 5322 governs message headers, including From:
• The envelope sender is used for transport and delivery failures
• The visible From: header is what the recipient sees
• The null sender:

<>

is valid and required for bounces

• postmaster@domain must exist for mail-enabled domains
• A sender address can be syntactically valid without representing a real mailbox
• In practice, modern mail systems strongly prefer sender domains that are real, routable, authenticated, and authorised
• Accepting or generating mail from non-existent sender identities increases spoofing, backscatter, operational failure, and spam risk

Recommended policy

A sound modern policy is:

• reject invalid or non-existent sender domains
• allow the null sender for legitimate system messages
• do not depend on remote mailbox existence checks
• require outbound mail to use real, authorised sender identities
• authenticate domains with SPF, DKIM, and DMARC
• reject bad mail during SMTP rather than accepting and bouncing later

That approach is both standards-aware and aligned with current anti-spam and anti-phishing best practice.