Inbound email: replies to campaigns

When a recipient hits Reply on a campaign email, the reply comes back to WeZend and lands in the Inbox — threaded onto the same conversation as everything else you have sent that address, and correlated to the exact campaign and the exact message that was replied to. Email becomes two-way, the way SMS and WhatsApp already were.

How the correlation works

Every campaign email is stamped with a per-message Reply-To of the form reply+<message-id>@reply.yourdomain.com (VERP). The token is the message's own UUID, so when the reply arrives nothing is guessed from address and recency: the id resolves deterministically to one customer, one campaign and one original message.

Two rules keep this predictable:

• Only campaign sends are stamped — a transactional POST /v1/messages/send is left alone.
• An explicit reply_to on the send always wins. Set it and WeZend does not touch it, so the reply goes to your own mailbox instead and nothing lands in the Inbox.

What happens to a reply

1. The receiving transport parses the MIME message and POSTs it to POST /v1/webhooks/inbound-email — shared-secret authed, the same convention as the delivery-report webhooks.
2. The reply is queued for durable processing and deduplicated on its Message-ID, so a provider that re-POSTs the same mail cannot create a second copy. If the queue is unavailable the webhook processes the reply inline rather than dropping it, and the endpoint always answers 2xx so the provider never hard-retries.
3. The reply is threaded into the conversation for that address and stored with its subject, HTML body, the SPF/DKIM/DMARC verdicts and the id of the campaign it answers.
4. A message.received platform event fires, so your CRM or help desk gets the reply without polling. If you have set an inbound webhook URL, the reply is forwarded there too.

What is dropped before it reaches you

• Spam and authentication failures — a spam score of 8 or above, or a DMARC fail, is quarantined and never becomes a contact or a conversation.
• Auto-responders — anything carrying an Auto-Submitted header other than no (vacation replies, ticket acknowledgements) is ignored, so replies cannot loop.
• Unattributable mail — a reply address with no valid message token, or a token that matches no message, is refused rather than guessed at.

A reply that is just STOP (or unsubscribe, afmeld, framelding …) is handled as an opt-out before it becomes a support ticket: the address goes on the suppression list, a consent record is written, and contact.unsubscribed fires — see Consent.

Attachments are stored per reply: JPEG, PNG, GIF, WebP and PDF, up to 15 MB per file and 20 files per message. Other content types are recorded as skipped rather than saved.

Turning it on

Inbound email stays dormant until an operator configures it — there is no toggle in the dashboard, because it needs DNS. The setup is one MX record on a dedicated reply subdomain (for example reply.yourdomain.com) pointing at the receiving transport, plus that domain set on the backend. Your apex domain's existing MX is untouched, so this does not disturb wherever your company mailboxes live today.

In practice that is SendGrid Inbound Parse: the reply subdomain's MX points at it, it evaluates SPF, DKIM and DMARC, and it posts the parsed message to the ingestion endpoint. Your DNS stays wherever it already is — the record is one MX on a subdomain, not a migration.

The transport is deliberately kept at arm's length: the ingestion endpoint normalises whatever it receives into one internal payload, so swapping or adding a receiving provider is a mapper, not a rewrite. Outbound setup is unchanged — see Email: domains, DNS & sending.