5.1.20 means the message’s From header listed more than one address and no Sender header was present. RFC 5322 allows multiple authors only when a single Sender identifies who actually transmitted the message; Exchange Online rejects messages that break that rule.
Most common causes
- Application code generated more than one mailbox in From
- A library combined author identities without adding Sender
- Template or MIME construction produced an invalid originator header set
What to verify next
- Inspect the raw From and Sender headers
- Change the application to emit one From address when multiple authors are unnecessary
- If multiple From addresses are intentional, provide the required Sender identity
- Retest the generated raw message rather than only the rendered content
A message construction error
Nearly every case comes from application code or a library that assembled the From header from a list. Two addresses in From is unusual and almost never intended; when it is intended, the Sender header is mandatory. Mail clients do not produce this; generated mail does.
The rejection is about header syntax, not authentication. DNS, SPF and DKIM are not involved, and no receiver-side setting causes it.
Inspect the raw message
Look at the raw headers of the generated message, not the rendered view. Confirm what From contains and whether Sender exists. Email Header Forensics extracts the originator fields and reports the mismatch.
Then find the code path that builds the headers. Common patterns include concatenating a display name and address incorrectly, passing an array to a field that expects one address, or templating that duplicates the From line.
- Check the raw From and Sender headers.
- Multiple authors require a single Sender.
- Fix the generating application, not DNS.
Fix and verify
Emit one address in From. If multiple authors are genuinely required, add a Sender header naming the mailbox responsible for transmission. Rebuild a test message and inspect it raw before releasing the change.
Because DMARC evaluates the From domain, keep From to a single address on your domain so alignment remains straightforward.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Header Forensics
Inspect From, Sender, Reply-To, Return-Path and transport evidence in the raw message.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Some libraries hide header construction; the raw message is the only reliable evidence.
- Other receivers may accept the malformed header, which delays discovery.
Common questions
Is this an authentication failure?
No. It is a header-format violation. Authentication is not evaluated.
Why does Gmail accept the same message?
Receivers differ in strictness. Exchange Online enforces the RFC rule; others may tolerate it.
What should Sender contain?
A single mailbox that actually transmitted the message, typically the application’s own address on your domain.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.