The Mailparser alternative for software, not spreadsheets

Parsing rules break the day a sender redesigns their template. Inboundr hands your application the whole message — bodies, attachments, threads — with nothing decided in advance.

Published 30 July 20266 min read

Mailparser’s documentation and pricing last read 30 July 2026

The short version

Parsing rules bet that tomorrow's mail looks like today's. A redesigned template produces an empty row, not an error — the failure is silent.
Here your code gets the whole message: bodies, headers, attachments and threads, with nothing decided in advance and nothing lost because no rule matched.
Mail arrives on your own domain and MX record, not forwarded through a mailbox provider that can filter or delay it first.
You can also reply. A parser is one direction by design; this is an inbox your software owns.

These are two different jobs

Mailparser— and Zapier’s email parser, and the several tools that work the same way — solves a specific and common problem. A supplier sends the same notification every day. Somewhere inside it is an order number, a date and a total. You draw a box around each one, and from then on those three values arrive in a spreadsheet, a CRM or a webhook without anybody reading the email.

For an operations team with no developer and three fields to copy out of a daily notification, that is a reasonable purchase. It is also a bet on the mail never changing, made at the moment you draw the box.

This product answers a different question: what does my software do when an email arrives? The output is not a row someone specified in advance. It is the message — every field of it, including the ones you did not know you would need.

Where field extraction runs out

Parsing rules make a bet: that tomorrow’s mail looks like today’s. That bet holds for machine-generated notifications and breaks in four familiar ways:

The sender redesigns. A template change upstream does not raise an error — the rule matches nothing and the row is empty, or worse, matches the wrong text and the row is wrong. Nobody notices until a number looks odd downstream.
A person writes to you. Prose has no fields. A customer explaining that line 3 is billed twice cannot be reduced to columns by a rule, and that is exactly the mail a support product or an agent is for.
You need something you did not extract. Rules apply going forward. The question “what did they actually say in March?” is unanswerable if the March payload was three columns.
You have to reply. Any workflow that ends in answering the sender needs a mail account, threading headers and a sending path. A parser is one direction by design.

The forwarding hop is worth thinking about too

Because parsers usually receive at an address on their own domain, the mail reaches your mailbox provider first and is then forwarded on — so its spam filter, its rules and its outages sit in front of your pipeline. Receiving on your own domain with your own MX record takes that hop out.

Side by side

The question behind every row is the same one: who decides what matters in a message — a rule written months ago, or the code reading it now?

What you need	Inboundr	Mailparser
The whole message, not selected fields	Full text and HTML bodies, every address, headers, threading ids and auth verdicts, whether or not you anticipated needing them.	The output is the fields your rules matched. Anything you did not write a rule for is not in the payload, and a rule written today does not apply to mail parsed yesterday.
Mail that does not follow a template	Nothing is assumed about the shape of a message, so a human writing prose and a machine sending a receipt arrive the same way.	Rules are anchored to the layout of a known sender. A supplier redesigning their notification email is a silent parse failure until someone notices the missing rows.
Receive on your own domain	MX and DKIM records on a domain you own; every address resolves, catch-all included.	You get an address on their domain and forward mail to it. Workable, and it means the mail passes through your mailbox provider first — one more hop that can break or filter.
Attachments your code can fetch	Every attachment stored on arrival, whatever the type, and handed out as a short-lived link or a tool call.	Text-readable attachments — CSV, XLSX, DOCX, PDF, TXT — can be parsed for their contents. Images and scans are not supported, and what you get back is extracted fields rather than the file.
Send a threaded reply	Reply in-thread from the API or as an agent tool call; the threading headers are written for you.	It is a parser, not a mail account. Answering the sender is something another tool in your chain does.
An agent that reads the mailbox	A hosted MCP server: list, read, thread, send, fetch attachments. The agent decides what matters in the message rather than a rule deciding in advance.	No MCP surface. An agent downstream sees whichever columns the rules produced — which is a lossy summary of the mail, chosen before the agent existed.
Extraction that survives a redesigned template	Nothing is anchored to a layout. A model reading the stored message pulls the order number out of a format nobody configured, and can say when it is unsure.	A rule that no longer matches produces an empty row rather than an error, so the failure is silent until a number looks wrong somewhere downstream.
Reach a spreadsheet or a CRM	A webhook, a REST API and MCP, which any automation platform can consume — one step you wire up rather than a catalogue you pick from.	A large integration catalogue, so parsed fields land in a sheet or a CRM without anyone writing a line.

The whole message, not selected fields

Inboundr: Full text and HTML bodies, every address, headers, threading ids and auth verdicts, whether or not you anticipated needing them.
Mailparser: The output is the fields your rules matched. Anything you did not write a rule for is not in the payload, and a rule written today does not apply to mail parsed yesterday.

Mail that does not follow a template

Inboundr: Nothing is assumed about the shape of a message, so a human writing prose and a machine sending a receipt arrive the same way.
Mailparser: Rules are anchored to the layout of a known sender. A supplier redesigning their notification email is a silent parse failure until someone notices the missing rows.

Receive on your own domain

Inboundr: MX and DKIM records on a domain you own; every address resolves, catch-all included.
Mailparser: You get an address on their domain and forward mail to it. Workable, and it means the mail passes through your mailbox provider first — one more hop that can break or filter.

