Gmail 550 5.7.1 'Not RFC 5322 Compliant': Fixing Duplicate Headers, Missing Message-ID and Bad From Lines

When Gmail answers with 550 5.7.1 and the words "not RFC 5322 compliant", or a line about a missing Message-ID or a bad From header, it is rejecting the message format, not you or your recipient. Something in the headers breaks the Internet Message Format standard: a header appears twice, a required one is missing, or a value is malformed. It is permanent, and it repeats for every Gmail and Google Workspace address until the way the message is built is fixed. The good news is that it is deterministic. Find the broken header once and the error is gone.

The format errors Google lists

Google's Gmail SMTP errors and codes page (last updated 26 October 2026, read 2 November 2026) has a group of 550 5.7.1 messages about headers:

What the error says	What is wrong
"...not RFC 5322 compliant because it has duplicate headers."	A header appears more than once when it may appear only once
"...not RFC 5322 compliant because it has multiple From: headers."	Two From lines
The From: header is missing	No From line at all
Messages with no valid address in From are not accepted	From has a name but no address, or a broken address
Messages with multiple addresses in From are not accepted	From: a@x.com, b@x.com
The From: header has a non-compliant domain name	The domain in From is not a valid host name
"Messages missing a valid Message-ID: header are not accepted."	No Message-ID, or one with the wrong shape
Unicode characters in a header that doesn't allow them; encoded-word syntax where it isn't allowed; malformed headers	Header values that are not encoded the way the standards require

Google's sender guidelines (read 2 November 2026) state the same rules as requirements for all senders: "Format messages according to the Internet Message Format standard, RFC 5322", "Make sure every message includes a valid Message-ID", and "From: headers should include only one email address."

Not sure which variant you have? Paste the bounce into the bounce message analyzer.

The RFC 5322 header counts

RFC 5322 section 3.6 has a table of how many times each header may appear. These are the ones that cause rejections:

Header	Minimum	Maximum
Date	1	1
From	1	1
Sender	0	1
Reply-To	0	1
To	0	1
Cc	0	1
Bcc	0	1
Message-ID	0 (should be present)	1
In-Reply-To	0	1
References	0	1
Subject	0	1

Note that "To: 0 to 1" means one To header, which can hold many addresses separated by commas. Two separate To: lines are a duplicate header. RFC 5322 makes Message-ID a "should", but Gmail enforces it as a must.

Headers that may repeat, such as Received, Comments and Keywords, are not the problem. Gmail is counting the single-use ones.

Where broken messages come from

Mainstream mail software builds headers correctly. This error almost always comes from code or templates that build headers by hand.

Source	What typically goes wrong
A script that writes raw headers into a string	Adds From: or Subject: and then the library adds its own
Custom SMTP code	No Message-ID or no Date, because nothing generated them
A CRM or mail-merge template with a "custom headers" field	Someone typed To: or Reply-To: there, duplicating the real one
A relay or gateway that rewrites headers	Adds a second From or Date instead of replacing it
Several people on one From line	From: Sales Team <a@x.com>, b@x.com
Non-English names or subjects	Accented or non-Latin text put straight into a header with no encoding
A From address typed into a form	Invalid domain, trailing dot, or no @

Cold email platforms and ESPs build their own headers, so their users rarely see this. If you do see it through one, check any "custom header" settings in the campaign or the template first.

How to find the broken header

1. Get the raw message

Send the same message, through the same tool, to an address you control on a provider that accepts it. Outlook.com or a Yahoo address often accept what Gmail refuses. Open the raw source (in Outlook on the web, "View message source"; in Yahoo, "View raw message") and save it as a .eml file.

2. Count the single-use headers

Look at the block of lines before the first blank line. Search for From:, To:, Subject:, Date: and Message-ID: at the start of a line and count each one. Two of anything in the table above is your problem. Watch for case: subject: and Subject: are the same header.

The email header analyzer lists every header in order, and the EML viewer opens the saved file in the browser.

3. Check the From line

It should hold one address, with an optional display name: Jane Doe <jane@example.com>. If the display name contains a comma or other special characters, it needs quotes: "Doe, Jane" <jane@example.com>. Without the quotes, a comma in the name can make the header look like two addresses.

4. Check Message-ID

It should look like <unique-part@your-domain>, angle brackets included, and be unique for each message. A blank Message-ID: line or one without brackets is "not valid".

5. Check encoding of non-ASCII text

Names and subjects with accents or non-Latin scripts must be encoded as MIME encoded-words, for example =?UTF-8?B?...?=, or sent over a connection where both sides support internationalised mail. Libraries do this for you if you pass the text to their header functions instead of writing the header string yourself.

Fixes in code

Let the library build the headers. Two common examples:

Python. Use email.message.EmailMessage, set each header once, and add a Message-ID with email.utils.make_msgid() and a Date with email.utils.formatdate(localtime=True). With the older email.message.Message class, assigning msg["Subject"] twice silently adds a second header. EmailMessage with the default policy raises an error instead, which is what you want. To change a header, use del msg["Subject"] first or msg.replace_header().

Node.js. Nodemailer generates Message-ID and Date for you. Pass the sender in from and extra people in cc or replyTo. Don't copy those same values into the headers option.

For any language: build one message object per recipient, set each single-use header once, and send a test to Gmail before you send to a list.

Why it matters beyond Gmail

Yahoo's SMTP error page (read 2 November 2026) lists the same family: "Duplicate headers", "Incorrectly formatted headers" and "Incorrect mime types". Yahoo also rejects for a header that is too big and a Date outside its accepted range. A message that passes Gmail's format checks will usually pass Yahoo's too. Both providers include message format in their bulk sender requirements.

How it compares to other 550 5.7.1 errors

Gmail uses 550 5.7.1 for many different problems. The text after the code tells them apart:

Text contains	Problem	Guide
"not RFC 5322 compliant", "Message-ID", "From: header"	Message format	This page
"likely unsolicited email"	Content or sending pattern judged as spam	Gmail 550 5.7.1 variants
"very low reputation"	IP or domain reputation	Gmail low reputation
"not authorized to send email directly"	Sending from an end-user IP	Gmail direct-send block

The full list of Gmail codes is in our Gmail bounce codes reference.

Where SimpleVerifier fits

A format error is a message problem, and no verifier fixes it. Once the message is fixed, the next question is whether each address will accept it. SimpleVerifier runs a live mailbox check on each address and returns safe to send, send with care, check again later or do not send, with the reason. Catch-alls stay risky, never guessed valid. If you send from your own code, the API checks an address in one call before you send.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off, and includes 10,000 API calls a month. See pricing.