Troubleshooting email rejected for RFC 5322 formatting issues that look like authentication failures

Sometimes a message gets rejected, deferred, or heavily spam-foldered and the first assumption is "SPF broke" or "DMARC is failing again."

That assumption is often wrong.

Large receivers increasingly treat message formatting defects as sender-trust problems because badly formed mail is common in abusive traffic, broken bulk tooling, and spoofing attempts. So the visible symptom can feel like an authentication issue even when SPF, DKIM, and DMARC are technically fine.

Google's Email sender guidelines make this explicit: messages must be formatted according to RFC 5322, include a valid Message-ID, avoid duplicate single-instance headers, and use only one address in From: for Gmail delivery.

Why formatting problems get mistaken for auth failures

Receivers do not evaluate sender trust in isolated boxes.

They look at the whole message shape:

• envelope sender and SMTP path
• From: identity
• SPF, DKIM, and DMARC results
• header structure and syntax
• whether the message looks machine-generated in a sane, standards-conforming way

If the headers are malformed, the message can look suspicious even when the cryptographic and DNS pieces pass.

That is why teams sometimes see this pattern:

1. SPF passes.
2. DKIM passes.
3. DMARC aligns.
4. The message still gets blocked or treated like risky mail.

At that point the next question should not be "how do we force DMARC to pass harder?"

It should be "what does the raw message actually look like?"

The important distinction: RFC 5322 correctness vs authentication correctness

Authentication answers who is allowed to send and whether a domain-aligned signature or SPF identity is present.

RFC 5322 answers whether the message itself is structurally well formed.

Those are different layers.

A receiver can absolutely decide:

• the message authenticated successfully
• the message is still malformed enough to distrust or reject

That is not contradictory. It is normal receiver behavior.

If alignment is the confusing part, DMARC identifier alignment deep dive and Return-Path vs From: practical implications cover the auth side in more detail. This post is about the separate formatting layer that often gets overlooked.

The formatting mistakes that most often masquerade as auth trouble

Duplicate single-instance headers

This is one of the biggest ones.

Google explicitly says single-instance headers should appear only once. That includes common fields such as:

• From:
• To:
• Subject:
• Date:

RFC 5322 also defines the message model in a way that expects only one From: field and one origination Date: field.

What this looks like in practice:

• an application sets Subject:
• a downstream library adds another Subject:
• a template system inserts its own From:
• a relay stamps a malformed resend workflow into normal headers instead of proper resent headers

The receiving side may then treat the message as ambiguous or deceptive, even if DKIM still verifies.

Multiple addresses in From:

This is a subtle one because bare RFC 5322 allows a single From: field to contain more than one mailbox, as long as Sender: is used when required.

Operationally, however, Gmail's sender guidance is stricter: From: should include only one email address.

So a message can be legal enough for some parsers, yet still trigger deliverability problems at major receivers.

If a product or marketing platform is building From: values dynamically, inspect the final raw header, not just the app configuration screen.

Missing or invalid Message-ID

Google specifically calls out the need for a valid Message-ID.

This tends to break in homegrown mailers, old appliances, and systems that assemble messages manually. A missing or malformed Message-ID does not directly break DMARC, but it absolutely makes the message look less trustworthy and less standards-conforming.

Malformed From: syntax

Common examples:

• unbalanced quotes
• bad angle-bracket usage
• comments or display-name text inserted incorrectly
• illegal characters in the address form
• broken encoding around non-ASCII display names

When this happens, different receivers can parse the same header differently. That can create symptoms that look like identity mismatch even when the intended domain is obvious to the sender.

Broken header folding or overlong lines

RFC 5322 allows header folding, but only in specific ways. It also imposes a hard line-length limit of 998 characters excluding CRLF, with a much shorter recommended display-friendly limit.

Problems appear when software:

• inserts raw newlines incorrectly
• folds in the middle of syntax that a parser handles badly
• generates extremely long header lines after tracking parameters or personalization are added

Malformed folding can make the next header look like part of the previous one, or make the field parse differently than intended.

Resent fields used incorrectly

Some systems try to represent forwarding or "send on behalf of" behavior by injecting extra normal originator headers instead of using proper resent fields or a sane single originator model.

That often produces duplicate From: or Date: fields, which then gets interpreted as suspicious message construction.

The easiest way to tell whether this is auth or formatting

Start with the delivered sample or the rejected raw message and separate the evidence into two buckets.

