# 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 project** — works immediately, no DNS to set up.
- **A webhook on arrival** — your app hears about mail in seconds.
- **Body and files over the API** — attachments come back as the bytes that were sent.
- **Scanned before you see it** — viruses dropped, spam flagged, SPF/DKIM/DMARC checked.

## Your address

Open **Inbound** in the dashboard and your project's address is at the top:

```
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.

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

1. **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.
2. **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.
3. **Your webhook fires** — a signed `email.received` event with the metadata and the attachment list, enough to decide whether you care. [Set one up](https://emailbump.com/docs/webhooks-api).
4. **Your code fetches what it needs** — the body and the files come from the [Inbound API](https://emailbump.com/docs/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](https://emailbump.com/docs/domains) — 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.

## 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.