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.
A common worry when adding a sending domain is: "Will this break my email? I already have MX records pointing at Gmail / Microsoft 365." The answer is no — the MX record MailBlastr generates lives on a different hostname than your inbound MX, so the two never collide.
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. |
Because the MailBlastr MX sits on the send. subdomain — a host you (almost certainly) have no records on today — it does not overwrite or interfere with the MX on your root domain that receives your mail.
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 MX already on `send.yourdomain.com`. A host can’t carry two unrelated MX setups cleanly, so remove the old
send.MX before adding the MailBlastr one. If you must keep the old record, verify a *subdomain* in MailBlastr instead (e.g.sub.yourdomain.com), which moves the MAIL FROM MX tosend.sub.yourdomain.comand sidesteps the collision. - A priority collision. Each MX on a host should have a unique priority. MailBlastr suggests
10for thesend.MX; if10is taken, pick any other unused value. Remember0is the lowest value (highest priority) — if something already uses0you’d have to free it up to outrank it, which you don’t need to do here since thesend.MX lives on its own host.
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.
You have two safe options:
- [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. - Receive on the root with a higher-priority record. Adding an inbound MX on
yourdomain.comwith a lower priority number than your current provider will route all mail for the root to MailBlastr instead of your existing inbox — only do this if that is genuinely what you want.