Why does Gmail rewrite or change email subject lines for senders?
Updated on 12 Oct 2026: We clarified Gmail subject displays, routing prefixes, and how subject edits affect DKIM authentication.
Gmail usually does not rewrite the actual Subject header that the sender put into a message. When the displayed subject looks different, check the delivered raw source first. Common causes include a Google Workspace routing rule, a Google Groups subject prefix, a mail gateway that modified the header, or Gmail conversation view presenting several related messages together.
The key distinction is whether the Subject header differs between the sender's generated MIME and the delivered copy. If the delivered raw header contains added text, investigate the sending system and the delivery path. If Show original retains the sender's subject but the conversation view looks different, investigate the mailbox UI and thread grouping.
Fast answer
- Start with Google Workspace routing and content compliance rules that can prepend custom subject text.
- Check Google Groups or another mailing list for a configured subject prefix, then use List-ID to identify the list path.
- Treat reputation as a placement and warning issue, not the first explanation for a changed subject string.
- Compare the sender's MIME, Gmail Show original output, conversation view, and a controlled mailbox before assigning the change to Gmail.
Google Workspace rules and Gmail display behavior
The first place to check is Google Workspace. Admins can configure Gmail routing and content compliance rules that modify messages during delivery. The Prepend custom subject action adds text before the existing subject. That can turn Campaign update into [External] Campaign update inside the affected organization, as described in Google's content compliance documentation.
A rule can cover a whole organization or only selected traffic. Conditions can target an organizational unit, inbound or internal mail, specific headers, content patterns, or an address list. This explains why users at one company report a changed subject that cannot be reproduced in an unrelated mailbox. Check secondary deliveries and Bcc copies as well: their advanced routing options can add a subject prefix separately.
![Google Workspace Gmail routing rule with Prepend custom subject set to [External].](https://qc6dmsenyc1qo7au.public.blob.vercel-storage.com/smpsj9t5sgporbe78dvj.webp)
Google Workspace Gmail routing rule with Prepend custom subject set to [External].
Header changed
The delivered message source contains a different Subject value than the sender generated. A routing rule, Google Group, mailing system, or gateway changed the message before final delivery.
- Raw source and the Gmail message view both contain the added subject text.
- Trace the systems that handled the message before it reached the mailbox.
Display looks changed
The raw source retains the sender's subject, but the inbox or open conversation supplies different context. Expand the specific message and inspect its source to distinguish its subject from the conversation heading.
- The selected message's raw Subject is unchanged even though the inbox display differs.
- Check the individual message and its position in the Gmail conversation.
Gmail conversation grouping also matters. To add a message to an existing thread through the Gmail API, supply the target threadId with matching subjects and valid References and In-Reply-To headers, as specified in Google's Gmail API threading requirements. Gmail Help states that a conversation splits when the subject changes or the thread exceeds 100 messages. Fake Re: or Fwd: text does not replace valid reply headers and can mislead recipients.
A Gmail user can also choose Edit subject while replying or forwarding. That user sends a new Subject value, and Gmail starts a new conversation. This is an intentional edit by the person composing the reply, not a silent rewrite of the message they received.
Gmail's External label is a separate warning indicator for conversations involving people outside a Workspace organization. It does not add [External] to the Subject header. Long subject lines also get truncated in an inbox row when screen space runs out. Open the message and compare Show original before diagnosing a rewrite; there is no universal 36-character display cutoff across Gmail layouts and devices.
|
|
|
|---|---|---|
Workspace rule | Admin routing and content compliance | Remove or narrow prefix |
Google Groups | Group email options | Remove subject prefix |
Conversation grouping | Reply headers and subject | Keep matching subjects and correct reply headers |
External label or truncation | Gmail display and raw Subject | Confirm the header is unchanged |
Gateway edit | Received path and gateway logs | Change gateway policy |
Encoding issue | Raw header | Fix MIME encoding |
Use this table to separate Gmail display behavior from an actual subject change.
When Google Groups adds a subject prefix
Google Groups owners and managers can set a Subject prefix under Group settings > Email options, as described in Google's subject prefix instructions. Google Groups adds that text to the beginning of every message distributed by the group, often in square brackets. Unlike a conversation-view effect, this prefix appears in the delivered Subject header on the group copy.
- Open the affected message in desktop Gmail and choose More > Show original.
- Confirm whether the bracketed prefix appears in the raw Subject header.
- Use List-ID and the Received path to identify the group that redistributed the message.
- Ask the group owner to change Subject prefix under Email options, then test with a new message.
A List-ID header identifies mailing-list traffic but does not add text by itself. A matching group identity, a bracketed raw subject, and a group hop in the delivery path point to the configured prefix. If no group handled the message, return to Workspace routing and gateway policies.
How to check the original subject header
Ask for the full original message, not a forwarded copy or only a screenshot. In desktop Gmail, open the affected message, select More next to Reply, then choose Show original. A forwarded copy can change headers and hide the delivery path. A screenshot proves what the user saw, but it does not show where the message changed.
Compare the subject in the sender's generated MIME, the delivered raw source, the Gmail inbox row, and the open conversation. Unfold header continuation lines and decode MIME encoded-words before comparing the displayed text, following RFC 2047. An encoded raw value is normal; broken encoding is a sending-system issue. If the decoded values match, there is no evidence of a change to the Subject text between those copies. If the Gmail UI still looks different, inspect the selected message and conversation grouping.
Header fields to inspecttext
Subject: RE: Campaign update From: Example Team <news@example.com> Sender: Digital Campaigns <bounce@mailer.example.com> List-ID: Digital Campaigns <campaigns.example.com> Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=mailer.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
The Sender and List-ID fields help identify a mailing system or list in the delivery path. They do not prove that Gmail changed the subject. Compare any bracketed text with the group or routing configuration, then use the Received headers to identify the delivery hops. Received headers do not record previous Subject values; compare gateway logs or message captures on each side of a suspected hop to locate the change.
For a display-only difference, temporarily turn Conversation view off in desktop Gmail under Settings > See all settings > General > Conversation view, then save the change. Inspect the individual message and restore the setting after testing. Google's conversation settings describe how to show each message separately.
Do not debug from one mailbox
A Google Workspace mailbox and a free Gmail mailbox are different tests. Workspace admins can add routing rules that never apply to consumer Gmail accounts. Use at least one controlled recipient outside the affected organization before treating the issue as Gmail-wide.
Send a clean test message through your normal sending platform to the unique address generated by Suped's email tester. Review the received-message headers and authentication results, and send a separate copy to the affected Gmail mailbox for comparison. The Suped test shows delivery to Suped; it does not reproduce Gmail conversation view or the recipient organization's routing rules.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the raw test source retains the original subject, move the investigation toward conversation view or recipient-side configuration. If the raw source already contains the changed subject, follow the delivery path backward until the routing rule, group, gateway, or sending system responsible becomes clear.
When subject changes affect DKIM
A subject prefix can create an authentication failure when it is added after signing. Check the h= list in DKIM-Signature: if it includes subject, changing the subject text invalidates that signature when a downstream receiver verifies the modified message. RFC 6376 recommends signing Subject, although only From is mandatory. Relaxed DKIM canonicalization tolerates certain whitespace changes, but it does not tolerate adding a prefix.
A failed DKIM signature does not automatically mean DMARC fails. DMARC passes when at least one passing DKIM signature or a passing SPF result satisfies the domain match required by the visible From domain's policy, as defined in RFC 9989. Forwarding often disrupts SPF, so a mailing-list prefix that also breaks the original DKIM signature needs closer investigation. A new signature using only the list's domain does not authenticate the original From domain unless it meets that domain-matching requirement.
If a receiver checks authentication before a local routing rule adds a prefix, the recorded Authentication-Results describes that earlier check. A recorded pass does not prove the saved subject is unchanged. Compare the receiving provider's results with the delivered source. Where you control an outbound gateway, make authorized subject changes before signing; ask the recipient admin to remove or narrow an unwanted local prefix.
Where authentication and reputation fit
Authentication and reputation affect spam filtering and sender warnings, but those decisions do not normally change the literal subject line. A routing rule or gateway that modifies signed content can cause an authentication failure, so investigate that connection when both symptoms appear.
If SPF, DKIM, or DMARC fail, investigate the failed checks alongside the subject comparison. Use Suped's domain health check to confirm published DNS records, then use DMARC monitoring to identify expected and unknown sending sources over time. If Gmail users also report spam placement or warnings, add Suped's blocklist monitoring to check blocklist (blacklist) evidence for the sending IPs and domains.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC dashboard groups sending sources and authentication results across reported traffic. Use those reports to find approved sources with recurring failures, then compare a sample message's headers to investigate the subject change. Aggregate DMARC reports do not include Subject headers or prove who changed a particular message. Blocklist (blacklist) evidence concerns reputation and acceptance, so keep that diagnosis separate.
How to judge authentication risk
Judge failures by source and sending volume instead of applying one universal pass-rate cutoff.
Expected state
Expected mail passes
Approved sources pass SPF or DKIM with the domain match required by the visible From domain's DMARC policy.
Investigate
Unknown or isolated
An unfamiliar source appears or an approved source has isolated failures.
Fix now
Approved stream fails
An approved source or meaningful mail stream fails consistently.
A subject that starts with a fake RE: can still hurt trust even when Gmail leaves the header intact. It can cause complaints and thread confusion. Weak authentication or inconsistent sending patterns give Gmail separate reasons to treat the message cautiously.
A practical investigation path
Use a short investigation path when a sender reports that Gmail changed a subject. Prove where the subject changed, then fix the responsible system. Do this before changing campaign copy, rotating domains, or rebuilding templates.
Gmail subject line troubleshooting flowchart: compare raw headers, check routing and list prefixes, then test mailbox types.
- Collect the original MIME from the sending platform, the raw delivered source, and screenshots of the inbox row and open message.
- Check whether the subject differs in the raw source or only in Gmail's conversation view.
- Review Gmail routing, content compliance, and group-based rules in the recipient organization.
- Inspect List-ID, Sender, Return-Path, List-Unsubscribe, and Received headers, then compare gateway logs or captures to identify the system that changed the message.
- Send the same message to a free Gmail account, a Workspace mailbox, and a non-Google mailbox you control.
- Have the responsible admin remove or narrow the Workspace or group prefix, repair headers or encoding, and investigate authentication failures linked to edits. Stop using fake reply subject patterns.
If the issue appears only in one Google Workspace organization, the sender usually cannot fix a recipient-side routing rule. The recipient's admin needs to remove or narrow it. A Google Groups prefix can be changed by the group owner. If the modified subject appears in every mailbox and in each raw delivered source, inspect the sending platform and every gateway in its handoff path.
Best fix for senders
Use plain, accurate subject lines and keep internal campaign labels out of customer-facing subjects. Put internal labels in sending-platform metadata, campaign naming, or reporting. The subject should describe the message the recipient receives.
Two related Gmail sender-identity issues need separate checks. An error about abnormal sender characters concerns address headers, as explained under abnormal sender characters. Gmail can also change how it displays sender identity, which is closer to a missing or replaced friendly from name. Neither issue proves that Gmail rewrote the subject header.
Views from the trenches
Best practices
Save the full original headers before judging whether Gmail changed the visible subject line.
Test the same send in Google Workspace and free Gmail before treating it as a Gmail issue.
Check routing, group prefix settings, List-ID, and Sender before changing subject strategy.
Common pitfalls
Assuming Gmail rewrote the Subject header when a Workspace rule prepended a local tag.
Using fake reply prefixes that invite thread confusion, user complaints, and filtering review.
Debugging only screenshots without comparing raw headers, final UI, and mailbox type first.
Expert tips
Keep campaign labels outside the subject when the label is only useful to internal teams.
Use seed addresses you control so you can capture headers and compare mailbox behavior.
Treat reputation as evidence for placement issues, not the first explanation for tags.
Marketer view
Marketer from Email Geeks says the original Subject header can remain intact while Gmail displays another line in the message list.
2025-02-28 - Email Geeks
Marketer view
Marketer from Email Geeks says Google Workspace routing can prepend custom subject text for certain messages or groups.
2025-02-28 - Email Geeks
What to fix first
Close the evidence gap first. Get the raw delivered source, compare Gmail account types, and confirm whether the subject changed in the message source or only in the conversation view. Remove fake reply patterns and internal tags where the sender controls them. Use Suped's DMARC reporting to keep source and authentication evidence separate from the subject-line diagnosis.
