Somewhere in your inbox there is a message that begins Dear [FIRST_NAME], or Hi [FIRST_NAME], or — if the platform default has been left untouched — Dear [FIRST_NAME], with the comma sitting outside the bracket like a coat left on the wrong hook. The greeting is the part everyone discusses. It is also the least interesting part of the format.
A merged message has two containers. The first is the body: the paragraphs, the greeting line, the conditional block that says since you’re in [CITY]. The second is the header section, and it is where the rules live. The personalization debate is usually conducted entirely in the first container. The more consequential decisions — who the message claims to be from, whether a reply is possible, how the reader leaves — are made in the second.
The header is a structured container, not free text
RFC 5322, the Internet Message Format specification, defines a message as header fields followed optionally by a body, separated by an empty line. Header fields are lines beginning with a field name, followed by a colon, followed by a field body, terminated by CRLF. That is the whole grammar of the top of your message. It is not a place for prose.
The standard also sets line limits: each line must be no more than 998 characters and should be no more than 78, excluding the CRLF. The conservative 78-character recommendation exists, in the standard’s own words, to accommodate user interfaces that may truncate or wrap the display of longer lines. This is worth sitting with. The limit is not about the wire. It is about the reader’s screen. A long subject line or a long display name is a bet that the client will handle it gracefully. Some do. The standard was written because some do not.
If you are choosing a merge field for a subject line, you are choosing a string that will be concatenated with other strings and then measured against a limit designed for display, not for storage. That is a format decision, and it belongs to you rather than to whatever the platform’s default template happens to do.
From and Sender are an editorial claim
RFC 5322 as updated by RFC 6854 distinguishes two originator fields. The From field specifies the author of the message — the mailbox of the person or system responsible for the writing. The Sender field specifies the agent responsible for the actual transmission. The standard’s example is a secretary sending on behalf of a principal: the principal’s mailbox appears in From, the secretary’s in Sender.
Most merged mail collapses both roles into a single From line. That is a format default, not a requirement. And the standard is explicit about the boundary: From should not contain any mailbox that does not belong to the author or authors of the message.
Read that as an editorial constraint rather than a technicality. A personalized greeting asserts authorship. When a publication merges a first name into the greeting while sending from a shared editorial mailbox, it is making two claims at once — that the message is personal, and that it is authored by the publication. The format permits both. Only one of them is stated in the field the reader sees first. Naming which claim is intended is a craft decision. It is not a deliverability decision, and no amount of subject-line testing will resolve it.
If the writing and the sending genuinely come from different parties — an editor writing under a publication’s name, an assistant sending for a principal — the format already has a field for that. Using it is a deliberate choice. Not using it is also a choice, and it is the one most platforms make for you.
The empty group: a formal option with a cost
The genuinely interesting merge artifact in the retrieved standards is group syntax. RFC 6854 updates RFC 5322 to allow group syntax in the From and Sender fields, as well as in Resent-From and Resent-Sender, in certain situations. The standard’s own example is an automated nightly monitor program, presented like this:
From: Nightly Monitor Robot:;The empty group after the colon means the message presents itself as coming from a system with no replyable address. Recipients’ email clients will not allow them to reply in the first place. The standard notes that such messages commonly include a valid, replyable address that discards replies — and that recipients who do reply might be unaware their replies will be discarded. The empty group is a way of being honest about that.
It is also a formal option with a cost attached, and the standard says so plainly. Group syntax is characterized as Limited Use. User agents should not permit its use in outgoing messages. Senders need to be aware that using groups in the From field might adversely affect deliverability.
For a writer, this is the most useful kind of artifact: a documented option that most platforms will never offer, with the trade-offs stated in the same document that permits it. You are unlikely to need it. You are more likely to need to know it exists, so that when a platform collapses every originator into a single friendly name, you can see what has been decided on your behalf.
The exit is part of the format
RFC 8058 describes a method for signaling a one-click function for the List-Unsubscribe header field. The requirements are specific. A sender enabling one-click unsubscription places one List-Unsubscribe header field and one List-Unsubscribe-Post header field in the message. The List-Unsubscribe field must contain one HTTPS URI. The List-Unsubscribe-Post header must contain the single key/value pair List-Unsubscribe=One-Click. The message must have a valid DKIM signature covering at least those two headers.
The POST request must not include cookies, HTTP authorization, or any other context information. The sender must not return an HTTPS redirect, because redirected POST actions have historically not worked reliably. And the receiver must not perform the POST without user consent.
Read this as the counterpart to the greeting. The container has a provision for the reader leaving, and that provision is engineered rather than appended. A publication that treats the inbox as a site of editorial independence should treat the reader’s departure with the same deliberateness as the reader’s arrival. The unsubscribe path is not an afterthought bolted onto the format. It is part of the format, and the standard treats it with the same specificity as the address fields.
What the merge actually is
The mail merge is usually told as a story about personalization — a name swapped into a greeting line. The standards suggest a different and more useful account. The merge is a set of decisions about which fields you fill and which you leave honest. Personalization at scale is bounded by the address syntax. The unsubscribe path is bounded by the same header section that carries the greeting.
A hypothetical illustration, clearly labeled as such: a small publication merges a first name into its greeting while sending from a shared editorial mailbox. It is making two claims at once. The format permits both, but only one is stated in the field the reader sees first. Naming which claim is intended is the work. The platform default will not name it for you.
The container disciplines the content. That is not a constraint to work around. It is the material you are working with.
Questions readers ask
Can I use group syntax in my newsletter’s From field? The standard permits it in certain situations, but characterizes it as Limited Use, advises that user agents should not permit it in outgoing messages, and warns that it might adversely affect deliverability. Most newsletter platforms will not expose the option at all. If you need a message that cannot be replied to, the empty group is the documented form; whether it is the right choice for your publication is a separate question.
Does the 78-character line limit apply to my subject line? RFC 5322 states that each line must be no more than 998 characters and should be no more than 78, excluding the CRLF. The recommendation exists to accommodate user interfaces that may truncate or wrap longer lines. Subject lines are not header fields in the same sense, but the reasoning — display, not storage — applies to any string the reader sees first.
What does one-click unsubscribe require? Per RFC 8058: one List-Unsubscribe header with one HTTPS URI, one List-Unsubscribe-Post header containing List-Unsubscribe=One-Click, and a valid DKIM signature covering both headers. The POST must not carry cookies or context information, and the sender must not redirect it.
Should I use Sender if I’m sending from a shared mailbox? The standard distinguishes the author of the message from the agent responsible for transmission, and its example is a secretary sending for a principal. If the writing and the sending genuinely come from different parties, the format has a field for that. Whether your platform exposes it is a separate matter.
