Gmail: Weird RFC 5322 bounces and what to do about them

Here is the scenario. Maybe you've just gotten a bounce message that looks like this:

Aug 25 11:20:24 s1 postfix/smtp[26906]: 98299221BB: to=<x@gmail.com>, relay=gmail-smtp-in.l.google.com[]:25, delay=1.2, delays=0.04/0.77/0.2/0.21, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[] said: 550-5.7.1 [] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant: duplicate headers. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please review 550 5.7.1  RFC 5322 specifications for more information. j6-20020a637a46000000b0042b3a763e76si3563504pgn.127 - gsmtp (in reply to end of DATA command))

Or perhaps it looks like this:

Aug 25 12:48:59 s1 postfix/smtp[14180]: C90492056B: to=<x@gmail.com>, relay=aspmx.l.google.com[]:25, delay=0.69, delays=0.08/0/0.39/0.22, dsn=5.7.1, status=bounced (host aspmx.l.google.com[] said: 550-5.7.1 [] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant: 550-5.7.1 Multiple 'From' headers found. 550-5.7.1 To reduce the amount of spam sent to Gmail, this message has been 550-5.7.1 blocked. Please visit 550-5.7.1  https://support.google.com/mail/?p=RfcMessageNonCompliant 550 5.7.1  and review RFC 5322 specifications for more information. y6-20020a17090a86c600b001fb71e2d709si4076772pjv.83 - gsmtp (in reply to end of DATA command))

Has this happened to you? It has happened to me, and it turns out that the best guidance on what was wrong was helpfully included right in the email bounce message: Gmail warned of "duplicate headers." In my case, it was custom mailing list software that accidentally generated a second Message-ID header, but it will  happen with other headers, too -- and the bounce message might vary. In the second example above, Gmail specifically calls out the extra "From" header. In my testing, I see that Gmail will reject messages that have a duplicate Subject, From or Message-ID header. They don't seem to care about duplicated Date, To or Reply-To headers, at least so far. (But it wouldn't surprise me if they decided to scrutinize based on duplication of these headers in the future.)

Why does this even matter? Bad guys trying to send bad stuff are always looking for new things to exploit; and adding secondary or duplicate headers is one way they could potentially sneak messages past spam filters, sometimes with DKIM encryption undisturbed, depending on how the email authentication configuration was set for a given sending platform's mail server. This helps to stop that sort of thing. (If you want to read more about that, you'll want to look up DKIM replay attacks and they're not new; here's Steve Atkins from Word to the Wise blogging about them in 2014. I guess it took a few years for the problem to grow large enough to result in Gmail blocking.)

This blocking should not hurt good senders; these messages are clearly in violation of specifications (RFC 5322, in this case) that say that you can only have one of each of these headers. Follow the specs and you'll be fine; it's easy to comply, and not meant to be a punishment. If you run into this bounce, fix the headers, and the bounce will stop happening.

And the warning about this kind of thing is not really that new; or at least it shouldn't be surprising. Way back in 2015, Brian Godiksen from SocketLabs was warning us that sending messages that fail to comply with the specifications in RFC 5322 and RFC 5321 was a bad idea and could come back to bite you in the rear at some point. And quite prescient he was about that.


Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.

  1. I have seen a similar issue at a client, investigated the headers (also validated using mxtoolbox, but that test doesnt even see duplicate froms). The only possible isue i see are multiple To lines, but that sould be OK right?

    1. Well, I tested again just now, and multiple TO: fields don't seem to make Gmail reject a message.

  2. In my personal forward-to-gmail script I had to change the following:
    First I will not forward "Message-ID:" headers that have Header and ID on 2 different lines of communication, separated by CR/LF - the ones in question are all coming from some sort of ...outlook.com domain. Verified for 3 senders, now it's working.
    Next I also remove all but one "Received:" headers - not sure if this does help, but anyway...
    HTH, Mart

Previous Post Next Post