# Inbound mail becomes a webhook with a verdict

> Receive email at your domain and get a full parse by webhook: routing by address, SPF, DKIM, and DMARC verdicts, and reply classification built in.

Canonical: https://emailfast.dev/features/inbound

## From mailbox to webhook

Inbound email parsing turns mail sent to your domain into a structured
`email.inbound` webhook: the full parsed message, routed by the address it arrived
at, with SPF, DKIM, and DMARC verdicts attached. Your code handles a JSON object,
not MIME.

## How it works

1. Point mail for your domain — most teams start with a subdomain — at us, and define routes by address.
2. Each message is fully parsed and authenticated: SPF, DKIM, and DMARC verdicts ride along on the event.
3. Reply intelligence classifies what the message actually is: an out-of-office, an unsubscribe request written in prose, a complaint, or a genuine lead.
4. Per route, opt in to auto-honoring written unsubscribe requests — "please take me off this list" suppresses the sender without a human in the loop.

Bounce, complaint, and report mailboxes are handled automatically — the postmaster
plumbing every domain is supposed to have, without you building it.

## The evidence

:::panel What your endpoint receives (abridged)
```json
{
  "type": "email.inbound",
  "data": {
    "route": "support@yourdomain.com",
    "from": "ada@example.com",
    "subject": "Re: your invoice",
    "auth": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
    "classification": "genuine_lead"
  }
}
```
The full parsed content rides along too — the abridgment here is ours, not the
payload's.
:::

## Honest limits

:::tradeoffs Classification is a judgment, not a fact
The classifier reads prose, and prose is messy: expect occasional misreads. That's
why auto-honoring unsubscribe requests is opt-in per route, and why the complete
parsed message always accompanies the classification — your handler can overrule it.
Authentication verdicts are reported, not enforced: a DMARC `fail` is attached for
your logic to act on, because silently dropping mail is how support threads vanish.
:::

## Where to go next

Inbound events arrive over the same [signed webhooks](/features/webhooks) as
outbound events. Classified replies can drive [automations](/features/automation) —
a genuine lead enters a journey, an out-of-office doesn't. The full payload reference
lives behind the [developer door](/developers), and if you run inbound routes on
Mailgun today, the [comparison](/compare/mailgun-alternative) covers the switch.

## How is inbound mail routed?

By the address it arrived at — support@ , orders@ , and so on each map to their own route, and the route rides along on the email.inbound event so your handler knows which door the message came through.

## Do you verify SPF, DKIM, and DMARC on inbound mail?

Yes. Each message is authenticated and the verdicts are attached to the webhook payload, so your code can treat a dmarc: fail differently from a clean pass without doing any of the verification itself.

## Can it unsubscribe people who reply "remove me" in plain prose?

Yes — reply intelligence recognizes unsubscribe requests written in prose, and you can opt in per route to auto-honoring them: the sender is suppressed without a human reading the message.

## What about bounce and abuse mailboxes?

Bounce, complaint, and report mailboxes are handled automatically — the postmaster plumbing every sending domain is supposed to have, without you wiring any of it.