For the complete documentation index, see llms-docs.txt or the site index llms.txt. Full docs corpus: llms-full-docs.txt. Prefer the markdown version of this page at /docs/guides/connect-domain/troubleshoot/mx-conflicts.md. Product capabilities: skill.md. Docs MCP: /docs/mcp. Site MCP: /mcp.

MX conflicts

Keep an existing inbox working while using Reloop — when MX changes are safe and when to use a separate hostname.

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. See also 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.

Was this page helpful?

Edit this page