Quoting and Trimming Replies: How Much to Leave In

How much of an email should you quote in a reply comes down to one test: would someone reading this cold, with no memory of the earlier messages, understand what you're responding to? If the answer is yes with just the last line or two, quote the last line or two. If the answer needs the full exchange — because a compliance rule requires an unbroken record, or five people have weighed in and lost the thread — keep everything.

There's no single rule that covers every reply, and treating it like there is one is how inboxes end up full of 40-line messages that repeat the same signature block four times. The right amount depends on who's reading, what kind of thread it is, and which client renders it. This guide covers the criteria that actually decide it, how Gmail, Outlook, and Apple Mail differ by default, and the one context where keeping everything is the correct call rather than the lazy one.

Getting it wrong runs in both directions, and both are common enough to have their own reputation. Trim too aggressively on a thread someone else needs to reconstruct later — a support ticket handed to a teammate, an approval chain someone audits in six months — and you've deleted the one thing that made the reply useful to anyone but you. Trim too little and every reply on a long thread becomes a scroll past messages the recipient already read, with the actual new sentence buried at the bottom or top depending on the client. Neither failure is really about etiquette; both cost the next reader real time.

The criteria that actually decide it#

Three questions do most of the work. Who else is on the thread — one person, or a distribution list that's grown to a dozen? Is this thread disposable once it's resolved, or does it need to exist as a record afterward? And will the reader open this on a laptop with a wide reading pane, or on a phone where a fully quoted thread pushes your actual answer below the fold?

• Audience size — a one-to-one exchange tolerates heavy trimming because only one person needs the context refreshed; a wide CC list benefits from more history because latecomers haven't seen the earlier messages
• Record-keeping requirement — legal correspondence, compliance approvals, incident postmortems, and anything that might be produced later as evidence should keep the full quoted history, unedited
• Thread age — a reply sent minutes after the original needs little quoting; a reply sent after a week or a holiday should quote enough that the recipient doesn't have to search their own inbox to remember the question
• Reading surface — mobile-heavy recipients lose more to a long quoted block than desktop readers do, because the new content scrolls further out of view before it's ever read
• House convention — a company or mailing list that already has a norm, interleaved on a developer list or top-posted internally, is a stronger signal than any general rule in this guide

None of these five outrank the others by default; they're read together. A short internal reply to one person, two days old, on a thread nobody will ever reopen, sits at the trim-everything end regardless of client. A five-person approval chain with a compliance flag sits at the keep-everything end even if it's also short. Most replies fall somewhere in the middle, and that middle is where the client you and your reader are using starts to matter.

How Gmail, Outlook, and Apple Mail quote differently by default#

The three clients most people use every day don't just look different — they default to different quoting behavior, and that shapes what counts as normal for whoever reads the reply.

• Outlook, classic and new, top-posts by default and folds the quoted history under a plain "From / Sent / To / Subject" header block rather than ">" marks, which is why corporate threads read top-down and rarely get trimmed by hand
• Gmail also top-posts by default, but it visually collapses the quoted portion behind a small "..." toggle in the compose window, so the sender sees a short message even though the full history is still attached underneath — trimming has to be deliberate, or it never happens
• Apple Mail quotes only the text you select before hitting reply, prefixed with ">", which makes it the one mainstream client where partial, inline quoting is the path of least resistance instead of an extra step
• Mailing-list software and terminal clients such as mutt and alpine default to quoting everything with incrementing ">" levels, the convention formalized by RFC 3676's format=flowed profile for wrapped plain text

How much to quote, by scenario#

Put together, those criteria point to a default per situation rather than one rule for every reply. This is the shortlist worth keeping near the compose window:

A worked example: trimming a real thread#

Take a five-message thread: a project update, two clarifying questions, a partial answer, and now a final reply that only needs to confirm a date. Quoting the entire chain would mean forwarding two signature blocks, a confidentiality footer, and a question that's already been answered twice further up.

The trim that actually helps: keep the one question this message answers, drop everything above it, and drop the signature block entirely — the sender's identity is already in the From field, and a client that shows threaded conversations doesn't need it repeated. What's left fits on one screen and is still traceable back to the original ask if anyone opens the full thread later.

On a phone, the difference is bigger than it looks on a laptop. The untrimmed version pushes the actual new sentence past two full screens of scrolling on a typical mail app, which is long enough that a reader skimming between meetings genuinely misses it. The trimmed version is the whole message on one screen, no scrolling required to see the part that changed.

Red flags#

A few patterns are worth catching before you hit send, regardless of which style you default to.

• Quoting past a legal hold or compliance notice and then trimming it out — if a message says the thread must be preserved, trimming is the one thing not to do
• Four or more nested quote levels with no summary at the top — by the third ">>>" most readers give up trying to reconstruct who said what
• Top-posting a reply that answers six different points from the original message, forcing the reader to hold six questions in their head while reading one undifferentiated block of answers
• Trimming a thread that's still open in a shared inbox or a ticket, where the next person to touch it needs the history you just deleted
• Replying to a cold thread, days or weeks old, with no quote and no restated context, on the assumption the reader remembers exactly what it was about
• Trimming out the part of the message where someone explicitly asked a question, while keeping the small talk around it — the opposite of what a trim is supposed to protect

What we'd pick, and why#

If there's one default worth defaulting to: trim to what you're directly answering, and say so plainly if you've cut something the reader might expect ("trimmed the earlier thread — see the original for full context" is one line). Keep everything, untouched, the moment a thread has any chance of being a legal, compliance, or audit record. That single branch covers most of the judgment calls in this guide, and it holds regardless of which client either side of the conversation is using, because the decision is about the reader, not the software.

Where that default gets hard to apply is volume — deciding it fresh on the fortieth reply of the day is exactly when top-posting the whole history wins by default, not because it's right. We build AI Emaily, and this is one of the smaller, unglamorous things its agent does when it drafts a reply on your behalf: it keeps the lines the reply is actually answering, guided by the Personal Context brain's read on what a given correspondent already knows, rather than reflexively attaching every prior message.

It isn't the right fit for every setup. If your team runs a mailing list with a house style that mandates manual, character-by-character inline quoting, or if a native Linux build is a hard requirement — we don't ship one; web works fine, but that's a real gap — a plain client that leaves quoting entirely in your hands is the better call. For everyone deciding this by habit dozens of times a day, having it decided consistently is worth more than any single instance of it.