From is who the email looks like it came from; Reply-To is where a reply should go when that is a different address. They are two distinct headers with two distinct jobs, and a help desk that answers the From instead of the Reply-To will silently drop replies to any on-behalf-of sender. Get this wrong once and the customer's response lands in a no-reply mailbox nobody reads.
From is who it looks like
The visible From header is the identity a mail client shows at the top of a message — the brand the customer recognizes. It is also the domain that DKIM alignment is checked against for DMARC, which is why sending signed as your own domain matters so much for whether your mail is trusted. The From is not, however, where bounces go. That is the return-path — the hidden envelope address checked by SPF. Three different headers, three different jobs, and conflating them is where both deliverability and threading break. For the full picture of how these fit together, see the support email deliverability guide.
Reply-To is where replies should go
Reply-To is an optional header that names where a reply should be directed when that differs from the From. When a mail client sees it, the reply is addressed to the Reply-To value instead of the From. When it is absent, replies default to the From. That single fallback rule is the whole reason the header exists: it lets a message present one identity while collecting responses at another.
- From present, no Reply-To — replies go to the From address.
- From and Reply-To both present — replies go to Reply-To.
- Reply-To points at a list or alias — replies fan out to whoever is behind that address.
The three addresses in every email
Most threading and bounce confusion comes from treating "the sender" as a single thing. It is not. A typical message carries at least three independently settable addresses, and each is read by a different system.
| Header | What it does | Who reads it |
|---|---|---|
| From | Visible sender identity; DKIM/DMARC alignment domain | The recipient's mail client and inbox provider |
| Reply-To | Where a reply is addressed when it differs from From | The recipient's mail client on "Reply" |
| Return-Path | Envelope sender; where bounces and SPF checks land | Mail servers, not the human |
None of these has to match the others, and in practice they often don't.
On-behalf-of senders and no-reply
The classic case is an on-behalf-of sender. A platform like Shopify sends an order notification where the From is a no-reply or platform-owned address, but the real human — the merchant, or their support inbox — is named in Reply-To. The same pattern shows up with mailing-list software, calendar invites, and any system that sends "as" someone while wanting answers to come back somewhere monitored. If the original message has a From of no-reply@… and you reply to it, the response either bounces or rots in an unwatched mailbox. The Reply-To is the only address that reaches a person.
Why ticketing has to respect it
A naive help desk replies to whatever is in the From and the message dead-ends. That is a real bug, not an edge case — forwarded mail, group aliases, and platform notifications all rely on Reply-To. Cherryrise routes the agent's reply to the Reply-To when it is present and differs from the From, so the customer's response reaches the actual person rather than a no-reply void. Because Cherryrise is a shared inbox built on real email, it has to get this right for the same reasons a human pressing "Reply" in their own client does.
Threading is a separate problem
Knowing where to send a reply is only half the job. The other half is making sure the reply lands back on the right ticket. That is a threading question, and the correct way to answer it is with the Message-ID, In-Reply-To, and References headers — the same chain every mail client uses to build a conversation view. Matching on subject line or sender address is fragile: subjects get edited, and addresses change exactly in the on-behalf-of cases above. Cherryrise threads on those standard headers, so a reply rejoins its ticket even when the addresses involved don't match the original message.
Setting Reply-To on your own outbound
The header cuts both ways. When you send notifications — a portal update, an automated acknowledgement, a digest — decide deliberately where you want replies to land. A few rules of thumb:
- If a message can usefully be replied to, set Reply-To to a monitored support address even if the From is a branded notification sender.
- Don't send from a no-reply address and then leave Reply-To empty; that guarantees lost replies.
- Keep the From on a domain you control and sign, so DKIM/DMARC alignment holds regardless of what Reply-To says.
For why the From domain matters to inbox placement specifically, see why support replies go to spam and DKIM for support email, explained.
Frequently asked questions
What is the difference between the From and Reply-To headers?
The From header is the visible identity of the sender — the name and address a mail client shows at the top of a message. Reply-To is an optional header that tells the client where a reply should be addressed when that differs from From. If Reply-To is absent, replies go to From. If it is present, well-behaved clients send the reply to the Reply-To address instead.
Does Reply-To affect email deliverability or DKIM?
Reply-To does not affect deliverability or authentication directly. DKIM signs the message and is checked against the From domain for DMARC alignment; SPF is checked against the envelope return-path. Reply-To is not part of SPF, DKIM, or DMARC evaluation. It only changes where a human's reply is routed, not whether the original message passes authentication.
Why do replies to no-reply addresses get lost?
When a message is sent from a no-reply From address with no Reply-To, any reply is delivered to a mailbox nobody monitors, or bounces. The sender should set Reply-To to a monitored support address so the customer's reply reaches a real person. A help desk that ignores Reply-To and answers the From recreates this dead end.
How does Cherryrise handle Reply-To when sending and threading?
When a customer message carries a Reply-To that differs from the From, Cherryrise routes the agent's reply to the Reply-To address so it reaches the actual person. Threading uses the Message-ID, In-Reply-To, and References headers rather than guessing from addresses, so the response lands back on the correct ticket even when on-behalf-of senders are involved.
Smart Reply-To is built in. See the deliverability section.