Why does Gmail bounce this when Outlook accepts the same message?

Because they enforce RFC 5322 differently. The message has a formatting defect — a duplicated single-instance header is the usual one — and Microsoft's receivers happen to be lenient about it while Gmail rejects it outright. That split is actually the most useful clue you'll get: it tells you the problem is in how your message is *built*, not in your SPF, DKIM, DMARC, or IP reputation. 'Works to Outlook, bounces at Gmail' is a sender-side formatting bug almost every time, and the fix is to the message generator, not your DNS.

My SPF, DKIM, and DMARC all pass. How can it still be rejected?

Because 550 5.7.1 'not RFC 5322 compliant' is about message *structure*, not authentication — a different layer entirely. Authentication asks 'is this sender allowed to use this domain.' RFC 5322 compliance asks 'is this a well-formed email at all.' You can have flawless auth and still emit a message with two From headers or two Message-IDs, and Gmail will reject the structure before your perfect SPF record ever matters. Don't go re-checking DNS; go read the raw headers.

What exactly is malformed? The message looks fine in my client.

Your client renders the message; it doesn't show you the raw header block, which is where the defect lives. The dominant cause is a single-instance header appearing twice — two Date lines, two From lines, two Message-ID lines, or multiple Subject headers — because one component (your app) set the header and another (the mail library or relay) added its own copy. Less often it's a missing Message-ID, broken address syntax, bad line folding, or stray non-ASCII in a header. You have to look at the raw source to see it; the pretty view hides exactly the part that's wrong.

550 5.7.1 This Message Is Not RFC 5322 Compliant

Problem

A message bounces with 550-5.7.1 ... This message is not RFC 5322 compliant, and it’s almost always a message your own system sent — a transactional email, an alert from a monitoring tool, a notification from an app you wrote or configured. The maddening part is that the same message often sails into Outlook and other inboxes without complaint, so it feels like Gmail is being difficult. It isn’t. The message really is malformed; most receivers just forgive it, and Gmail doesn’t.

This is a structural problem, not a reputation or authentication one, and that distinction is the whole key to fixing it fast.

Symptoms

The bounce text contains the literal phrase This message is not RFC 5322 compliant, usually under enhanced status code 5.7.1, often with a Google help pointer appended.
It’s reproducible for a specific kind of message (everything from one app, one script, one alerting integration) — not random.
The same message is accepted by Microsoft 365 / Outlook.com and other providers, which makes it look like a Gmail-specific glitch.
Your SPF, DKIM, and DMARC checks all pass, so the usual deliverability advice gets you nowhere.

What 550 5.7.1 “Not RFC 5322 Compliant” Actually Means

RFC 5322 is the Internet Message Format — the spec for how an email is structured: which header fields exist, how addresses are written, how long lines fold, and the blank line that separates headers from the body. Section 3.6 is strict about one thing in particular: a message must have exactly one Date field and at least one From field, and the headers that are defined as single-instance — From, Date, Subject, Message-ID, among others — must appear at most once. Two of any of them is a violation.

Gmail enforces this. Google’s bulk-sender requirements, in force since February 1, 2024, explicitly say to format messages per RFC 5322 and to include a valid Message-ID — and Google maintains a dedicated troubleshooting page specifically for duplicate-header RFC 5322 bounces, which tells you how common that one cause is. The enhanced status code here, 5.7.1, is shared with Gmail’s spam-policy rejections (“this message is likely unsolicited”), so read the text, not just the code — the words after the number are what tell you this is a format problem, not a reputation one.

Top 3 Causes

A single-instance header appears twice (by far the most common). Your application sets a header — say Date or Message-ID — and then the mail library, framework, or relay stamps its own copy too, so the message goes out with two. Two From, two Date, two Subject, two Message-ID: any of these trips it. Hand-built MIME, misused SMTP libraries, and alerting integrations that prepend headers to an already-complete message are the usual culprits.
A required header is missing or address syntax is broken. No Date, no valid From, or an address that isn’t well-formed (missing angle brackets, a stray comma, an unquoted display name with special characters). Google additionally requires a valid Message-ID, so a message with none can be rejected even though RFC 5322 itself only recommends it.
Bad line folding or disallowed characters in a header. A header line that’s too long and folded incorrectly, raw non-ASCII where an encoded-word is required, or malformed =?utf-8?...?= encoding. These are rarer than duplicates but produce the same bounce.

Diagnose with DechoNet

Email Header Analyzer parses the raw message source and lays out the header block so you can see duplicated single-instance fields (two Date, two Message-ID) and malformed addresses directly — the defect is in the raw headers, which your mail client hides from you.
Email / Domain Check confirms your SPF, DKIM, and DMARC are actually fine, so you can rule authentication out and stop chasing DNS for a problem that lives in the message body’s framing.
DNS Lookup is a sanity check that the sending domain’s records (and the Message-ID domain, if you reference one) resolve — occasionally relevant when a generated header references a domain that doesn’t exist.

Resolution Checklist

Get the raw source of a bounced message (not the rendered view) and look at the header block.
Scan for any single-instance header appearing twice — From, Date, Subject, Message-ID. A duplicate is the most likely cause.
If you find a duplicate, identify which component is adding the second copy (your code vs. the mail library/relay) and have only one of them set it.
Confirm exactly one valid Date, at least one well-formed From, and a single valid Message-ID.
Check address syntax and header encoding (angle brackets, encoded-words for non-ASCII, correct line folding).
Re-send to a Gmail address and confirm acceptance — the fix is verified by delivery, not by the message looking fine in a client.

When to Escalate

If the duplicate header is being injected by a third-party sending service or appliance you don’t control, that’s a vendor ticket — give them the raw headers showing the doubled field, since the fix is in their pipeline.
If you’ve confirmed one clean copy of every single-instance header and it still bounces, pull a fresh raw sample and look for subtler violations (line folding, encoded-word syntax) rather than re-checking auth.
If the bounce text is actually the other 5.7.1 — “our system has detected that this message is likely unsolicited mail” — this is a different problem; see 550 5.7.1 SPF/Policy Bounce and the alignment-focused 550 5.7.26 Gmail unauthenticated.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.