---
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**. Lower priority number = higher preference.

## Sending-only with an existing inbox

If you only need Reloop to **send**, keep your current inbox MX where it is. Publish SPF, DKIM, DMARC, **Sending MX** (`reloop.sh`), and tracking as shown in Reloop — and turn **Email Receiving** off so Reloop does not expect inbound MX (`inbound.reloop.sh`).

New domains start with Email Receiving on; turn it off before Auto-populate or manual publish if you must keep Google Workspace / Microsoft 365 on that hostname.

## Receiving with Reloop

Enabling Reloop receiving expects MX toward `inbound.reloop.sh`. On the **same hostname** as another inbox, adding Reloop’s inbound MX can divert or split delivery depending on priority and which MX records you keep. Do not remove Google/Microsoft MX unless you intend Reloop to receive mail for 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.