# How do I avoid conflicts with my MX records?

> The MX record SendPing 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.

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

> **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.). SendPing never touches this. |
| **The MAIL FROM MX** | `send.yourdomain.com` | Routes bounce and complaint feedback for outbound mail. This is the only MX SendPing 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.

**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 SendPing.** The MAIL FROM MX belongs only on `send.yourdomain.com`. There is no SendPing 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 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 SendPing 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](https://docs.aws.amazon.com/ses/latest/dg/mail-from.html). Changing one priority does not resolve this requirement. Use the hostname, target and priority shown in your SendPing domain configuration after confirming that the host is dedicated to this purpose.

> **Note:** For ordinary inbound mail, equal MX preferences are valid and can distribute delivery attempts across servers; lower numbers are preferred and other eligible servers may be tried on failure. See [SMTP routing in RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1). This does not remove the separate SES custom MAIL FROM restriction.

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

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 SendPing. No conflict with your primary inbox.
2. **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.

> **Warning:** SendPing 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.sendping.co/docs/domains/dns) for the full record set and [Choosing a region](https://www.sendping.co/docs/domains/region) for why the MX value embeds the sending region.