From and Reply-To Strategy for App Email: noreply@ vs support@

Most apps pick one sender address on day one, usually noreply@, and never think about it again. Then customers reply to a receipt with a question, the reply bounces, and the ticket arrives three days later by another route, angry. A sender strategy is a small table: which address sends which kind of email, and where replies to each one go. Here is how to build that table and set up the mailboxes behind it.

Quick answer

Use a handful of purpose-named addresses on your own domain (orders@, billing@, security@, notifications@, support@), send each email type from the matching one, and make every one of them a real mailbox that a person or a shared inbox reads. Reserve noreply@ for the rare message where a reply is genuinely meaningless, and even then keep support@ visible in the body.

The address table

• orders@ for order confirmations and shipping updates. Replies are address changes and questions about items; route to the support inbox.
• billing@ for invoices, receipts, renewal and dunning emails. Replies are remittance advices and "please update my company details"; route to finance.
• security@ or login@ for codes, magic links, password changes and new-device alerts. Replies are locked-out users; route to support with priority.
• notifications@ for mentions, comments and digests. Replies are often answers to the comment; route to support or, later, to a reply-by-email parser.
• alerts@ for monitoring mail sent to your own team; replies go to the ops inbox.
• hello@ or team@ for founder notes and onboarding messages; replies go to whoever wrote them.
• support@ everywhere in footers, so the customer always has a human path.

What noreply@ actually costs

A noreply@ address does three things, all bad. It bounces replies, which loses the question and annoys the customer. It signals low engagement to mailbox providers, because nobody ever writes back to it, and reply behaviour is one of the signals Gmail uses to decide whether your domain is worth the inbox. And it invites people to add the address to their contacts less often, which is a small positive signal you forfeit. There is one legitimate use: automated mail where a reply cannot be actioned and you already tell the reader where to go instead. Even then, the from name should be your brand and the body should include support@.

How replies work in practice

A reply goes to the Reply-To address if the message has one, otherwise to the From address. The simplest strategy needs no Reply-To at all: send from orders@ and make orders@ a real mailbox. If you must send from an address that is not a mailbox, set the from address to one that is. With OquMail, every address on the domain can be a mailbox on the free plan (up to 15), so orders@, billing@ and support@ can each be a real inbox, or aliases that a shared support mailbox reads in webmail or in any IMAP app. The API key you send with is created from a mailbox, so the from address and the inbox that receives replies are the same thing.

The request, per email type

The only thing that changes between email types is the from address and the content. Keep the mapping in one place in your code so nobody sends a receipt from notifications@:

const SENDERS = {
  order: "orders@yourdomain.com",
  billing: "billing@yourdomain.com",
  security: "security@yourdomain.com",
  notification: "notifications@yourdomain.com"
};

async function sendAppEmail(type, to, subject, html, text) {
  const res = await fetch("https://api.oqumail.com/api/v1/emails", {
    method: "POST",
    headers: { "Authorization": "Bearer " + process.env.OQUMAIL_API_KEY, "Content-Type": "application/json" },
    body: JSON.stringify({ from: SENDERS[type], to, subject, html, text })
  });
  if (!res.ok) throw new Error("send failed: " + res.status);
}

From names

• Brand name for transactional mail: "Acme Orders", "Acme Billing". Consistent and recognisable in a crowded inbox.
• Person via brand for conversational mail: "Jane at Acme" or "Jane via Acme". Never a bare personal name from a shared address.
• The same from name and address for the same email type every time. Changing senders looks like a phishing attempt to both people and filters.
• No emoji, no "Do Not Reply" as the name.

Setting it up

1. Create the mailboxes or aliases on your domain: orders@, billing@, security@, notifications@, support@.
2. Decide who reads each one, and set up forwarding or a shared inbox where a team needs it.
3. Generate API keys from the sending mailboxes and store them per environment.
4. Put the sender mapping in code as above and refuse to send an email type from the wrong address.
5. Check the delivery log after the first sends of each type to confirm they were accepted, and reply to one of your own test emails to confirm the reply lands in the right inbox.

Common questions

Can I use one address for everything?

You can, and small products often start with hello@ for all mail. Split at least security@ out early, because users should be able to trust that address specifically.

Should replies go to a ticketing system?

If you use one, forward support@ into it. The email still comes from and replies to a real address on your domain; the tool just reads the mailbox.

Does a subdomain like mail.yourdomain.com help?

Some large senders separate marketing onto a subdomain so its reputation is isolated. For transactional mail from a small app, the root domain with proper DKIM is simpler and more trusted by recipients.