What is inbound email processing?
Inbound email processing turns the email people and systems send you into structured data: a service receives the message, parses it, and posts it as JSON to a webhook in your application.
By Xander Groesbeek, founder · Published February 2026 · Updated October 2026 · 7 min read
In brief
The issue. Support requests, invoices, orders and alerts arrive as email, written for people. Software can't act on a raw message until someone, or something, turns it into data.
What it means for you. An inbound email processing service receives mail for an address you choose, parses sender, subject, body and attachments, checks who really sent it, and posts the result as JSON to your webhook. Your code or automation takes it from there.
What to do.
- Pick one stream of email you handle by hand today.
- Give it its own address or subdomain, and point that at a processing service.
- Choose the provider on data location, mailbox access, attachment limits and retries.
What is inbound email processing?
Inbound email processing is the automated handling of incoming email: converting messages from unstructured text into structured data that applications can act on. When an email arrives at a configured address, the processing service parses the headers, body and attachments, and delivers the result as JSON to a webhook: an HTTPS URL in your application that receives it.
It sits on the receiving side of email, which sets it apart from two things it is often confused with:
| Category | What it does |
|---|---|
| Inbound email processing | Receives email sent to you and turns it into data for your software |
| Outbound (transactional) email | Sends email from your software: notifications, receipts, password resets |
| Email marketing platforms | Manage subscriber lists, send campaigns and track opens |
If you want incoming support requests, invoices, booking confirmations or monitoring alerts handled without someone reading each one first, inbound email processing is the step that makes that possible.
How inbound email processing works
DNS sends the mail to the service, the service parses and checks it, and your webhook receives JSON. Step by step:
- 1
Configure DNS
Point the MX record of a subdomain (for example in.yourcompany.com) at the processing service.
- 2
Email arrives
Mail sent to support@in.yourcompany.com goes to the service instead of a mailbox.
- 3
Parsing
Sender, recipients, subject, text and HTML bodies, headers and attachments become separate fields.
- 4
Verification and spam checks
SPF, DKIM and DMARC show whether the sender is who they claim; a spam score flags unwanted mail.
- 5
Webhook delivery
The parsed email is sent as a JSON POST request to the URL you configured.
- 6
Your application acts
Your code creates a ticket, updates a CRM record, logs an invoice, or starts any other workflow.
For the details, see how to set the MX record on a subdomain, what SPF, DKIM, DMARC and spam scoring report, and what the JSON payload contains.
In one line:
Email sent → MX record routes to provider → parse and verify → JSON webhook → your applicationThe sender just sends a normal email. Your application receives an ordinary HTTP request with the email's data ready to use. To see a real payload before setting anything up, send an email to the live demo; no account needed.
Common use cases
Anywhere people or systems send email that your software needs to act on. The most common ones, with a worked example each (more in the use case library):
| Use case | What happens to the email | Example |
|---|---|---|
| Support ticketing | Mail to support@ becomes a ticket with subject, body, sender and attachments | Support workflow |
| CRM updates | A message from a client or prospect is logged on their record and can start a follow-up | Issue tracking |
| Invoice processing | The PDF attachment goes to your accounting or extraction step | Financial documents |
| Monitoring and IoT alerts | Alert emails become events that trigger incident response or escalation | |
| Calendar and scheduling | Booking confirmations and invites update your scheduling system | Calendar integration |
| Document collection | Contracts, reports and signed forms are filed in the right place, and the right team is told | Legal documents |
Key technical terms
Six terms you will meet when evaluating inbound email processing:
| Term | What it means |
|---|---|
| MX record | The DNS record that tells mail servers where to deliver mail for a domain. Point it at a processing service and all mail for that (sub)domain goes there. |
| Webhook | An HTTP callback: the service pushes each email to a URL you choose, so your application doesn't have to poll a mailbox. |
| JSON payload | The parsed email as predictable fields (sender, subject, body, attachments) that any programming language can read. |
| SPF / DKIM / DMARC | Email authentication. SPF says which servers may send for a domain, DKIM proves the message wasn't altered, DMARC sets the domain owner's policy when they fail. |
| Spam score | A number from a filter such as rspamd or SpamAssassin: the higher it is, the more likely the mail is spam. You pick the cut-off. |
| Virus scanning | Attachments are checked for malware before they reach your systems; infected files are held back. |
More on each: domain setup, spam filtering and virus scanning.
How to choose a provider
Services differ most on where your email goes, what they need access to, and what happens when your endpoint is down. The questions worth asking:
| Factor | What to ask |
|---|---|
| Data location | Where are the servers, and is email ever transferred outside that jurisdiction? For EU businesses, a US provider means US law (such as the CLOUD Act) can reach the data. |
| Access | Does it need a password or OAuth access to a whole mailbox, or only the mail you send to it? |
| Compliance | Is there a data processing agreement, and where are the sub-processors? Ask for the certifications your sector needs, rather than trusting a badge. |
| Retention | How long is email content kept after delivery, and can you delete it yourself? |
| Pricing | Is there a free tier to test with? What does your volume cost? Is inbound bundled with outbound email you don't need? |
| Features | Spam and authentication results, attachment size limits, aliases, routing rules. |
| Reliability | How often and for how long are failed deliveries retried? Is there an ID to drop duplicates? Can you replay a delivery? |
| Integration | Is the payload documented field by field, with real examples? Are deliveries signed so you can verify them? |
Different providers serve different needs: established US providers offer broad ecosystems, EU-only providers keep the data under EU law. The provider comparison sets them side by side.
Getting started
Three steps from nothing to your first parsed email:
- Choose an address. Pick a subdomain such as
in.yourcompany.comand point its MX record at the service, or start on an address the service gives you. - Create a webhook endpoint. An HTTPS URL in your application, or in n8n, Zapier or Make, that accepts POST requests.
- Send a test email. Check the JSON that arrives, then build the logic: tickets, records, workflows.
How EmailConnect fits
EmailConnect is an inbound email processing service, run in the EU. Each item links to the page behind it.
- Email arrives at your webhook as signed JSON. Deliveries follow Standard Webhooks (HMAC-SHA256), with one ID per email across retries. Webhook signing →
- A system address or your own domain. Use a system address on user.emailconnect.eu, or add your domain or subdomain with an MX record. Getting started →
- No access to your mailbox. You send or forward mail to addresses we run; we never hold a password or token for your mailbox. Privacy promise →
- Processed in the EU. Application, database and mail server at Hetzner in Germany; no US company in the processing chain, apart from optional Google or GitHub sign-in. Sub-processors →
- Failed deliveries are retried up to 7 times over about 22 hours, within your retention window. Delivery and retries →
- Free to try: 100 emails a month, one domain, three aliases. Pricing →
Receive your first email as JSON: getting started →
Related
How email automation works
What happens between an email arriving and your automation running, with a real payload.
Selective email access vs full mailbox
Why forwarding only the mail you need is safer than giving a tool your whole inbox.
Built for European privacy
EU hosting, GDPR and data retention, and how they shape an email service.
How EmailConnect compares
Inbound email services side by side on data location, privacy and developer experience.
Need help setting up inbound email processing for your application? Contact hello@emailconnect.eu.