How do I avoid conflicts with my MX records?
The MX record MailBlastr adds lives on the send. MAIL FROM subdomain and only routes bounce/complaint feedback — it is separate from your inbound MX. Never remove your real MX records.
MailBlastr normally places its sending-feedback MX on send.yourdomain.com, separate from the root-domain MX used by your inbox provider. Check the exact hostname before making a change: that subdomain may already be in use.
The key idea is that there are two completely separate MX records doing two unrelated jobs.
0 is the highest priority possible. MX records only affect the exact host they are set on — send.yourdomain.com and yourdomain.com are independent.Two different MX records
| MX record | Host | Purpose |
|---|---|---|
| Your inbound MX | yourdomain.com | Routes incoming mail to your inbox provider (Gmail, Microsoft 365, etc.). MailBlastr never touches this. |
| The MAIL FROM MX | send.yourdomain.com | Routes bounce and complaint feedback for outbound mail. This is the only MX MailBlastr asks you to add. |
Records on send.yourdomain.com and yourdomain.com belong to different DNS names. Preserve the root-domain MX and check who owns any existing records on the proposed send. host.
TypeMXoptionalReceives bounce and complaint feedback for the MAIL FROM subdomain.
Namesend.yourdomain.comoptionalThe custom MAIL FROM subdomain — NOT your root domain.
Valuefeedback-smtp.us-east-1.amazonses.comoptionalRegion-specific feedback host (the region matches your domain’s sending region).
Priority10optionalMX priority.
TTLAutooptionalProvider default.
send.yourdomain.com MX as a brand-new record alongside everything you already have.Things to watch for
- Add, don’t replace. Create the
send.MX as a new record. Some DNS UIs prompt to "replace existing records" — make sure you’re adding to thesend.host, not editing your root MX. - Don’t put an MX on the root for MailBlastr. The MAIL FROM MX belongs only on
send.yourdomain.com. There is no MailBlastr MX record onyourdomain.com. - Keep the SPF TXT on the same `send.` host. The
v=spf1 include:amazonses.com ~allTXT and the MX share thesend.yourdomain.comname — that’s expected, and separate from any SPF TXT on your root.
Resolving an existing conflict
If you do hit a clash, it is one of two kinds:
- An existing service uses the MAIL FROM host. Identify that service before editing its records. If it must remain, use a separate sending domain or subdomain in MailBlastr and copy the records generated for that configuration. Do not delete an existing record merely to make verification pass.
- Multiple MX records on the MAIL FROM host. Amazon SES requires exactly one MX record for a custom MAIL FROM domain. Changing one priority does not resolve this requirement. Use the hostname, target and priority shown in your MailBlastr domain configuration after confirming that the host is dedicated to this purpose.
The other MX case: receiving mail
The discussion above is about sending, where the MAIL FROM MX only carries delivery feedback. If you also enable MailBlastr inbound (receiving mail), that uses a *separate* inbound MX, and here the conflict with your existing inbox provider is real — because an inbound MX on a host genuinely routes that host’s incoming mail.
Plan receiving separately from the sending-feedback host:
- [Recommended] Receive on a subdomain. Put the inbound MX on a dedicated host (e.g.
inbox.yourdomain.com). Mail toyou@yourdomain.comkeeps flowing to Gmail / Microsoft 365, while mail toyou@inbox.yourdomain.comis routed to MailBlastr. No conflict with your primary inbox. - Migrate root-domain receiving deliberately. If you intend to move your existing inbox routing, plan the full MX change with the administrators of both services. Keeping unrelated providers at different priorities is not a way to deliver a copy to each provider and can send fallback attempts somewhere unintended.