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

Under Inbound → Setup & test → Use your built-in Email Bump address, click Send test email. This checks the built-in address only, not receiving on your own domain. Success appears only when that exact test email arrives.

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

Sending and receiving need separate DNS records. Verifying a sending domain does not enable incoming mail. The Domains page shows both statuses; choose Set up receiving to open that domain's setup. Under Inbound → Setup & test → Receive on your own domain, select a domain you've already verified for sending.

01
Add the receiving DNS record
Copy the MX type, host/name, mail server, and priority into your DNS provider.
02
Check receiving DNS
This verifies the MX record. If the lookup cannot complete, retry; it does not mean your records are missing.
03
Send test email
The test goes to a unique address on the selected custom domain. The page confirms Test email received only after that message arrives, with a link to open it. After two minutes without delivery, you can check for delayed delivery again or recheck DNS and send another test.

You can also send a message from Gmail or another mailbox to the example address. The inbox refreshes while the page is open.

Email notifications

The setup shows your Received email notification preference and links to Settings → Email notifications. New incoming mail emails project members by default, unless they turn it off; automatic replies and bounces are excluded. Domain ownership verification emails the owner and explains the separate receiving setup. Receiving DNS verification itself is confirmed on screen, not by a separate email.

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.