Inbound email / receiving
Receiving is the other half of an email API. Mail addressed to your domain arrives, is parsed into headers, text, HTML and attachments, and is handed to your code. It turns an address into an endpoint, which is how support inboxes, reply handling and forward-this-to-the-app features get built without anybody running a mail server.
At a glance
- Category
- Interfaces
- Enabled by
- An MX record pointing at the receiving service
- Delivered as
- A webhook carrying the parsed message
- Includes
- Headers, text and HTML parts, and an attachment list
- Threading uses
- The Message-ID, In-Reply-To and References headers
How it works
You publish an MX record for a name you control, pointing at the receiving service. Mail addressed to anything at that name is then delivered there rather than to a mailbox. The service accepts the message, parses it into its parts — the envelope, the headers, the text and HTML bodies, each attachment — and posts the result to your endpoint as a signed webhook. Attachments are usually referenced by a link rather than inlined, so a large message does not become a large request.
Why it matters
A surprising amount of product work is really inbound mail: replies that should land on a support ticket, documents forwarded into an application, addresses that act as a command. Doing that without a receiving API means running a mail server, which means spam filtering, MIME parsing and uptime for a service whose only job is to hand messages to your code. Receiving as an API keeps the same shape as sending, so one set of webhooks covers both directions.
Example
A team points the MX record for a support subdomain at the receiving service and subscribes to the received event. A customer replies to a notification, and the reply arrives as a webhook with the parsed text, the original message identifier in its references header and a link to the screenshot they attached. The application matches the reference to a ticket, appends the reply and downloads the attachment.
Common mistakes
- 01Pointing the MX record at the root of a domain whose staff mailboxes live there, which redirects everybody's mail at once.
- 02Trusting the From header to identify the sender, when only authentication results say anything about who really sent it.
- 03Ignoring the threading headers and matching on the subject line, which breaks as soon as somebody edits it.
- 04Processing the webhook slowly and answering late, so the delivery is treated as failed and the same message arrives again.
In Rasket
Point one MX record at us, subscribe to the email.received event, and each message arrives as a webhook carrying the envelope and the attachment list. Receiving
Related terms
Frequently asked questions
Do I need a separate domain to receive mail?
No, but a subdomain is the usual choice. Changing the MX record at the root of a domain moves every address there at once, which is rarely what a team intends.
How are large attachments handled?
Normally by reference: the webhook names each attachment and gives you a link to fetch it, so the request stays small. That also lets you skip downloading files your application does not need.
Can I reply from the same address?
Yes, provided the domain is also verified for sending. Setting the In-Reply-To and References headers from the incoming message is what makes the reply thread correctly in the recipient's client.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.