Help ensure your emails
hit the inbox
Stop guessing why your messages end up in spam. Follow this 28-point checklist to achieve technical compliance, enhanced sender reputation, and delivery success.
Content
Message Formatting / MIME
TL;DR
- Invalid headers, MIME structure, encoding, or line endings can cause filtering and rejection.
- Generate standards-compliant plain-text and HTML parts, then inspect the received message.
Every outbound message must be constructed as a valid Internet email message, not merely look correct in a browser or template editor. Malformed headers, incorrect line endings, invalid MIME boundaries, or unsafe transfer encoding can cause messages to be altered, deferred, rejected, or filtered even when the visible content appears normal.
Messages should comply with RFC 5322 and use CRLF line endings. No generated line may exceed 998 characters excluding CRLF, and lines should normally remain within 78 characters where practical. Long header fields must be folded only at valid syntax boundaries. Each message should include valid Date and From fields and a globally unique Message-ID, together with an accurate Subject and recipient fields.
HTML email should normally be sent as multipart/alternative with equivalent text/plain and text/html parts. The plain-text version should appear first and the richer HTML version second. Each part must declare an appropriate Content-Type and charset, normally UTF-8, and use a valid Content-Transfer-Encoding such as quoted-printable or Base64 when required.
Technical construction checks should include:
Messages should be generated by a mature email library or reputable ESP rather than assembled through ad hoc string concatenation. The complete message should then be sent through the normal production path to test accounts and AuthEmailTest.com, because inspecting the received message reveals transformations and defects that are not visible in a template preview.
By validating raw message structure as well as visible presentation, organizations improve compatibility across mail systems, protect authentication integrity, and reduce avoidable delivery failures.
Messages should comply with RFC 5322 and use CRLF line endings. No generated line may exceed 998 characters excluding CRLF, and lines should normally remain within 78 characters where practical. Long header fields must be folded only at valid syntax boundaries. Each message should include valid Date and From fields and a globally unique Message-ID, together with an accurate Subject and recipient fields.
HTML email should normally be sent as multipart/alternative with equivalent text/plain and text/html parts. The plain-text version should appear first and the richer HTML version second. Each part must declare an appropriate Content-Type and charset, normally UTF-8, and use a valid Content-Transfer-Encoding such as quoted-printable or Base64 when required.
Technical construction checks should include:
- MIME-Version and accurate Content-Type headers
- Correct charset and transfer-encoding declarations
- Unique, properly opened and closed multipart boundaries
- Equivalent plain-text and HTML alternatives in the correct order
- Quoted-printable and Base64 output wrapped to no more than 76 characters per encoded line
- Accurate MIME types, filenames, and encoding for attachments
- A blank CRLF line separating the header section from the body
- No bare carriage returns, invalid control characters, or malformed header folding
Messages should be generated by a mature email library or reputable ESP rather than assembled through ad hoc string concatenation. The complete message should then be sent through the normal production path to test accounts and AuthEmailTest.com, because inspecting the received message reveals transformations and defects that are not visible in a template preview.
By validating raw message structure as well as visible presentation, organizations improve compatibility across mail systems, protect authentication integrity, and reduce avoidable delivery failures.