Features
Inbound email on your own domain
Receive mail, drive reply workflows, and keep send plus receive on one platform — without bolting on a second inbound vendor.
- MX on a subdomain
- email.received webhooks
- API + dashboard access
Why enable it
Replies belong next to your sends
One account, one set of domains, and one place to see the whole conversation.
Reply workflows
Support and product replies land in the same account that sends your transactional mail.
Instant webhooks
email.received fires into your app the moment mail arrives, signed like every other event.
API + dashboard
List and fetch received messages via the API, or scan them in the Inbound dashboard.
Attachments
Retrieve attachment metadata and content for the messages you receive.
How it works
Four steps to receiving mail
Use an inbound subdomain so MX records never collide with your primary mailbox provider.
- 1
Verify a domain
Add and verify your sending domain, then enable inbound on a subdomain.
- 2
Publish MX
Add the MX records SuperSend TX shows you for that inbound subdomain.
- 3
Subscribe
Point a webhook at email.received, or poll GET /received-emails.
- 4
Handle replies
Route mail into your product logic and inspect traffic in the dashboard.
Payload
A webhook you can wire up in minutes
Inbound events use the same signing and delivery model as your outbound delivery events.
- Signed with your whsec_… endpoint secret
- SDK helpers verify signatures for you
- Same account isolation as sending
email.received
{
"type": "email.received",
"data": {
"id": "rcv_abc123",
"from": "[email protected]",
"to": "[email protected]",
"subject": "Re: Your receipt",
"text": "Can I get a VAT invoice?"
}
}- · GET /received-emails to list
- · GET /received-emails/{id} for detail
Turn on inbound for your domain
Verify a domain, publish MX, and start receiving on the same account you already send from.
Keep reading