“Reply to this email” is a promise about what happens after the send. A migration can preserve the email's design and still break that promise if the address, inbound route, or support workflow changes.
Use Migma to review the invitation to reply as part of the creative, then have the sending and support owners prove where the response arrives. For a Mailgun-to-Loops move, outbound sending and inbound processing need separate decisions.
This guide is published by Migma. It focuses on reader-facing copy and reply-path acceptance, not a complete infrastructure migration recipe or an independent provider benchmark. Official product pages were checked on October 16, 2026.
Follow the reply before choosing new copy
Find every active email that asks the recipient to answer. Do not stop at messages with a prominent reply button. A friendly closing, a survey question, or a support sentence can create the same expectation.
For each message, ask the owner to show the actual Reply-To address and what happens behind it. A response might arrive in a monitored mailbox, become a helpdesk ticket, or be parsed into an application. Those are different workflows, even if the reader sees the same address.
Mailgun's inbound routing page describes parsing and directing incoming messages, including replies that feed an app or support ticket. That is a separate capability from sending an outbound email.
Understand the migration boundary
Loops' Mailgun migration guide says Mailgun Routes do not have a Loops inbound-routing equivalent. It recommends keeping Mailgun or another inbound provider for those paths when they remain in use.
That does not make a sending migration impossible. It means “move the templates” and “replace the reply workflow” are different tasks. Do not retire an inbound path merely because the new outbound template passes a test.
Migma's export workflow provides reviewed email creative and HTML handoff. It does not automatically migrate Mailgun Routes, configure a support mailbox, or establish a native Loops connection. Keep those responsibilities visible in the plan.
Choose wording that matches the real response path
Write the closing in Migma after the reply owner confirms the supported behavior. The following original examples illustrate three different promises:
A monitored human inbox
“If you need help choosing, reply to this email and our team will take a look.” Use this only when the message actually reaches a team responsible for that request. Do not invent a response time to make the closing sound more reassuring.
A support form with useful context
“Need help with this order? Open the support page and include your order reference.” Use a reviewed destination and explain the information the team actually needs. Do not show a reply invitation elsewhere in the email if replies are not monitored.
A reply that updates the application
“You can reply to add a comment to this conversation.” This is an application behavior claim. Ask the engineering owner to prove how the message is matched to the right conversation, including whether attachments and quoted text are handled as expected.
These examples are suggested copy, not statements about your system. Choose the one that matches the tested path or write a different closing from your verified facts.
Test the round trip from the final message
Run Migma Email Preflight and review the creative, links, and inbox layout. Then have the implementation owner send a controlled final-platform test through the actual outbound path.
Reply from that received message rather than manually typing the expected address into a new email. The round trip should prove that the final headers, address, and route work together.
Use an acceptance record like this:
| Check | Evidence to retain |
|---|---|
| Outbound message | Final sender and Reply-To from the received test |
| Response | Controlled reply with safe representative content |
| Destination | Correct mailbox, ticket, or application conversation |
| Ownership | Named person responsible for follow-up |
| Failure handling | What the team sees if routing or processing fails |
Do not put real customer conversations or private credentials in a shared creative record. Use approved test content and retain operational evidence in the appropriate system.
Check the cases hidden by a simple success
A plain-text reply can pass while another supported case fails. Ask the implementation owner which cases matter for the actual workflow: replies from a second inbox, an attachment, a forwarded message, or a response to an older email after cutover.
You do not need to test every theoretical variation for every campaign. Focus on the behaviors the copy promises and the paths customers already use. If a capability is unsupported, change the message or preserve a working route rather than implying it works.
Pay particular attention to older sent emails. Their Reply-To addresses cannot be changed by editing tomorrow's template. Keep the responsible owner informed before retiring an address or route that those messages still reference.
Record outbound delivery and successful inbound processing separately. A provider accepting the send is not evidence that the customer's answer reached a person. Use what the test reveals to refine the next Migma draft, and publish a reply invitation only when the team can keep it.
Frequently Asked Questions
Does moving outbound templates replace Mailgun Routes?
No. Loops' migration guide says it has no equivalent inbound-routing feature. Preserve Mailgun or another inbound provider for the reply paths you still need, and test them separately from outbound sending.
What should a reply-path test start from?
Start from a controlled message received through the actual final sending path. Reply to that message and confirm the intended mailbox, ticket, or application conversation receives it. Typing an address into a new email tests less of the path.
Can I keep asking readers to reply during a migration?
Only when the responsible team has verified that the address and downstream workflow still work. Otherwise use a supported, reviewed contact route and change every conflicting reply invitation in the new creative.
Why do older sent emails matter?
They still contain the Reply-To addresses and promises used when they were sent. Editing a future template cannot change them. Check continued reply handling before retiring an old address or inbound route.