DOCUMENTATION

Multiple sender identities

Last updated Aug 2026
Email
All plans

By default, every automated email your store sends — order confirmations, shipping notices, campaigns, welcome emails, Domain Inbox replies — goes out from the single Default sender you set up when you connected Resend. Sender identities let you add more named “From” addresses on the same connection (e.g. orders@, support@, hello@) and control which one each type of email actually sends from, without connecting a second Resend account.

This is a Resend feature, not a mailbox feature — see Setting up email (Resend) first if you haven’t connected Resend yet. Everything below happens in the same place, Settings → Email, one panel further down.

One connection, several names

It’s easy to assume “adding a sender” means a second Resend account, a second API key, or a second billing relationship. It’s none of those. A sender identity is a name + email address layered on top of the one Resend connection and the domain(s) you’ve already verified there — plus, per identity, its own optional auto-reply and email signature, so support@ and orders@ don’t have to share the same reply text or sign-off.

What it is
Default senderThe one address set up during Resend connect. Every automated email uses this unless a purpose (below) is pointed at a different identity.
Sender identityAn additional name + address on the same connection — e.g. a “Support” identity at support@yourdomain.com. Doesn’t require its own API key or its own domain verification if it shares a domain you’ve already verified.
An identity’s domain still has to be verified in Resend to actually send. If you add an identity on a domain you haven’t verified yet, it saves fine but shows an amber “Domain not verified in Resend — sends may fail” note next to it — that’s not a bug, it’s telling you the identity exists but can’t send until that domain is verified (see adding and verifying a sending domain).

Adding a sender identity

1
Open Settings → Email, scroll to Sender identities

This section sits directly below the “Sending from” (Default) card in the connected Resend panel — it only appears once Resend is connected.

2
Click Add

Three fields appear inline: a short internal Label (e.g. Support — this is just for your own reference, recipients never see it), a Display name (what shows in the recipient’s inbox, e.g. My Store Support), and the email address itself.

3
Save

The identity appears in the list immediately. There’s no separate verification step for the identity itself — only the underlying domain needs to be verified in Resend.

Sender identities — example
Support — My Store Supportsupport@mystore.com
Orders — My Store Ordersorders@mystore.com

Pointing email types at an identity

Adding an identity doesn’t change anything by itself — nothing switches senders automatically. Below the identities list is a Default senders section with one dropdown per automated email type; each one defaults to blank (meaning “use the Default sender”) until you point it at an identity.

PurposeCovers
Orders & shippingOrder confirmation and shipping-notification emails from Product CMS purchases.
CampaignsBulk sends from the Campaigns tab.
Welcome emailsSent when someone joins an Email Signup Form list.
BookingBooking confirmation and reminder emails from the Booking Calendar block. Falls back to the Orders & shipping identity, then Default, if left unset.
A common setup: leave Default as your general hello@ address, point “Orders & shipping” at an orders@ identity, and leave Campaigns/Welcome/Booking on Default. Each dropdown is independent — you don’t have to fill in all four.

Default templates — what the email says

The purposes above control who an email sends from. A separate “Default templates” picker, right below Default senders in the same panel, controls what it says: order confirmation, shipping notification, booking confirmation, and booking reminder can each be pointed at one of your own saved templates from the Templates tab instead of the built-in design. Leaving one unset keeps the original hardcoded design — nothing changes until you assign one.

If the template you assign is missing a merge variable the email needs (e.g. an order-confirmation template with no {{orderNumber}}), the send falls back to the built-in design rather than mailing a broken subject line or body — it fails safe, not silently.

Sending as an identity from the Domain Inbox

If you’ve enabled receiving (see Enabling receiving), the Domain Inbox tab's compose and reply forms both have their own From dropdown listing your Default sender and every identity — independent of the purpose assignments above. This is a per-message choice, not a saved setting.

Replying to a thread
The From field pre-selects whichever identity that specific thread's traffic matches, if one does — you can still override it before sending.
Composing new
The From field starts on your Default sender. Pick a different identity from the dropdown before sending if you want the message to come from e.g. support@ instead.

Auto-reply, per identity

Each identity can have its own automatic reply, sent once per new inbound thread to that specific address — a customer emailing support@ and one emailing orders@ can get two entirely different auto-replies, instead of one shared message for the whole account. Toggle it on for an identity, then either write a plain message or point it at a saved template (same fallback behavior as default templates above — an incompatible template falls back to the plain message rather than sending something broken).

Auto-reply won’t create a reply loop with another automated sender — it stops after one hop rather than replying to its own replies back and forth. It also skips obviously-automated senders (addresses that look like notifications@, noreply@, etc.) so you don’t accidentally auto-reply to a system notification.

An inbound thread that doesn’t match any named identity’s address falls through to the Default identity’s own auto-reply setting, configured in the same “Sending from” card as your Default sender.

Email signature, per identity

Separately from auto-reply, each identity can have its own signature — auto-appended to every Domain Inbox reply and compose sent from that identity, the same way Gmail or Google Workspace appends a signature. Toggle it on and write the signature HTML; it’s inserted below your message body on send, not stored as part of the message you type.

The Gmail tab (and its own separate signature setting) is currently unavailable — send everything through Domain Inbox and a sender identity for now.

Removing an identity

Click the × next to an identity in the list to delete it. Any purpose dropdown pointed at that identity falls back to the Default sender automatically — it doesn’t leave that email type broken or unset.

Troubleshooting

SymptomWhat it means
New identity shows "Domain not verified in Resend — sends may fail"The identity saved correctly, but its domain (the part after the @) hasn't been verified in Resend yet. Verify it the same way you verified your first sending domain, then the warning clears on its own.
Order confirmations still arrive from the old address after adding an "Orders" identityThe identity alone doesn't redirect anything — you also need to point the "Orders & shipping" purpose dropdown at it.
Deleted an identity and a purpose dropdown now shows "Default"Expected — deleting an identity that was assigned to a purpose resets that purpose to Default rather than leaving it broken.
Identity dropdown in Domain Inbox compose is emptyNo identities have been added yet — this dropdown always includes Default, so if it looks empty rather than showing just Default, check that Resend itself is connected.
Running a Business-plan reseller account with team members? You can restrict a team member to exactly one (or a few) of these addresses in the Domain Inbox — see Team members & client access.