Gmail header-size rejections for legitimate mail: diagnosing ARC bloat, mailing-list headers, and tracking overload

When Gmail rejects a legitimate message for header size, the first wrong assumption is usually that the message body must be too large.

Often it is the opposite. The body can be normal. The attachments can be small. The failure is in the metadata wrapped around the message.

Google now documents these header limits clearly:

• all headers together: 500KB
• total header count: 5000
• any single header value: 32KB

That third one matters more than many teams expect. A message does not need to have overall header bloat to fail. One giant ARC-Seal, List-Unsubscribe, Authentication-Results, or custom tracking header can be enough.

What Gmail actually rejects

Google's Gmail message header limits page shows the relevant rejection family as 552-5.3.4.

The error text tells you which limit was crossed:

• total header bytes exceeded 512000
• header count exceeded 5000
• a single standard header exceeded 32768 bytes
• a single non-standard header exceeded 32768 bytes

That is a useful distinction because the troubleshooting path is different.

If the SMTP reply says a standard header is too large, focus on things like ARC, Received, list headers, Authentication-Results, or other RFC-defined fields.

If the reply says one of the headers exceeded the limit without naming it, Google is usually referring to a custom header. In real mail flows, that often means tracking, feedback, campaign, routing, or internal analytics metadata.

The three most common causes in legitimate traffic

For real operational mail, header-size failures usually cluster into three buckets:

1. ARC chains that grew across too many hops
2. mailing-list or subscription headers that multiplied or carried oversized URLs
3. tracking and analytics headers that quietly became huge

Sometimes you get two or all three at once.

Why ARC can become the biggest header problem

ARC is useful because intermediaries can preserve authentication context across forwarding and modification. But ARC is not free. Every ARC hop adds three headers:

• ARC-Authentication-Results
• ARC-Message-Signature
• ARC-Seal

RFC 8617 explicitly calls out increased header field size as a security and operational consideration, and it caps ARC instance values at 1 through 50 partly to limit header growth.

That does not mean Gmail waits until 50 ARC sets before mail becomes risky. Long before that point, the accumulated headers can become bulky enough to cause delivery trouble, especially when each hop records verbose authentication results or uses long DKIM-style signature values.

ARC bloat pattern to look for

This is the usual shape:

1. original sender signs normally
2. message goes through a gateway, a list manager, a filtering service, and maybe another forwarding layer
3. each hop adds a fresh ARC set
4. each hop also adds more Received and sometimes more Authentication-Results
5. Gmail eventually rejects the message because one header or the total header section crossed the limit

This is especially common in environments where mail loops through:

• secure email gateways
• inbound filtering services
• internal forwarding tiers
• mailing lists or discussion platforms
• compliance journaling or archive relays

If you need the protocol background first, What is ARC in email and how does it work? and How to read ARC headers in practice are the best companion posts.

What to inspect in a delivered sample or rejected copy

Count how many ARC sets exist by looking at the highest i= value.

Then check whether the ARC headers are unusually verbose. A single hop can add a lot of text if:

• ARC-Authentication-Results records many sub-results and properties
• the signatures use long b= values and broad h= coverage
• multiple systems seal the same message in sequence even when they add little value

If the message passed through eight or ten intermediaries, the problem may be architectural more than accidental.

Mailing-list headers: small individually, big in combination

Mailing-list headers are legitimate and standardized. RFC 2369 defines headers such as:

• List-Help
• List-Subscribe
• List-Unsubscribe
• List-Post
• List-Owner
• List-Archive

RFC 8058 adds List-Unsubscribe-Post for one-click unsubscribe signaling.

None of those headers are bad by themselves. The issue is that they can become surprisingly large when they contain:

• long HTTPS unsubscribe URLs with opaque recipient tokens
• multiple alternate URLs in the same header
• nested list-manager rewrites
• tracking parameters appended to already long unsubscribe links

Google's single-header 32KB limit applies to these headers too.

The worst offender is often List-Unsubscribe

That header can legitimately contain more than one URI. RFC 2369 allows multiple angle-bracketed URLs in order of preference, and RFC 8058 requires enough information in the HTTPS URI for one-click processing.

That means a sender can end up with something like:

List-Unsubscribe: <mailto:list-request@example.com?subject=unsubscribe>, <https://example.com/unsubscribe/very-long-opaque-token-and-other-parameters>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Now combine that with campaign parameters, per-recipient encoding, and a downstream platform that rewrites or appends more metadata. That single header can get large quickly.

Mailing lists also create header multiplication

List traffic often accumulates more than just List-* fields:

• extra Received lines
• extra Authentication-Results
• ARC if the list seals
• subject rewrites and resent-style handling in some systems
• footer-processing systems that also inject their own custom metadata

So even if no one List-* header is enormous, the list path can still push the total header section toward Gmail's 500KB limit.

For the broader indirect-flow background, DMARC forwarding and mailing lists: why SPF and DKIM fail (and how ARC helps) is the right nearby read.

