# 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.

> **Note:** An **MX (Mail Exchanger)** record tells the world where to deliver incoming mail for a host. Each MX has a **priority** (a.k.a. preference): the **lower the number, the higher the priority**, and `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.

**SPF — MX (the MAIL FROM subdomain only)**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Type` | MX | No | Receives bounce and complaint feedback for the MAIL FROM subdomain. |
| `Name` | send.yourdomain.com | No | The custom MAIL FROM subdomain — NOT your root domain. |
| `Value` | feedback-smtp.us-east-1.amazonses.com | No | Region-specific feedback host (the region matches your domain’s sending region). |
| `Priority` | 10 | No | MX priority. |
| `TTL` | Auto | No | Provider default. |

> **Warning:** Do **not** remove, replace, or re-point the MX records on your **root domain** — those are how you receive email. Add the `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 the `send.` 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 on `yourdomain.com`.
- **Keep the SPF TXT on the same `send.` host.** The `v=spf1 include:amazonses.com ~all` TXT and the MX share the `send.yourdomain.com` name — 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 to `send.sub.yourdomain.com` and sidesteps the collision.
- **A priority collision.** Each MX on a host should have a unique priority. MailBlastr suggests `10` for the `send.` MX; if `10` is taken, pick any other unused value. Remember `0` is the lowest value (highest priority) — if something already uses `0` you’d have to free it up to outrank it, which you don’t need to do here since the `send.` MX lives on its own host.

> **Warning:** If two MX records on the same host share a priority value, mail is **not** sent to both — one server is chosen at random per delivery attempt. Keep priorities unique to make routing deterministic.

## 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:

1. **[Recommended] Receive on a subdomain.** Put the inbound MX on a dedicated host (e.g. `inbox.yourdomain.com`). Mail to `you@yourdomain.com` keeps flowing to Gmail / Microsoft 365, while mail to `you@inbox.yourdomain.com` is routed to MailBlastr. No conflict with your primary inbox.
2. **Receive on the root with a higher-priority record.** Adding an inbound MX on `yourdomain.com` with 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.

> **Warning:** MailBlastr inbound is **off by default** and requires explicit setup (an inbound MX plus a configured store). Sending alone never adds a receiving MX to your root, so it can’t hijack your inbox.

> **Note:** See [DNS records](https://www.mailblastr.com/docs/domains/dns) for the full record set and [Choosing a region](https://www.mailblastr.com/docs/domains/region) for why the MX value embeds the sending region.