ReceiveHQ

Guides

What is inbound email processing?

Inbound email processing turns SMTP messages addressed to your domain into structured data your application or AI agent can use — usually via an inbound email to webhook HTTP POST, or by storing mail for API/MCP reads.

Guide · inbound email processing · ReceiveHQ

Definition

Unlike outbound (transactional) email, inbound processing receives mail: invoices to ap@yourdomain.com, support aliases, bounce parsers, or vendor notifications. The processor accepts SMTP, parses MIME (headers, plain/HTML bodies, attachments), and delivers a normalised payload to your stack.

Typical pipeline

  1. DNS — MX records for your domain point at the inbound provider.
  2. SMTP accept — mail is received, optionally filtered (RBL / spam score).
  3. Parse — MIME becomes fields + attachment blobs.
  4. Deliver — HTTPS webhook POST, object store, or agent-readable inbox.
  5. Retry / evidence — failed deliveries retry; raw .eml retained for support.

ReceiveHQ runs this pipeline on infrastructure hosted in Germany.

Webhook vs blackhole

Webhook endpoints POST parsed mail to your HTTPS URL in a provider format (Postmark JSON, Mailgun/SendGrid multipart, CloudMailin JSON).

Blackhole endpoints store mail without forwarding (status blackholed). Useful when Cursor or Claude reads messages via MCP list_messages instead of HTTP callbacks — see the MCP inbound guide.

Common payload formats

Many apps already speak a vendor’s inbound shape. ReceiveHQ reuses those contracts so you can switch MX without rewriting parsers:

Field reference: Webhook API docs.

Why a dedicated inbound service

  • Avoid DIY SES receipt rules + SNS + Lambda for every domain
  • Clear data residency when GDPR Article 44 transfers matter
  • Inbound-only pricing instead of outbound-tied plans
  • Agent-native setup via MCP when humans should not click the console

Next steps

Try ReceiveHQ · Inbound email and GDPR · MCP inbound email · Provider alternatives