---
title: MX conflicts
sidebarTitle: MX conflicts
description: Keep an existing inbox working while using Reloop — when MX changes are safe and when to use a separate hostname.
---
> For the complete documentation index, see [llms-docs.txt](/llms-docs.txt) or the site index [llms.txt](/llms.txt). Full docs corpus: [llms-full-docs.txt](/llms-full-docs.txt). Prefer markdown URLs (append `.md`) for agent consumption. Product skill: [skill.md](/skill.md).


MX records decide **where inbound mail is delivered**.

## Sending-only with an existing inbox

If you only need Reloop to **send**, keep your current MX where it is. Publish SPF, DKIM, DMARC (and tracking) for Reloop without replacing MX.

## Receiving with Reloop

Enabling Reloop receiving sets MX toward `inbound.reloop.sh`. On the **same hostname**, that typically **stops** delivery to any other inbox on that name.

### Safe pattern

Use separate hostnames:

- `acme.com` MX → your existing inbox
- `mail.acme.com` MX → Reloop (inbound + Reloop send)

Reloop supports the [root, a subdomain, or both](/docs/guides/connect-domain/what-is-a-domain). See also [Sending vs receiving](/docs/guides/connect-domain/sending-vs-receiving).

## Multiple MX priorities

If you experiment with multiple MX targets, lower priority number = higher preference. Mixing two inbox providers on one hostname is advanced and usually the wrong fix — prefer a separate hostname for Reloop receiving.