What is inbound email processing?
Inbound email processing gives your app an email address it can receive and act on. When a message arrives at reply@yourapp.com or tickets@yourcompany.com, rather than sitting in an inbox, your system parses it and does something with it — creates a support ticket, appends a reply to an existing thread, processes a forwarded invoice, or triggers a workflow.
This is the reverse of transactional email. Instead of sending messages out, you are receiving them in and treating them as structured input. The challenge is that email is inherently unstructured — you receive raw text, HTML, attachments, auto-replies, and bounce messages all mixed together, and your parser needs to handle all of it gracefully.
Inbound processing is what allows systems like Zendesk (email-to-ticket), Basecamp (email-in replies), and accounts payable automation tools (forward your invoices here) to work.
When does your app need it?
- You want customers to email a support address and have tickets automatically created in your system, with replies staying in thread
- Your app sends notifications and you want users to be able to reply by email rather than logging in
- You are building an accounts payable or expense management tool that processes forwarded supplier invoices
- You have an operations workflow triggered by external parties sending emails to a designated address
- You want to allow email-based data submission from users who are not technical or not logged in
- You need to capture attachments (PDFs, images) sent via email and associate them with records in your system
How much does it cost?
Adding inbound email processing typically adds 8–16 hours of development — roughly $1,000–$4,000 AUD.
At the simpler end, this is a webhook handler that receives parsed email data from a provider and creates a record in your database. At the more complex end, it includes threading logic (matching replies to existing tickets), attachment extraction and storage, spam filtering, handling out-of-office auto-replies without creating duplicate records, and a human review queue for messages that fail to parse correctly.
How it's typically built
The standard approach is to configure an email provider to receive messages on your domain and forward the parsed content to a webhook on your server. SendGrid Inbound Parse, Postmark Inbound Processing, Mailgun Routes, and AWS SES with Lambda are the most common options. Each receives the raw email, parses it into structured fields (sender, subject, body text, HTML body, attachments), and POST the result to your endpoint.
Your application then applies business logic: extract the relevant identifier from the subject line or To address (e.g. a ticket number), match it to a record, strip quoted reply text to get only the new message, store attachments to S3 or equivalent, and update the record. Edge cases — HTML-only emails, malformed addresses, spam, delivery status notifications — require defensive handling. For AI-assisted processing (e.g. extracting line items from a forwarded invoice), an LLM parsing step can be added after the initial parse.
Questions to ask your developer
- What should happen when an email cannot be matched to an existing record? You need a clear policy — create a new record, queue for human review, or discard.
- Do you need to handle email threading (replies staying in the same conversation)? Thread matching via Message-ID headers or subject-line parsing adds meaningful complexity.
- Will you process attachments? Extracting and storing files from email attachments needs to be scoped, including storage costs.
- How will you handle spam and auto-replies? Without filtering, your system will create noise from out-of-office replies, delivery receipts, and spam.
- Which provider will handle the inbound routing? Choice affects how attachments are delivered to your webhook and the size limits imposed.
See also: Transactional email · AI document extraction · App cost calculator