How to format messages according to RFC 5322 for Gmail sender guidelines?
Published 8 Jul 2025
Updated 5 Oct 2026
14 min read
Summarize with
Updated on 5 Oct 2026: We clarified Gmail's header requirements and added MIME formatting checks for HTML and attachments.
Format each outbound message as a valid Internet Message Format message under RFC 5322, then follow Gmail's stricter practical rules for single-instance headers, valid Message-ID values, one-address From fields, readable sender identity, and non-misleading content. If you use a normal email service provider, the message builder and sending engine should handle most of this. If you build mail directly, inject custom headers, or transform messages before sending, you need to test the raw message.
Treat the Gmail sender guidelines as a receiver-side acceptance checklist, not a full engineering specification. RFC 5322 defines message content and headers. The SMTP envelope and transport rules sit outside its scope. Gmail adds practical rules that it enforces through delivery decisions and bounce responses.
RFC 5322 compliance rarely explains general poor inbox placement by itself. A malformed header can cause a hard rejection or a specific Gmail bounce, but broad deliverability problems usually come back to authentication, complaints, list quality, content, sending patterns, and domain or IP reputation.
RFC 5322 formatting requirements for Gmail
For Gmail sender guidelines, a correctly formatted RFC 5322 message needs a clean header section, a blank line, then the message body. Header field names use printable ASCII characters other than spaces or colons, followed by a colon. Header field bodies must not contain raw line breaks except where the field is folded correctly. Physical lines must end with CRLF, not LF alone.
- Include one valid Date field and one valid From field, the required fields under RFC 5322. Gmail additionally requires a valid Message-ID, which the RFC recommends.
- Single copies: Do not duplicate fields such as From, To, Date, Subject, or Message-ID.
- Line handling: Keep every physical line at most 998 characters excluding CRLF; aim for 78 characters where practical.
- Encoding: Encode display names and subjects only where needed. Do not encode the actual address local part or domain in a normal ASCII address.
- Gmail behavior: A malformed message can produce a rejection, while a compliant message can still land in spam if reputation or authentication is weak.
If you are not generating raw email, do not start by rewriting headers. Send a test message, inspect the raw source, and only escalate RFC 5322 problems when you see a specific bounce or malformed output. For a practical check, send a real message through the same production path and inspect it with the email tester.
What Gmail means by RFC 5322 formatting
Gmail is not asking every sender to memorize the whole RFC. It is asking senders to avoid malformed messages that break parsing, confuse identity, or look deceptive. The most common failures are duplicate headers, missing Message-ID values, incorrect line endings, oversized headers, huge physical lines, invalid dates, bad address syntax, invalid internationalized domains, and display-name tricks.
Flowchart showing the basic RFC 5322 message validation path.
RFC 5322 itself is about the Internet message format: header fields, dates, addresses, identifiers, folding, and message body separation. It does not define the SMTP envelope used to route the message. Gmail's published requirements add receiver expectations around sender identity and deliverability. For example, RFC 5322 permits multiple author addresses in one From field when a Sender field is present, but Gmail requires one From address.
|
|
|
|---|---|---|
From | One email address in one From field | Identity confusion |
Date | Valid timestamp | Parser rejection |
Message-ID | Unique identifier enclosed in angle brackets | Bounce risk |
Subject | One field | Duplicate error |
Lines | CRLF and limits | Malformed source |
Compact RFC 5322 checks that matter most for Gmail senders.
A compliant message skeleton
A simple production message should have this shape before MIME complexity, multipart boundaries, tracking headers, or unsubscribe headers are added. Replace the example addresses, timestamp, and Message-ID for each new message.
Simple RFC 5322 message skeletontext
From: "Example Brand" <news@example.com> To: subscriber@example.net Date: Mon, 25 May 2026 10:15:00 +1000 Subject: May account update Message-ID: <20260525.101500.abc123@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your account update is ready.
The blank line before the body matters. Everything above it is the header section. Everything after it is body content. The example uses visible line breaks for readability, but the serialized message must use CRLF. HTML tags such as <br> do not create raw RFC line endings. They only affect how HTML renders inside the message body.
Do not hand-edit production headers unless you own the sending pipeline. If your provider emits malformed raw email, give them the exact raw source and Gmail SMTP response. A mail transfer agent usually should not repair bad header structure after submission because that can break signatures, threading, and message interpretation.
Headers Gmail cares about most
Gmail calls out several header mistakes because they are easy to generate in custom systems and easy to miss in campaign previews. The preview can look fine while the raw source is invalid. Gmail's broader formatting rules also require valid HTML, visible sender information, content that is not hidden with HTML or CSS, and links whose destination is clear to recipients.
Good header behavior
- Identity: Use one email address in the From field for every message sent to Gmail.
- Timestamp: Generate the Date field when the message is ready to send. Include a numeric time-zone offset and ensure any weekday matches the date.
- Identifier: Use one globally unique Message-ID such as <unique-token@example.com>, with angle brackets and no spaces inside the identifier.
- Folding: Fold long header fields with CRLF followed by whitespace.
Bad header behavior
- Duplicates: Adding two Subject fields can trigger a Gmail rejection.
- Empty values: A blank Message-ID is not a valid identifier.
- Deception: Do not use fake Re: or Fwd: prefixes.
- Encoding: Do not encode addresses as display-name text.
Duplicate single-instance headers are the easiest issue to diagnose because the raw source shows them plainly. If Gmail is rejecting mail that another mailbox accepts, compare the raw message against RFC 5322 bounce errors and look for fields that appear twice.
Gmail also checks for duplicate Cc, Sender, Reply-To, Bcc, In-Reply-To, and References fields. Put multiple recipients in one comma-separated To or Cc field. Repeated Received trace fields are normal and must not be removed as duplicates.
Bad duplicate header exampletext
From: "Example Brand" <news@example.com> From: alerts@example.com To: subscriber@example.net Date: Mon, 25 May 2026 10:15:00 +1000 Subject: May account update Subject: Re: urgent notice Message-ID: <20260525.101500.abc123@example.com> This message has duplicate single-instance fields.
That message duplicates From and Subject, and the second subject pretends to be a reply. Gmail rejects duplicate single-instance fields and warns against misleading subjects. Use the exact SMTP error text to distinguish a formatting rejection from other 550 5.7.1 failures.
Line endings and line length
Line handling is where many custom senders fail. RFC 5322 messages use CRLF at the end of each physical line. A message assembled on a Unix system with only LF can look normal in logs but still be non-compliant at the Internet message layer.
RFC 5322 line length thresholds
Use these thresholds for raw message source lines, excluding CRLF.
Preferred
78 characters
Readable header and body lines where practical.
Maximum
998 characters
Hard limit before CRLF in generated messages.
Reject risk
999+ characters
Lines beyond the RFC limit can fail parsing.
Do not confuse HTML wrapping with raw message wrapping. A paragraph can wrap visually in Gmail while its source contains a long physical line. Inspect the final transfer-encoded message, because quoted-printable or base64 encoding changes the physical lines sent over SMTP.
A <br> tag is not a CRLF. Pressing return in an HTML editor also does not guarantee raw source wrapping after the message is serialized. The sending engine must serialize the final message with correct line endings and safe line lengths.
Header folding uses CRLF followed by a space or tab at a position allowed by that field's syntax. Fold between complete tokens, such as after a comma in a recipient list. Do not split a mailbox address, encoded word, or Message-ID internally. Use a maintained email library for this work.
Gmail message header size limits
RFC 5322 line limits and Gmail header-size limits are separate checks. A message can keep every physical line within 998 characters and still exceed Gmail's total header allowance after trace fields, authentication results, custom metadata, references, and routing hops accumulate. Gmail can reject these messages with a 552 5.3.4 response.
|
|
|
|---|---|---|
All headers | 500KB | Count the complete header section |
Header fields | 5,000 per message | Watch repeated trace and custom fields |
One header value | 32KB | To, Cc, and References are exempt, but count toward the total |
Message-ID value | 500 characters | Keep the identifier compact and unique |
Subject value | 998 characters | Count the full value after the colon, including folded lines |
Header field name | 1KB | Also obey the 998-character physical line limit |
Current Gmail limits for message headers.
When Gmail reports a header-size error, remove unnecessary custom fields, cap generated values, or move non-routing metadata into the body. Do not delete Received, Authentication-Results, ARC, or signature fields blindly. Capture the rejected raw message first so the team can identify which field or cumulative route caused the limit breach.
Encoding and address syntax
RFC 5322 is ASCII-oriented at the header syntax level. For messages without SMTPUTF8, RFC 2047 encoded words carry non-ASCII display names and subject text. RFC 6532 permits UTF-8 header values when the SMTP path supports SMTPUTF8; field names remain ASCII. For that UTF-8 format, the hard line limit is 998 octets rather than characters, excluding CRLF.
- Display names: Use RFC 2047 encoded words for non-ASCII names on an ASCII-header path. Quote ASCII display names containing punctuation, such as "Example, Inc.".
- Subjects: Use RFC 2047 encoded words for non-ASCII subject text on an ASCII-header path, with safe folding.
- Addresses: Never use RFC 2047 encoded words inside a mailbox local part or domain. Internationalized local parts require SMTPUTF8; encode internationalized domains with IDNA when an ASCII form is needed.
- Internationalized domains: Apply Unicode Technical Standard #39 section 5.2 to authenticating, envelope-from, payload, Reply-To, and Sender domains used for Gmail delivery.
This matters because a message can be accepted by one mailbox provider and rejected by Gmail if the address syntax is odd enough. Check display names, subject encoding, and address syntax separately. If your issue involves encoded mailbox text, compare the raw header against guidance on encoded addresses before changing sender identity.
MIME formatting for HTML and attachments
RFC 5322 defines the message structure, while the MIME standards RFC 2045 and RFC 2046 define content types and body encoding. Valid headers alone do not ensure that HTML or attachments can be decoded correctly.
- Include MIME-Version: 1.0 and a Content-Type matching the body. Declare the charset for text, such as UTF-8.
- Use multipart/alternative for equivalent plain-text and HTML versions, with plain text first. Use multipart/mixed for a message with attachments, nesting the alternative part when needed.
- Make each boundary delimiter match the declared boundary. Separate each part's headers from its body with a blank line, and close the multipart body with --boundary--.
- Make Content-Transfer-Encoding match the encoded bytes. Quoted-printable and MIME base64 lines have a 76-character maximum excluding CRLF, stricter than the RFC 5322 limit.
MIME headers and body for plain-text and HTML versionstext
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="example-alt-123" --example-alt-123 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your account update is ready. --example-alt-123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><p>Your account update is ready.</p></body></html> --example-alt-123--
Keep the normal From, To, Date, Subject, and Message-ID fields above these MIME headers, and serialize every line with CRLF. Let the email library generate boundaries and perform encoding. Declaring quoted-printable or base64 does not encode the body automatically.
Who owns the fix
Responsibility depends on where the message is created. If a marketer types content into a provider's campaign editor, RFC 5322 serialization should be the provider's job. If a developer builds raw email through code, the application owns the message before it enters SMTP.
Campaign team
The campaign team should focus on accurate sender identity, honest subjects, visible unsubscribe paths, and clean content. They should not need to know how to fold a header field.
- Escalation: Send raw source and SMTP response to the provider.
- Evidence: Attach the exact message that Gmail rejected.
Engineering team
The engineering team should generate the raw message through a maintained email library, preserve CRLF, avoid duplicate fields, and test after template rendering.
- Validation: Inspect the raw final message, not template input.
- Regression: Test personalized messages with long fields.
The most useful escalation package has the raw message, the Gmail response, the sending timestamp, the envelope sender, the visible From address, and the message ID your system logged. That keeps the conversation technical instead of speculative.
How to test before sending at scale
Do not validate only the template. Validate the final message after merge fields, tracking links, footers, unsubscribe headers, custom headers, and MIME boundaries are added. The broken line or duplicate field often appears only after the final assembly step.
In Gmail on the web, open a received test message, select the More menu beside Reply, then choose "Show original" to inspect its headers. Use the captured raw .eml file or sending logs to check serialized line endings. If Gmail rejects the message, capture the outgoing source and SMTP response because no received copy is available.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A good test sends through the same path as production, including its sending domain and rewritten tracking links. For bulk marketing or subscribed mail, verify an HTTPS List-Unsubscribe URL and List-Unsubscribe-Post: List-Unsubscribe=One-Click; a mailto option alone does not satisfy Gmail's one-click requirement. Keep a visible unsubscribe link in the body.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped's email tester checks authentication and unsubscribe headers on a real message sent through the production path. Suped's DMARC reporting tracks authentication across live traffic, while raw-source inspection diagnoses formatting errors. DMARC aggregate reports do not contain the full message source or prove RFC 5322 compliance.
For a domain-level check around the same sending setup, use the domain health checker to review authentication and DNS findings alongside the raw message test.
When RFC 5322 is not the real problem
If you are using a mature sending platform and Gmail is not returning a specific RFC 5322 bounce, poor delivery is probably not caused by message format. Check list source, consent, spam complaint rate, content mix, sender consistency, authentication results, and domain reputation first.
That distinction matters. Header compliance is binary enough to test. Reputation is measured over time. A single malformed message can bounce, but poor inbox placement across campaigns usually needs monitoring, segmentation, and authentication cleanup.
- Authentication: SPF normally checks the envelope sender domain and DKIM checks its signing domain. DMARC passes when at least one passing result matches the visible From domain under the configured DMARC alignment rules. Use Suped's DMARC monitoring to review those results.
- Reputation: Review domain and IP listing status with blocklist monitoring when blacklist or blocklist signals appear.
- Engagement: Separate engaged recipients from inactive addresses before increasing volume.
- Bounces: Treat a duplicate headers rejection as a formatting issue, not a content issue.
Under the Gmail sender guidelines, all senders need SPF or DKIM, valid forward and reverse DNS, and TLS. Bulk senders also need SPF and DKIM plus DMARC, with p=none accepted. Gmail counts about 5,000 messages to personal Gmail accounts within 24 hours as bulk sending, combining a primary domain and its subdomains. Keep reported spam rates below 0.3%, and target below 0.1%. These requirements are separate from message formatting.
The fastest practical workflow is: test one real message for RFC 5322 structure, fix any malformed raw source, then monitor DMARC, DNS, spam rate, bounces, and blocklist (blacklist) status over time. That separates one-message format failures from ongoing deliverability problems.
A practical compliance checklist
Use this checklist on the final message sent through your production pipeline to catch Gmail formatting problems before increasing volume.
- Raw source: Get the final raw message after all provider processing.
- Required fields: Confirm one valid Date, one valid From, and one valid Message-ID.
- Duplicates: Search for repeated single-instance fields.
- Line endings: Verify CRLF in serialized output.
- Line length: Scan for physical lines above 998 characters, and enforce the 76-character limit for quoted-printable or MIME base64 body lines.
- Header size: Check Gmail's total, field-count, and individual-value limits.
- MIME: Verify content types, charsets, transfer encoding, and matching multipart boundaries.
- Identity: Make sender, subject, links, and display names accurate.
- Authentication: Check authentication results separately from RFC 5322 format.
Views from the trenches
Best practices
Capture the raw final message, then compare Gmail rejections against exact headers.
Let the sending platform serialize mail, unless your team owns the raw generator.
Test long personalized subjects, links, and headers before increasing Gmail volume.
Common pitfalls
Treating HTML line breaks as raw CRLF line endings creates false confidence in tests.
Chasing RFC fixes for reputation problems wastes time when Gmail gives no format error.
Escalating to a provider without raw source slows down duplicate-header investigation.
Expert tips
Keep one-message compliance tests separate from ongoing DMARC and reputation review.
Use Message-ID search in logs to connect the raw source with the exact SMTP response.
Check generated output after tracking, merge fields, and footer injection have run.
Expert view
Expert from Email Geeks says most senders do not need to study RFC 5322 unless they build or modify the sending engine.
2024-03-13 - Email Geeks
Expert view
Expert from Email Geeks says duplicate From, To, Subject, or Date fields are the clearest Gmail formatting failures.
2024-03-13 - Email Geeks
