Create and send

Receiving email

Give a project an address, and turn what people send you into something your app can act on.

What you get

Sending is half a conversation. Receiving is the other half: an address that accepts mail, and a way for your application to do something with what arrives — a support reply, a forwarded invoice, a photo of a damaged order.

An address per projectWorks immediately, no DNS to set up.A webhook on arrivalYour app hears about mail in seconds.Body and files over the APIAttachments come back as the bytes that were sent.Scanned before you see itViruses dropped, spam flagged, SPF/DKIM/DMARC checked.

Your address

Open Inbound in the dashboard and your project's address is at the top. It looks like this:

Your inbox address

anything@<project-slug>.inbound.emailbump.com

The part before the @ is yours to invent. support@, replies@, and order-4821@ all arrive at the same place, with nothing to create first — there is no such thing as an address on that domain that doesn't exist. Use different ones to tell apart what arrives, then read the received_for field to see which was used.

Send it a test

The Inbound page has a Send a test email button. It mails your own address and shows you the message landing, so you can confirm receiving works before writing any code.

What happens to a message

01
We check it
Viruses, spam, and the SPF, DKIM and DMARC signatures. A message carrying a virus is dropped and never reaches you; spam arrives flagged, because one product's junk is another's signal.
02
We read and store it
Sender, recipients, subject, both bodies, and every attachment. It's saved before anything else happens, so nothing is lost if your server is down.
03
Your webhook fires
A signed email.received event with the metadata and the attachment list — enough to decide whether you care. Set one up.
04
Your code fetches what it needs
The body and the files come from the Inbound API when you ask for them, which keeps deliveries small and replayable.

Using your own domain

To receive at your own address instead, add an MX record to the domain you want to receive on. It has to be a domain you've already verified for sending — that's what proves it's yours. The Inbound page has the record and a Check DNS button that tells you whether it's live yet.

An MX record moves all mail for that name

If the domain already receives email — Google Workspace, Outlook, anything — put the record on a subdomain like inbox.yourdomain.com. Adding it to a domain that already has mail will redirect your own email here.

Forward it to a real inbox

Not everything needs code. Under Inbound → Forwarding, name an address you already read and every message that arrives is sent on to it — attachments, embedded images and all — while still being stored here.

Point a rule at one address (support@…) or leave it blank for everything the project receives.
Spam is left out unless you ask for it.
The copy comes from your own sending address with Reply-To set to whoever wrote it, so replying reaches them rather than you.
Rules can't loop. Our copies carry a hop count and stop after three, an address that receives mail here is refused as a destination, and automatic mail — out-of-office replies, bounces, mailing-list posts — is never forwarded, because that is what turns two mail systems into a ping-pong match.

To send a single message on instead, open it and use Forward — or call the API from your own code.

Replies to no-reply

When someone replies to a message you sent from the shared sending domain, the address they reply to is the same one every project uses — so the address alone can't say whose it is. We read the reply's headers instead, match it to the message it answers, and file it with the project that sent the original.

Mail we can't place at all — cold email to that address, or a domain pointed here before it was verified — isn't delivered to anyone. If a message you expected never arrived, that's worth asking us about.