Skip to main content

You Can Send Email. But Can You Reply?

· 5 min read
Yopie Suryadi
Founder, mailbot

A customer gets your automated receipt. They reply with a question. "Can I change my shipping address?"

Your app has no idea that reply exists. The email went out through an API that only moves in one direction. Send. Done. Goodbye.

Outbound is the easy part​

Every email provider on the market lets you send. You compose a message, call an endpoint, and the email lands in someone's inbox. That part works.

The problem starts when someone replies.

Most email APIs treat sending as the entire job. They give you a send endpoint, a delivery status, maybe an open or click event. But when the recipient hits "Reply," that message goes to a black hole. Or it bounces. Or it lands in a shared inbox that nobody monitors.

This is not an edge case. For transactional email, replies are the norm. A customer gets an order confirmation and asks about delivery. A user receives a password reset and replies saying they did not request it. A client gets an invoice and responds with a dispute.

These replies are not spam. They are the most important emails in the thread. And your system cannot see them.

Why "no-reply" is a product failure​

The industry workaround is the no-reply@ address. Do not reply to this email. This address is not monitored.

From an engineering perspective, this makes sense. You do not have an inbound endpoint. You cannot process replies. So you tell users not to send them.

From a product perspective, this is a surrender. You are telling your users that your system cannot have a conversation. That your software is capable of talking but not listening.

Users ignore the instruction anyway. They reply to no-reply addresses constantly. Support teams know this. They see the bounce notifications pile up. They know customers are trying to reach them through the channel the business initiated.

The no-reply pattern does not solve the reply problem. It hides it.

What a reply actually requires​

Replying to an email is not the same as sending a new message to the same person. A proper reply needs to maintain context.

Threading headers. The reply must include an In-Reply-To header pointing to the original message's Message-ID, and a References header that chains the full conversation history. Without these, the reply shows up as a separate conversation in the recipient's inbox. The thread breaks.

Subject line continuity. The subject must match the original, prefixed with Re:. Change even one character and some email clients will break the thread.

Quoted content. Most email clients expect the original message to be quoted below the new reply. Without it, the recipient loses context. They see a response without knowing what it refers to.

Sender identity. The reply should come from the same address that sent the original message. If the original came from support@yourapp.com but the reply comes from noreply@mail-provider.net, the recipient sees a stranger in their inbox.

Building all of this by hand means parsing MIME headers, managing message IDs, handling character encoding, and reconstructing thread chains. For every single reply. It is the kind of work that seems simple until you discover that Gmail, Outlook, and Apple Mail all handle threading slightly differently.

The two-way gap​

The real issue is architectural. Most email APIs were designed as one-way pipes. Messages flow out. Nothing flows back.

When you need two-way email, you end up building a parallel system: an inbound email processor that receives messages via SMTP or forwarding rules, parses the MIME structure, extracts the body and attachments, matches the incoming message to the original thread, and triggers the appropriate workflow.

That is not a feature request. That is an infrastructure project. And it sits outside the scope of most email APIs entirely.

Some teams build it. They spend weeks wiring together an inbound processor, a thread matcher, and a reply composer. It works, mostly, until edge cases start appearing. Forwarded messages. Inline images. Multipart MIME bodies where the plain text and HTML versions disagree. Calendar invites nested inside replies.

Most teams do not build it. They put up the no-reply wall and move on.

Replies as a first-class operation​

mailbot treats reply as a native operation because email is not a broadcast medium. It is a conversation medium.

When you send a message through mailbot, the thread is already tracked. Every message has a message ID, a thread reference, and a full event timeline. When a reply comes in, mailbot matches it to the original thread automatically. No MIME parsing on your end. No header management. No thread reconstruction.

import { MailBot } from '@yopiesuryadi/mailbot-sdk';

const mailbot = new MailBot({ apiKey: process.env.MAILBOT_API_KEY });

// Send the original message
const message = await mailbot.messages.send({
  inboxId: 'inbox_support',
  to: 'customer@example.com',
  subject: 'Your order has shipped',
  body: 'Your package is on the way. Expected delivery: March 20.'
});

// Later, reply in the same thread
await mailbot.messages.reply({
  messageId: message.id,
  body: 'Tracking number has been updated. Here is your new ETA: March 19.'
});

The reply carries the correct headers, maintains the thread, and arrives in the recipient's inbox as part of the same conversation. The recipient sees one continuous thread, not two disconnected emails from different senders.

Inbound replies from the recipient trigger event notifications on the same thread. Your application receives the reply with full context: who sent it, which thread it belongs to, and the parsed body content. No forwarding rules. No separate inbound processor.

Email is not a monologue​

The gap between "send" and "converse" is the gap between a notification tool and a communication tool. If your system can send but cannot reply, you are using email as a one-way loudspeaker. Your users will try to talk back anyway. The question is whether your infrastructure is listening.