Attachments your code can fetch

Inboundr: Every attachment stored on arrival, whatever the type, and handed out as a short-lived link or a tool call.
Mailparser: Text-readable attachments — CSV, XLSX, DOCX, PDF, TXT — can be parsed for their contents. Images and scans are not supported, and what you get back is extracted fields rather than the file.

Send a threaded reply

Inboundr: Reply in-thread from the API or as an agent tool call; the threading headers are written for you.
Mailparser: It is a parser, not a mail account. Answering the sender is something another tool in your chain does.

An agent that reads the mailbox

Inboundr: A hosted MCP server: list, read, thread, send, fetch attachments. The agent decides what matters in the message rather than a rule deciding in advance.
Mailparser: No MCP surface. An agent downstream sees whichever columns the rules produced — which is a lossy summary of the mail, chosen before the agent existed.

Extraction that survives a redesigned template

Inboundr: Nothing is anchored to a layout. A model reading the stored message pulls the order number out of a format nobody configured, and can say when it is unsure.
Mailparser: A rule that no longer matches produces an empty row rather than an error, so the failure is silent until a number looks wrong somewhere downstream.

Reach a spreadsheet or a CRM

Inboundr: A webhook, a REST API and MCP, which any automation platform can consume — one step you wire up rather than a catalogue you pick from.
Mailparser: A large integration catalogue, so parsed fields land in a sheet or a CRM without anyone writing a line.

When Mailparser is the better choice

Nobody is writing code. If the person who needs the data is in operations and the alternative is a developer ticket, a rule builder wins outright. Everything here assumes an application on the other end.
The destination is a spreadsheet and the mail never changes. One sender, one layout, three fields, into a sheet. Their catalogue takes you there with nothing in between.

Using both, which is often the answer

These products compose better than they compete. An address can point at more than one endpoint, so the same message can post to your application and forward to a parser inbox — code takes the messages that need judgement, rules take the ones that are always the same shape.

There is also a third option that did not exist when field extraction was invented: keep the whole message and let a model read it. The payload is the same either way —

POST https://your-app.example.com/hooks/inbound

{
  "event": "email.received",
  "email": {
    "id": "em_2f9c1a4b7d3e5601",
    "from": "supplier@example.com",
    "to": ["orders@yourdomain.com"],
    "subject": "Order 4021 confirmed",
    "text": "Order 4021 confirmed for delivery on 4 August, total £412.50…",
    "attachments": [
      { "filename": "order-4021.pdf",
        "contentType": "application/pdf",
        "size": 84213 }
    ],
    "receivedAt": "2026-07-30T09:14:22.104Z"
  }
}

— and an agent given get_email and get_attachment can pull the order number out of a layout nobody drew a box around, and say so when it is unsure. That is the trade against rules: no configuration, no silent breakage when a template changes, but a judgement call instead of a deterministic match. For invoices and receipts it is often the better one. See giving an agent its own address.

What each one costs

No figures here on purpose — check theirs at the source and ours here.

Both meter roughly the same thing: emails processed per month. The comparison that matters is fit, not price — a parser is cheap for a few hundred uniform notifications and a poor foundation for an application that also receives human mail, replies to it, and has to keep the attachments.

Moving off a parser

Write down what your rules currently extract. That list is your handler’s first job, and it is usually shorter than expected.
Add the domain in the Inboundr console and publish the MX and DKIM records. This is also the point where mail stops going via a forwarding hop.
Point the address at a webhook endpoint, and keep the forward to your parser inbox alongside it. Both run in parallel for as long as you want them to.
Reimplement the extraction — a few string operations, or a model call with the body and the attachment, depending on how uniform the mail is.
Compare the two outputs for a week. The parser is your control group; disagreements are usually mail that never fitted the template.
Remove the forward once the numbers agree.

Questions people ask

Do you have a rule builder for extracting fields?

No. Filtering rules here decide whether a message is delivered at all — sender, recipient, subject, spam verdict — they do not pull values out of a body. Extraction happens in your code, or in a model you call with the message.

Can I still get the data into a spreadsheet?

Yes, but through your own automation: the webhook can call a Zapier or Make endpoint, or your handler can append a row directly. What you do not get is a built-in export — that is their product and not ours.

Can you parse an attached PDF or spreadsheet?

We store attachments and hand them to you or to an agent; we do not extract fields from them. A model reading the file is the usual route, and unlike a rule it copes with a layout it has not seen. Deterministic table extraction from a known format is theirs.

Why does receiving on my own domain matter?

Fewer moving parts and no dependence on a forwarding hop: messages arrive at your MX record, and the spam verdict, authentication results and delivery attempts are all recorded in one place. It also means the address on your invoices belongs to you rather than to a vendor.

Claims about Mailparser were checked against their public feature pages, their help-centre articles on parsing rules and on webhooks and integrations, and their pricing page. Zapier Email Parser and similar tools work the same way, but their details were not checked for this page. Read on 30 July 2026. If something here is out of date, tell us and we will correct it.

Keep reading

CloudMailin alternative6 min read Building inbound email yourself9 min read ImprovMX alternative6 min read