Tracking overload is usually a custom-header problem

This is the category teams miss most often because the message still looks normal in the mail client.

The visible message may be short, but the sending platform can attach a pile of metadata such as:

• X-Campaign-*
• X-Feedback-ID
• X-Entity-*
• X-Trace-*
• internal workflow, tenant, customer, journey, or segmentation headers

Individually these may seem harmless. But if a platform stores long JSON-like blobs, many UUIDs, encoded URLs, or repeated audience metadata in custom headers, Google may reject the message as a non-standard header over 32KB.

This gets worse when multiple systems add their own custom headers and nobody owns the final assembled message.

Common tracking-overload pattern

1. marketing platform adds campaign IDs and list metadata
2. link-tracking layer adds rewritten URLs and feedback IDs
3. downstream relay adds tenant or routing annotations
4. CRM or support platform injects conversation metadata
5. custom headers now dwarf the human-readable message

If Gmail's error text does not name the offending header, start here.

A practical diagnosis sequence

This order usually gets to the root cause fastest.

1. Save the exact Gmail SMTP rejection text.
2. Determine whether Gmail complained about total headers, header count, a named standard header, or an unnamed non-standard header.
3. Capture the fully assembled message as close to final outbound delivery as possible.
4. Measure the unfolded size of each header, not just the visual folded lines.
5. Count ARC sets and note the highest i= value.
6. Inspect List-*, Authentication-Results, ARC-*, and Received first for standard-header failures.
7. Inspect X-* and provider-specific metadata first for unnamed non-standard-header failures.

That sequence matters because Gmail evaluates the message after all your intermediaries have finished modifying it.

The message your app generated may be fine. The message your final MTA emitted may not be.

What unfolded size means, and why it matters

RFC 5322 allows header folding so long headers can wrap across lines. But folding is presentation, not a true size reduction. Gmail's documented limits apply to the actual header content, not the way it is visually wrapped in a raw source view.

So this can be misleading:

List-Unsubscribe:
 <https://example.com/unsubscribe/...>

It looks split across lines, but logically it is still one header value.

The same applies to long ARC signatures and giant custom headers.

Which standard headers usually cause the failure

In practice, standard-header failures tend to come from one of these:

• ARC-Seal
• ARC-Message-Signature
• ARC-Authentication-Results
• Authentication-Results
• List-Unsubscribe
• Received

Google's exception for To:, Cc:, and References: not having the same single-header 32KB limit is useful, but those are usually not the problem in the ARC/list/tracking scenarios anyway.

Fixing ARC bloat without throwing ARC away

ARC is often still the right feature. The fix is usually to reduce unnecessary sealing and unnecessary hops.

Start here:

1. map the full message path end to end
2. remove redundant forwarding or security layers where possible
3. avoid sealing at intermediaries that do not add meaningful trust value
4. reduce verbose authentication-result annotations if your platform allows it
5. stop reprocessing the same message through parallel hygiene tiers

If a secure email gateway is part of the chain, How to stop secure email gateways from breaking DMARC covers the trust-order side of that design.

Fixing mailing-list header growth

The safest cleanup steps are usually:

1. shorten unsubscribe URLs
2. avoid duplicative alternate URIs unless they are actually needed
3. remove unnecessary query parameters from list-management links
4. verify downstream systems are not rewriting list headers with extra tracking data
5. keep only one instance of each List-* field as intended by the standards

That last point matters. RFC 2369 says there must be no more than one of each list header in a given message. Duplicate list headers are not just messy. They also waste header budget.

Fixing tracking overload

This is usually the fastest win.

Ask a blunt question: which custom headers are operationally required at final delivery, and which exist only because no one cleaned them up?

Then:

1. remove bulky debug and internal workflow headers from production sends
2. shorten opaque identifiers where feasible
3. move rich metadata out of headers and into internal event stores
4. stop serializing structured blobs into X-* headers
5. verify that downstream relays are not duplicating upstream metadata

Google's own remediation advice for header-limit failures is simple: truncate header values or move information into the message body. In practice, for internal telemetry, the better answer is often to move the data out of the email entirely.

A simple decision tree that works

If Gmail says:

• 512000 total header bytes or 5000 header fields: think cumulative growth across ARC, Received, list headers, and custom metadata
• named standard header over 32768: inspect ARC, list headers, Authentication-Results, or Received
• unnamed non-standard header over 32768: inspect tracking and custom X-* metadata first

That one split will save a lot of time.

In summary

Gmail header-size rejections for legitimate mail usually come from metadata accretion:

• ARC chains that grew across too many hops
• mailing-list headers with long unsubscribe or archive URLs
• tracking and analytics headers that turned into oversized custom metadata

Use Gmail's rejection text to separate total-header failures from single-header failures. Then inspect the fully assembled outbound message, count the ARC hops, measure unfolded header sizes, and be ruthless about removing metadata that does not need to ride with the message.

The fix is rarely "change the email copy." The fix is usually "send a smaller story about the email."