Internet email is a structured message format. Mail clients and filters process the raw headers and MIME body, not just the design visible in an editor. Invalid boundaries, unsafe header values or incorrect transfer encoding can lead to altered, filtered or rejected messages.
Use plain-text and HTML alternatives
HTML email should normally be sent as multipart/alternative with an equivalent text/plain part first and a text/html part second. Each part needs an explicit charset—normally UTF-8—and an appropriate transfer encoding.
The plain-text part should be intentionally written, not produced by stripping every tag without regard to links, headings or spacing.
Keep the message structurally valid
- Use CRLF line endings throughout the transmitted message.
- Keep every generated line within the Internet Message Format limit of 998 characters, excluding CRLF.
- Fold long headers only at valid syntax boundaries.
- Include valid Date, From, Message-ID, Subject and recipient fields.
- Open and close every multipart boundary correctly.
- Wrap quoted-printable and Base64 output to valid encoded line lengths.
- Declare accurate MIME types and filenames for attachments and inline images.
Test the message that was actually received
Use a maintained email library rather than concatenating headers and bodies by hand. Then send through the same application, network and AuthSMTP account used in production. Inspecting the received source reveals transformations and defects that a browser preview cannot show.
For a focused structural check, send the result to AuthEmailTest.com and retain an example .eml file when troubleshooting.
Generate messages with a mature email library, include equivalent text and HTML parts, and inspect the received raw message through the normal sending path.
Verify that your mail library creates both alternatives, uses UTF-8 safely and produces standards-compliant line endings and transfer encoding.
