Turn replies and incoming messages into structured events your application can act on.
AI intent classification sorts replies, out-of-office notes and complaints for you.
{
"event": "inbound",
"from": "customer@example.com",
"to": "support@reply.yourdomain.com",
"subject": "Re: Your order",
"text": "Thanks, that works for me.",
"attachments": []
}
Point an MX record at MigoSMTP for a subdomain you choose.
Headers, body and attachments arrive in a clean structure.
Send different addresses to different endpoints.
Receive files with size limits you control.
Screen incoming mail before it reaches your app.
Verify each payload came from us.
Publish the MX record for a subdomain.
Match an address pattern and choose a webhook.
Your app receives each message as JSON.
Switch between stages to see what you control at each step. Illustrative interface with sample data.
Use inbound routes to capture replies to transactional email, create tickets or feed workflows.
Route support@ on a reply subdomain to your helpdesk endpoint. Each email becomes a ticket with sender, subject and attachments, without polling a mailbox. No polling needed.
Set a reply-to on a reply subdomain with a token in the address. When someone responds, inbound email routing ties the reply to the right order or conversation.
Let users forward invoices or documents to a unique address. Parsed attachments arrive at your endpoint, ready to store or process, within the size limits you configure.
Capture out-of-office notices and unsubscribe requests sent by reply, then update contact status automatically so you stop mailing people who asked you to stop. Quiet clean-up improves long-term list health.
Each inbound message can be labelled as a genuine reply, out-of-office, unsubscribe request, complaint or sales enquiry. You map labels to routes, and low-confidence items go to a person.
For support routes, the assistant drafts a response from your knowledge base. A human reviews and sends it; nothing goes out automatically unless you configure that rule yourself.
Long reply chains are condensed into a short summary and a suggested next action, helping agents pick up conversations quickly. Original messages stay available in the logs.
AI risk scoring complements spam and virus checks by rating suspicious inbound messages. You choose whether high-risk items are quarantined, flagged or still delivered. Humans stay in charge of every decision.
AI features are assistive: classification and drafts support your workflow, and you decide the routing rules and what is sent. [Confirm which AI features are available at launch.]
Put the MX record on a subdomain like reply.yourdomain.com so your normal mailboxes keep working and inbound traffic stays isolated.
Check the signature header before processing a payload. Treat unsigned requests as untrusted, since anyone could post to a public URL.
Return a success response quickly and queue the work. Slow handlers trigger retries and duplicate deliveries. Queue the payload for later processing.
Retries can deliver the same message twice. Deduplicate on message ID so replays from the logs never create duplicate tickets.
Decide maximum size and allowed file types per route. Rejecting oversized or unexpected files early protects downstream systems.
Inbound email parsing receives email sent to an address you control and converts it into structured data, usually JSON with sender, subject, body and attachments. Your application gets it by webhook, so it can act on messages without running a mail server.
Add an inbound domain, publish the MX record for a subdomain, create a route matching an address pattern, and point it at your HTTPS webhook. Each incoming message is posted to that endpoint as signed JSON. Pick a name that is easy to recognise.
We recommend a dedicated subdomain so your regular mail is not affected. An MX record sends all mail for that name to the receiving service, so using the root domain would redirect your normal mailboxes. Review the delivery log for details.
Deliveries are retried, and you can replay them from the inbound logs once your endpoint recovers. [Confirm retry schedule.] Return a success response only after you have safely received the payload. This is safest when your endpoint is idempotent, because a replayed delivery then changes nothing a second time.
[Describe attachment delivery format.] Size and type limits are configurable per route. [Confirm message and attachment size.] Attachments are typically described in the payload with file name, type and size, and delivered either inline or by secure link, depending on size. Test with a few real files to see how your handler should treat them, and set strict size limits per route.
Inbound email handles messages sent to you and posts them to your endpoint. Webhooks more broadly report events about messages you sent, such as delivered or bounced. Inbound uses webhooks as its delivery mechanism, so the same signature checks apply.
Only if you enable it. AI classification and summaries run on messages for routes where you turn them on, and results are suggestions you can map to rules. Human review stays available. [Confirm which AI features are available at launch.]
Yes, incoming mail can be screened before it reaches your application, and you choose how flagged messages are handled. [Confirm scanning behaviour and engines.] Scanning protects downstream systems from malware and obvious junk. You choose whether flagged messages are rejected, tagged or quarantined for review, and every decision is recorded in the logs, which keeps handling auditable. Check your route settings for options.
We recommend a dedicated subdomain so your regular mail is not affected.
Deliveries are retried, and you can replay them from the logs.
Create an account, add your domain and send your first email.