Bucket 1: authentication evidence

Check:

• Authentication-Results
• DKIM verification result
• SPF result
• DMARC alignment result

If those all pass, do not stop there. Passing auth does not clear the message structurally.

For a refresher on reading those headers, DMARC troubleshooting with real headers is the right companion post.

Bucket 2: message-format evidence

Check the raw header block for:

• duplicate From:, Date:, Subject:, or To:
• more than one mailbox in From:
• missing or malformed Message-ID
• broken quoting or bracket syntax
• strange line wrapping or partial headers
• generated headers that appear twice because multiple systems added them

This second bucket is where teams often find the real fault.

A practical troubleshooting workflow

1. Capture the exact raw message that was rejected or delivered badly

Do not debug from screenshots, ESP UI summaries, or copied header fragments.

You need the raw source because header folding, duplicate fields, and malformed address syntax are easy to miss once a tool "normalizes" the display.

2. Confirm whether auth truly passed on that same sample

Look at the actual message instance, not a different test email.

It is very common for one stream to authenticate cleanly while another stream from the same product has a formatting bug or different header-generation path.

3. Count single-instance headers manually

Do not assume your mail library prevented duplicates.

Specifically count these in the raw source:

• From:
• Date:
• Subject:
• To:
• Message-ID:

If you see two copies of something that should be singular, that is already a strong suspect.

4. Inspect the final From: field exactly as sent

Verify all of this:

1. only one From: field exists
2. it contains one mailbox only
3. the mailbox syntax is valid
4. the visible domain is the domain you intended recipients to see

If the visible domain is also relevant to DMARC, verify the aligned auth domain matches that same identity story.

5. Validate Message-ID generation

Make sure every message gets one, and only one, properly formed Message-ID.

If different layers can each generate one, decide which layer owns it and remove the duplicate behavior.

6. Look for header mutations between your app and the final sending edge

This is a common root cause.

The application might build a clean message, but then:

• middleware rewrites the sender
• a plugin adds a second reply or subject field
• an ESP connector inserts its own header set
• a forwarding or resend feature duplicates originator fields

If possible, compare:

1. the message right before handoff from the app
2. the message as accepted by the outbound MTA or provider
3. the message as seen by the receiving side

7. Re-test with the smallest possible message

When the cause is unclear, send a minimal sample:

• plain text body
• one recipient
• simple subject
• single clean From:
• normal Date:
• valid Message-ID
• no custom headers unless required

If that delivers while the production variant fails, add complexity back one layer at a time.

That is usually much faster than guessing.

Common root causes behind these bad headers

• custom code constructing MIME or headers manually
• multiple libraries each trying to be the source of truth for originator fields
• merge tags or personalization inserting unsafe characters into display names
• ESP integrations that prepend headers while the app already set them
• "send as" or delegated sending workflows bolted onto tools that were not designed for them
• old appliances or CRM systems generating non-standard mail

In other words, the problem is often not DNS at all. It is message assembly.

What to fix first when the symptoms look like DMARC but are not

Prioritize fixes in this order:

1. eliminate duplicate single-instance headers
2. reduce From: to one valid mailbox
3. guarantee one valid Message-ID
4. stop manual header construction where a mature library can do it correctly
5. identify the one system in the path that owns sender/header generation

Only after that should you revisit SPF, DKIM, or DMARC assumptions.

Otherwise it is easy to burn hours "fixing" authentication that was never the real blocker.

Why receivers treat malformed mail as a trust problem

This is the part that frustrates operators, but it makes sense.

Malformed mail is disproportionately associated with:

• bad bulk tooling
• spoofed campaigns
• rushed phishing kits
• broken automation pipelines

So even when a receiver can technically parse the message, malformed structure is still a strong negative quality signal.

Microsoft and Google both evaluate more than raw pass/fail auth bits when deciding how trustworthy a message is. Microsoft's Email authentication guidance describes implicit and composite authentication, which is a useful reminder that a message can clear SPF or DKIM and still be treated like risky sender behavior.

Bottom line

If a rejection or spam-placement event looks like authentication trouble but the auth results are clean, inspect the message as a formatting problem next.

Check for duplicate headers, invalid From: construction, missing Message-ID, and broken header folding before changing DNS.

In many real incidents, the message was not being rejected because the domain failed to authenticate. It was being rejected because the message looked malformed enough to behave like suspicious mail.