Inbound email

An address that already works

Each project has its own receiving domain from the moment it exists. Anything before the @ arrives, so you can invent an address per purpose without creating anything first.

Prefer your own domain? Point an MX record at us and every address on it arrives the same way. We check the record for you before you go looking for mail that never came.

[email protected]
[email protected]
[email protected]

# all three arrive — nothing to set up per address

Mail becomes a webhook

When a message arrives we scan it for viruses and spam, check SPF, DKIM and DMARC, parse the MIME, and POST you a signed event. The body and any attachments come from the API when you want them, so the delivery stays small.

The message is stored before the webhook fires. If your server was down, nothing is lost — it's still there when you come back for it, and the delivery can be replayed.

{
  "type": "email.received",
  "data": {
    "email": {
      "id": "3de5e8ff-…",
      "from": "[email protected]",
      "to": ["[email protected]"],
      "received_for": "[email protected]",
      "subject": "Photo of the damage",
      "attachments": [
        { "filename": "photo.png", "content_type": "image/png",
          "content_disposition": "inline", "content_id": "photo001" }
      ],
      "spam": "PASS", "spf": "PASS", "dkim": "PASS", "dmarc": "PASS"
    }
  }
}

Attachments arrive as themselves

Photos, invoices, spreadsheets — download them by id and get back the bytes that were sent, with the original filename and type. Images the sender embedded in the message are marked as such, so you can render a message the way they wrote it.

Every download is served as an attachment, never rendered on our domain, because a file from a stranger is exactly that.

• Messages up to 40 MB, attachments included
• Virus-carrying mail is dropped before you ever see it
• Spam is flagged rather than hidden — you decide what it means

Or just send it to your inbox

Not every team wants to write a webhook handler on day one. Name an address you already read and every message that arrives is sent on to it — attachments, embedded images and formatting exactly as they were sent — while still being stored here for when you do build something.

The copy comes from your own sending address with Reply-To set to whoever wrote it, so replying reaches the customer and not us. Spam stays out unless you ask for it, and mail we forwarded is never forwarded again.

curl -X POST https://emailbump.com/api/v1/inbound/MESSAGE_ID/forward \
  -H "Authorization: Bearer ebk_your_key" \
  -H "Content-Type: application/json" \
  -d '{ "to": "[email protected]" }'

Replies find their way home

A customer replying to a no-reply address is the most common way email gets lost, because that address is the same for everyone. We read the headers of the reply, match it against the message it answers, and file it with the project that sent the original.

The sender has to be the person that message went to, so a message id someone happens to have seen isn't a way into anyone's inbox.

What you can build with it

• Support requests and replies arriving as structured data your app can act on
• Attachments — receipts, photos, documents — pulled straight into your product
• An address per customer, per order or per ticket, created by inventing it
• Replies to a no-reply address landing somewhere instead of nowhere
• Everything forwarded to an inbox you already read, with no code at all