Question 1

What is inbound email parsing and what is it used for?

Accepted Answer

Inbound email parsing is the practice of accepting incoming SMTP traffic on your domain (or a subdomain), parsing the MIME content into structured data, and delivering it to your application as a JSON webhook. Typical use cases: **support inbox automation** (parse customer reply emails into ticket creation), **sales lead capture** (forward leads@yourcompany.com into your CRM as structured records), **reply handling on transactional sends** (capture reply-to addresses on automated emails and route the text content back to your application), **email-to-API integrations** (let users interact with your product by sending email — adding a note to a project, creating a task, etc.). The Inbox OSS inbound parse endpoint replaces self-hosted Postfix and custom MIME-parsing code with a managed JSON-webhook API.

Question 2

How do I set up inbound email parsing?

Accepted Answer

Setup is three steps: (1) point an MX record for your inbound domain or subdomain (commonly inbound.yourcompany.com) at mx.inbox.onesourcesoft.com with priority 10; (2) configure a parse route in the dashboard mapping the inbound domain or pattern (support@*, sales@inbound.yourcompany.com, etc.) to a webhook URL you control; (3) implement a JSON-receiving endpoint that handles the parsed payload. End-to-end setup takes 5-10 minutes, less than half the time of the SendGrid Inbound Parse equivalent because we co-host the authoritative DNS for your MX target and verify resolution automatically before activating the route.

Question 3

What does the parsed email JSON payload look like?

Accepted Answer

Every parsed email is POSTed as a structured JSON payload with these top-level fields: **headers** (object with all RFC 5322 headers), **from** and **to** (parsed address structures with display name and email), **subject**, **text** (plain-text body), **html** (HTML body), **attachments** (array with filename, MIME type, size, and signed CDN URL or inline base64 content depending on configuration), **authentication_results** (DMARC, SPF, DKIM verdicts and details), **spam_report** (SpamAssassin score and per-rule breakdown), **received_at** (Unix timestamp), and **message_id** (unique per inbound). The schema is fully documented as JSON Schema for type-safe handler generation in any language.

Question 4

How are attachments handled?

Accepted Answer

Attachments are extracted from MIME and **stored on our CDN** by default. The payload includes a signed URL for each attachment with a 7-day expiry — your handler downloads the bytes when needed without our system having to push large binary blobs into your webhook. For attachments you need synchronously (image previews, small documents), you can switch to **inline base64 mode** per route, which embeds the bytes directly in the JSON payload (subject to a 25 MB combined payload limit). The CDN-storage mode is the right call for support workflows where attachments might be large screenshots or PDFs; inline mode is the right call for high-frequency low-size attachments like invoice PDFs.

Question 5

Does the parser include DMARC, SPF, and DKIM authentication results?

Accepted Answer

Yes. The authentication_results object on every parsed payload contains the full DMARC verdict (pass/fail/none with policy reason), SPF result (pass/fail/neutral/none/permerror/temperror with the sending IP that was checked), and DKIM result (pass/fail with the signing domain and selector). These verdicts are the same ones a mail server would compute on receive — you can implement trust scoring in your application logic based on whether the inbound passed authentication, since spoofed emails to your inbound endpoint are detectable by these signals. **This is materially better than SendGrid Inbound Parse, which does not surface DKIM details at all.**

Question 6

Can I route different inbound addresses to different webhooks?

Accepted Answer

Yes. The route configuration supports **per-domain and per-local-part routing** with pattern matching: support@inbound.yourcompany.com to one URL, sales@inbound.yourcompany.com to another URL, *.replies@ to a reply-handler URL, and a catch-all to a fallback. Routes are evaluated in priority order and the first match wins. This lets you split inbound traffic by department or workflow without standing up multiple inbound infrastructures. For multi-tenant SaaS use cases where each customer gets a unique inbound address, the dashboard supports programmatic route creation via API so you can provision a customer-specific inbound webhook at signup time.

Question 7

How does spam scoring work for inbound messages?

Accepted Answer

Every inbound message is scored with **SpamAssassin** and the resulting score and per-rule breakdown is included in the parsed payload. Scores above 5.0 are typically spam; scores above 10.0 are almost certainly spam. You can configure the route to either pass all messages through and let your application decide what to do, or drop messages above a configurable threshold so your webhook only receives clean inbound. The route configuration also supports header-based filters (drop if X-Spam header present, drop if SPF=fail, etc.) for additional pre-filtering before your webhook handler is invoked.

Question 8

How does reply threading work?

Accepted Answer

When recipients reply to your transactional emails, the reply typically includes quoted content from the original message ("On Mon, March 15, Ada wrote: > Hi there..."). The parser uses a heuristic stripping engine to **separate the new reply content from the quoted history and the signature block**, then surfaces three fields: text_new (just the new content the recipient wrote), text_quoted (the quoted history), and text_signature (the detected signature). This makes building reply-handling workflows dramatically simpler — your ticketing system gets the customer's new message without having to strip noise. The heuristic handles Gmail, Outlook, Apple Mail, and Yahoo reply conventions out of the box and degrades gracefully on unrecognized clients.

Question 9

How does Inbox OSS inbound parse compare to SendGrid Inbound Parse and Mailgun Routes?

Accepted Answer

All three accept SMTP on a configured MX target and deliver parsed JSON to a webhook. Inbox OSS has structural advantages on three dimensions: (1) **DKIM details are surfaced in the payload** (SendGrid does not include them); (2) **per-domain routing supports pattern matching** out of the box (Mailgun Routes requires per-route configuration for each pattern, which becomes operationally painful at scale); (3) **the parsed payload includes spam_report with full rule breakdown** rather than just a single score. Pricing is also bundled — inbound parse is included in every paid plan rather than billed separately like Mailgun Routes.

Question 10

What rate limits and volume capacity does the inbound endpoint support?

Accepted Answer

The MX target accepts SMTP submissions at production scale — internal benchmarks show **sustained 10,000+ inbound messages per minute per account** with no degradation. Inbound messages are queued, parsed, and webhook-delivered with sub-2-second median latency from MX receive to webhook POST. If your downstream webhook returns non-2xx, retries follow the standard exponential-backoff schedule for 24 hours, identical to outbound event webhooks. There is no per-message charge for inbound parse on any paid plan; the Free tier includes 1,000 inbound messages per month.

Receive email as JSON via webhook

Full MIME parsing

Attachments

Authentication results

Spam scoring

Per-domain routing

Reply threading

Frequently asked questions about inbound email parsing

Start sending email in under 5 minutes.