Send and receive
Work with outbound email and inbound replies through the same inbox APIs.
Mailgun alternatives for more than the send event.
Bring real inboxes, inbound automation and email testing together with MailSlurp. See what your application sent and what the recipient received.
Trusted by teams at
Give every workflow an address of its own.
Create real email addresses in the dashboard or through the API. Receive replies, inspect messages and organize inboxes around your customers, applications and test environments.
Use MailSlurp domains or connect your own domain. Choose inbox lifetimes and retention settings to suit the workflow.
Explore programmable email
React to incoming messages
Use webhooks to notify your app when an email arrives, then retrieve its content and attachments.
Inspect what was delivered
Open the received message, headers and raw content when a workflow needs debugging.
Keep the received message within reach.
Look beyond the send event. Open an email in the dashboard, inspect its final content and use the API to retrieve the fields your application needs.
For invoices, orders and support messages, add AI extraction to turn email and attachment content into structured records.
Turn incoming email into data
Test the send before your customers depend on it.
Pair your email workflow with inbox placement testing, domain checks and device previews. Check where a test lands and how the message looks before releasing a new template or changing a sending service.
Check inbox placement
How to bring a workflow into MailSlurp
Create an inbox and connect your app
Start with an address in the dashboard, then use the MailSlurp API and SDK guides to create and manage inboxes from your application.
Send a representative message
Test the confirmation, receipt or reply your app depends on. Inspect the delivered email and verify any domain settings required for your sending path. Plans show the current sending allowances.
Automate the next action
Configure a webhook or wait for the expected email through the API. Check the content, extract the data you need and continue the workflow with a repeatable test.
Move an inbound route without losing the reply.
Start with one receiving workflow. Keep the message, attachment and downstream action together while you compare the result.
Map the recipient and the action
A Mailgun inbound route pairs a filter with actions such as forwarding or storing a message. Record which recipient or header selects the route, where it sends the email, and whether later routes also run. Keep that behavior explicit when moving to a MailSlurp inbox and webhook consumer.
Use a dedicated inbox for the receiving address, then handle the incoming event through email webhooks. Match the recipient and message fields before invoking your downstream action. Mailgun's route documentation describes its priority and stop behavior; translate that logic deliberately rather than copying a route expression into a different API.
Receive the content and process it once
Mailgun's HTTP forwarding can deliver form fields or multipart data. Update the consumer for MailSlurp's JSON event and retrieve the full email and attachments by their IDs. Check the recipient, plain text, HTML and attachment bytes with a representative reply before connecting a customer-facing action.
Verify the webhook signature and deduplicate deliveries using the event's message ID. Persist the event before acknowledging it, then perform the business action in your worker. The webhook reference covers payloads, retries and verification; the attachment guide covers downloading the received files.
Check the switch with a test address first
Try a new address or subdomain before changing production MX records. Send a reply with an attachment, repeat delivery to check duplicate handling, and confirm that a failed downstream action can be retried without creating a second order or ticket. Keep the previous receiving configuration available until those checks pass.
Review the custom-domain setup and your plan's receiving and retention allowances. Evaluate MailSlurp sending separately from receiving, and add placement testing when the outbound route changes. For visual campaign QA, see the Mailgun Inspect alternative.
Questions before you switch?
How do I evaluate inbound email when comparing Mailgun alternatives?
Try a reply that contains both message text and an attachment. Receive it in a dedicated MailSlurp inbox, check the webhook event and retrieve the original email through the API. If your app needs an invoice total or order number, test an AI transformer against the attachment and review the extracted value before using it downstream. See the inbound webhook workflow.
Can I test email without changing my sending provider?
Yes. Send from Mailgun or your existing provider to a dedicated MailSlurp inbox. Inspect the received message, retrieve its verification link or attachment and check the next step in your app. You can evaluate MailSlurp's sending and inbound APIs separately while those tests protect the existing workflow.
How do I evaluate a migration?
Start with one receiving address or a test subdomain. Map its recipient filters, forwarding destinations and stored-message handling to a MailSlurp inbox and webhook consumer. Check text, attachments, duplicate delivery and failure handling before changing the production domain's MX records. Evaluate outbound sending separately so a receiving migration does not silently change how your application sends mail.
Bring your next email workflow into MailSlurp.
Start with an inbox, a real message and the next action your app needs.
