What 550 5.7.9 Means
Per RFC 5322 (and earlier RFC 2822), email messages must have certain required headers (From, Date) and follow a strict format for header field names and values. 550 5.7.9 means the receiver parsed your message, found a structural violation, and rejected on policy grounds — your mail server is producing malformed mail and the receiver won't pass it through.
Strictly-configured receivers, including some enterprise gateways running ProofPoint and Mimecast. Gmail and Microsoft 365 are more permissive of borderline messages but still reject the most egregious violations.
Missing Date header (required); missing Message-ID header (technically optional but most receivers require it); 8-bit characters in headers without proper encoding; line lengths exceeding 998 characters; CR/LF line endings inconsistent; duplicated headers that should be unique (multiple From, Date, Message-ID); or invalid date format that fails RFC 5322 parsing.
How to Fix 550 5.7.9
- 1
Capture a copy of the malformed message
View the raw source of the message you tried to send. Most cold email tools let you export the raw message before send. Save the full text including all headers — that's what you'll diagnose.
- 2
Verify required headers are present and unique
RFC 5322 requires: From (exactly one), Date (exactly one), and either To/Cc/Bcc. Strongly recommended: Message-ID (exactly one), Subject. Check that each required header appears exactly once with valid content.
- 3
Verify header encoding
Header values containing 8-bit characters (non-ASCII letters, accents, emoji) must be encoded per RFC 2047 (typically =?UTF-8?B?...?= encoding). If your subject contains 'é' or '€' literally without RFC 2047 encoding, strict receivers reject. Most sending platforms encode automatically; manual scripts often don't.
- 4
Check line endings and length
Per RFC 5322 §2.1.1, lines must be at most 998 characters, terminated by CRLF (not LF alone or CR alone). Lines longer than 998 violate. Inconsistent line endings (some LF, some CRLF) violate. If your sending pipeline transforms text, verify it produces CRLF consistently.
- 5
Validate the Date header format
RFC 5322 §3.3 specifies an exact date format (e.g. 'Mon, 23 May 2026 12:00:00 -0700'). Custom date formats fail. If your mail server is generating dates manually, switch to a library that produces RFC 5322 dates. Most modern SMTP libraries get this right.
- 6
Use a managed sending platform if you're hand-rolling SMTP
Hand-rolled SMTP is the most common source of RFC compliance failures. If you're using ColdRelay or a major cold email platform, RFC compliance is handled for you. If you're writing your own SMTP client in scripts or low-level libraries, you're going to keep tripping on these edge cases.
References
550 5.7.9 in the Cold Email Context
RFC compliance failures are uncommon when sending through a professional cold email platform — the platform's outbound layer enforces RFC 5322 structure on every message. The risk shows up when teams build custom outbound integrations: a Python script using smtplib without proper header encoding, a Zapier-glued workflow that constructs messages by string concatenation, or a CRM that sends mail through a misconfigured SMTP library. ColdRelay's outbound layer validates every message against RFC 5322 before transmission and surfaces compliance issues in the dashboard's Sends log — you see exactly which header field tripped the validator, not just a generic 'rejected' message.
Frequently Asked Questions
Is 5.7.9 always RFC compliance?
5.7.x is a broad authentication-and-policy category. The specific 5.7.9 enhanced code is used by some receivers for 'message format violation' but others use it for 'recipient address misuse'. The descriptive text after the code tells you which one. RFC compliance is the most common cold email cause.
Will Gmail reject borderline RFC violations?
Gmail is more lenient than enterprise gateways. Minor violations (slight date format quirks, inconsistent line endings) usually pass at Gmail. Egregious violations (missing From, duplicate Message-ID) get rejected even by Gmail.
What's the difference between RFC 2822 and RFC 5322?
RFC 5322 supersedes RFC 2822 (which itself superseded RFC 822). The format is largely backward-compatible. Modern receivers enforce RFC 5322. The older RFC numbers are still referenced in error messages because the original implementations predated the newer RFCs.
How do I check my outbound messages for RFC compliance?
Send a test to a service like mail-tester.com or open the raw message in a tool that validates headers. The validator flags any structural violation. Most cold email platforms also expose a 'view source' option for sent messages so you can spot-check.