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.

support@your-project.inbound.emailbump.com
replies@your-project.inbound.emailbump.com
order-4821@your-project.inbound.emailbump.com

# 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": "jamie@example.com",
      "to": ["support@your-project.inbound.emailbump.com"],
      "received_for": "support@your-project.inbound.emailbump.com",
      "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

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