Key takeaway
A subject line is a short header field naming the topic of the message, and readers judge it in under a second alongside the from-name and the preheader. Two parties enforce the same rule about it, the mailbox providers and the reader: it can't mislead about what's inside. The rest is taste, inside a 78-character convention and a 998-character limit. I test on what happens after the open, because the open itself is now partly machine-generated.
Every email in the library lists its subject line next to the email it opened, which is a better reference than a swipe list.
What a subject line actually decides.
The Subject field is a header on the message, and the format specification describes it as a short string identifying the topic of the message. That's the whole job as far as the wire format is concerned, and it's worth holding on to, because everything else ever written on this subject is an argument about how to do that one thing well.
Nobody sits down and reads a subject line, though. Three fragments arrive together and get judged in under a second: the from-name, the subject, and the preheader. That's a routing decision rather than a reading experience, and the subject line is the middle fragment of the three. On most lists the from-name settles more of it than the subject does, because recognition lands before comprehension does. I've watched a change to the sending identity move a campaign further than a month of subject-line edits did.
A subject line can't rescue a list that never asked for the mail, and it can't sell an offer nobody wants. It moves an already-willing reader from later to now, and that's the ceiling on it. Any promise past that ceiling is describing a different part of the machine.
The two rules that are not advice.
Nearly every rule you'll read about subject lines is a preference. Two of them are conditions. The first is that the line has to be true about what's inside. Not true in hindsight, and not defensible after an argument: true to what a reasonable reader would take from it before they opened anything. A subject line that misdescribes the email is the single most reliable way to convert an open into a complaint.
The second is the mailbox providers, who say much the same thing in their own words and enforce it with delivery rather than with a court. Google's sender guidelines tell senders not to open with Re: or Fwd: unless the message really is a reply or a forward, and that headers and content have to be accurate rather than misleading or deceptive. Yahoo is blunter, and bars deceptive subject lines alongside forged headers.
So the fake reply and the fake order confirmation aren't clever. They're the one move on this entire topic that has a named consequence attached to it, and the consequence is applied by the party deciding whether your next campaign reaches an inbox. The limit here is the obvious one: honesty in a subject line is a floor, not a strategy, and clearing it earns you nothing on its own.
Length is a client question, not a rule.
Ask how long a subject line should be and you'll get a different answer on almost every page, sometimes two on one page: a word count here, a character range there, and "vary it" a section later. They disagree because none of them is measuring the same thing. Truncation happens after the message leaves you, and four things you don't set decide it.
- Client: every mail app allots a different width to the subject, and the same line wraps differently in each one.
- Device and orientation: a phone held upright shows the least of it, and a desktop reading pane shows the most.
- From-name length: the sender name sits on the same row in most list views, so a long one eats the subject's space.
- Preheader handling: some clients spend the leftover room on preview text, and others cut the subject to make space for it.
Stop writing to a character count, then, and write to a position instead. Put the words that identify the message at the front, write as though only the first thirty characters or so are guaranteed, and treat the rest as a bonus.
The format has limits even where the inbox doesn't. A header line should be no more than 78 characters and must be no more than 998, which is RFC 5322 again, and non-ASCII characters in a Subject field mostly don't travel as themselves. Sending them directly needs SMTPUTF8 support on every hop, so in practice they travel as encoded words capped at 75 characters each, split across several when the text runs longer. That's the mechanical reason an emoji-heavy subject line folds or mangles in some clients, and none of it is about taste.
Open rate stopped being the subject line's scoreboard.
An open gets recorded when a tracking pixel loads, and a pixel is remote content. Apple Mail downloads remote content in the background by default, regardless of whether the recipient engages with the email, and routes the request through relays on the way.
Which puts nearly every guide on this topic in an awkward position. They promise to lift your open rate, and then they tell you to A/B test your subject lines on open rate. Those two instructions can't both be followed honestly any more. A subject-line test judged on opens is partly a test of how many people in that segment read their mail on an Apple client, and you didn't choose that split. The randomizer did.
Opens aren't worthless, and that's as far as the complaint goes. On a stable audience they're still a usable trend line, and on a segment with nothing to click they're the only signal available at all. What they are not is a comparison metric between two subject lines sent to two halves of one list, which is precisely the job everybody gives them.
Judge a subject line on what happens after the open instead. Click rate is the first honest signal. Clicks per opener is sharper where your platform reports it. The thing you actually wanted, a reply, a booking, or an order, is the one that settles the argument. All three are slower and all three come with smaller numbers, and they're the only version of this test that still means something a month later.
The patterns that survive the inbox.
Every pattern below is one underlying move performed six ways: say what's inside, in the reader's own words. What changes between them is what the reader is being told and how much they're being asked to take on trust. None of them is a template to fill in, I'd test on replies and clicks rather than opens for all six, since a proxy fetch counts as an open before any human sees the line. A swipe file of somebody else's winners is a record of other people's audiences rather than a method for yours.
- The plain statement of contents: what's in the email, said flatly, as in "Your March invoice is ready".
- The specific number: a real figure or a named amount rather than "big savings", as in "Three seats left on Thursday".
- The dated event: a deadline that exists, as in "Registration closes Friday", and only ever one that does.
- The question the reader already has: their question rather than a rhetorical one, as in "Where's your order?".
- The continuation: a reference to something the reader just did, which is why triggered mail earns personalization that a campaign has to pay for.
- The curiosity line: it works, and it's the one pattern that borrows against the next send rather than paying for itself.
The order isn't a ranking. It's a decision about what the reader is owed in this particular message, and a triggered notification and a Tuesday campaign aren't the same writing job. The curiosity line is the only one carrying a running cost, and it collides with the two rules above the moment the email doesn't deliver what the line implied. At that point you're not in a debate about taste any more. Plain over clever has a real number behind it: Hyggekrog, a solo brand where the founder writes every email, runs an 90% open rate and a 32.94% click rate, off subject lines that just say what's inside.
Personalization, emoji, and urgency are amplifiers, not content.
Each of these multiplies a subject line that already says something, and multiplies nothing at all when the line says nothing. They're the last thing to reach for rather than the first.
A first name is the weakest form of personalization and by some distance the most used. It proves a field was populated, which readers worked out years ago. The strong form is naming what the reader did, and triggered mail gets it almost for free, because the event that fired the message is the thing worth putting in the line. A campaign has to earn the same effect through a segment that's genuinely a segment, and a group assembled from one form field filled in two years ago isn't one.
Emoji are a taste and brand-voice decision with one mechanical consequence, already covered above: they encode, they consume characters, and they render differently in every client. If the voice wants one, use one, and count it against the words you were going to spend.
Urgency that's true is a fact and belongs in the subject line. Urgency that isn't is the cheapest route to a complaint, and complaints are the one number here with a published ceiling on it. Google asks bulk senders to keep their Postmaster Tools spam rate below 0.10%, and never to reach 0.30% or higher. A fake deadline crosses that line faster than any word in the subject ever will.
How to test a subject line so the answer means something.
This is the test almost every sender runs and the one they run worst. Four failures account for most of it: the sample was too small to separate anything, the metric was compromised in the way described above, more than one thing changed between the halves, and the result was never written down anywhere the next person could find it. Five steps deal with all four, and not one of them is about writing.
- Pick the metric before the send, and pick one that survives a proxy fetch.
- Hold everything else still: the same segment, the same send window, the same from-name, and the same preheader.
- Change one dimension rather than one word. Length against length, specific against curious, question against statement.
- Size the halves so the difference you care about could actually show up in them.
- Write the result down against the segment it came from rather than against the campaign.
A subject-line test tells you about one audience at one moment, and the winner rarely survives contact with a different list. The value isn't the individual result. It's the record that accumulates beside each segment once you've run twenty of them.
Where the subject line stops being a writing job.
At one campaign a week, a subject line is something a person types into a composer and thinks about for ten minutes. That's a writing job, and every guide on this topic, this one included, is written for it.
It stops being one somewhere around forty segments, a set of triggered flows, and a test already running. The subject line is a generated string per audience by then, and writing quality isn't the bottleneck any more. The bottleneck is that every variant has to be typed into a screen by a person, and the record of what won ends up in somebody's head instead of beside the segment it belongs to. That's why the fifth step above is the one everybody skips. There's nowhere obvious to put the answer.
What that runs into is the platform underneath. Every existing email platform was built for a human clicking buttons, so an agent reaches only what somebody remembered to wrap in an API. Nitrosend is MCP-first: campaigns, segments, templates, and tests are tools an agent calls before they're screens a person clicks. A subject-line test becomes a command, and the answer lands where the audience definition already lives.
Both things this page asks of you, testing on a metric that survives a proxy fetch and keeping the record beside the segment, are bookkeeping, and bookkeeping is what a screen makes expensive. That's the part we built an agent to carry. Start on the free tier: 8,000 emails to begin with, then 500 a month, unlimited contacts, and no credit card.
Go deeper
Sources
- RFC 5322, Internet Message Format: the Subject field as a short string identifying the topic of the message, and the 78-character and 998-character limits on a header line.
- RFC 2047, non-ASCII text in message headers: encoded words are capped at 75 characters each and longer text is split across several of them.
- RFC 6532, internationalized email headers: UTF-8 may be used directly in header field values, including the unstructured text used in fields like Subject, and messages using the extension need SMTPUTF8 transport.
- Google, Email sender guidelines: don't open a subject line with Re: or Fwd: unless the message is an actual reply or forward, keep headers and content accurate, and keep the Postmaster Tools spam rate below 0.10%, never reaching 0.30% or higher.
- Yahoo, Sender Best Practices: no false or misleading header information and no deceptive subject lines.
- Apple, Mail Privacy Protection: Mail downloads remote content in the background by default, regardless of whether the recipient engages with the email, and routes it through two separate relays.
Common questions
There isn't a single length that works, because truncation is the mail client's decision rather than yours. The client, the device and its orientation, the length of your from-name, and how preview text is handled all change how much of the line shows. Front-load the words that identify the message, and treat the rest as a bonus some readers will see.
It depends on the audience, and it's worth testing on a metric that survives a proxy fetch rather than on opens. Mechanically an emoji is non-ASCII, so it travels as an encoded word, costs characters from a line that's already short, and renders differently in every client. Use one where the brand voice genuinely wants one.
No. A first name is the weakest form of personalization and proves only that a field was populated. Naming what the reader just did is the strong form, and triggered mail gets it almost for free, because the event that fired the message is the thing worth saying. A campaign earns it only where the segment is real.
That question has stopped having a clean answer. An open is recorded when a tracking pixel loads, and Apple Mail loads remote content in the background whether or not anybody read the message, so the ranking you'd build from opens is partly a ranking of mail clients. The lines that earn attention say plainly what's inside. Judge them on clicks, replies, or orders.
Not on its own, and not because of a word list. Filtering scores the whole message and the sender's history, so no vocabulary is a trigger by itself. The route a subject line really takes to the spam folder is complaints: it promises something the email doesn't deliver, recipients hit the spam button, and the complaint rate climbs.
Not if the message isn't a reply. Google tells senders not to open with Re: or Fwd: unless the message is an actual reply or forward, and Yahoo bars deceptive subject lines outright. The reader is the harsher judge of the two: somebody who opens a fake reply and finds a sale reaches for the spam button, not the unsubscribe link.
Two, in most cases. A third variant splits the same audience three ways, and each arm gets small enough that a real difference stops showing up in it. Add a third only when the list is large enough that every arm still carries a meaningful sample. Change one dimension between them rather than one word.
No. They're read together in one glance, so a preheader repeating the subject wastes the second half of the sentence. Let the subject identify the message and let the preheader carry what comes next: the detail, the deadline, or the reason it matters now. Written that way they read as one line rather than two.