MX record conflicts are usually caused by treating every email-related DNS record as though it controls the same thing. It does not: MX records route inbound mail to a domain, while a transactional email API or SMTP relay handles outbound delivery.

The safe rule is simple: do not replace working MX records just because you are adding a new sending provider. Add only the DNS records that provider actually requires, keep inbound routing intentionally owned by one system, and use subdomains when different mail functions need clean separation.

Start with the distinction that prevents most mistakes

Email has several independent paths. They interact in a recipient's spam filters and in your users' inboxes, but they are not configured by the same DNS record.

An MX (Mail Exchanger) record tells other mail servers where to deliver messages to an address such as support@example.com. If someone sends a reply to your domain, their server looks up the MX records for example.com and attempts delivery to the listed receiving mail hosts.

A transactional email service, by contrast, generally accepts mail that your application submits through one of two outbound interfaces:

An HTTPS REST API, where your app sends a request containing recipients, sender, subject, and content.
An authenticated SMTP relay, where your app connects to a submission hostname, authenticates, and submits a message.

Neither method normally requires you to point your root-domain MX records at the transactional provider. The provider is your outbound relay, not necessarily your mailbox host.

That distinction matters because an MX replacement can break ordinary business mail immediately. Your website may still work. Your application may still receive 202 Accepted from its mail API. Yet messages sent to hello@example.com, password-reset replies, supplier invoices, and support requests may start going to the wrong system or fail altogether.

Inbound and outbound email are different jobs

Use this mental model:

Job	Typical mechanism	What it controls
Receiving mail for `user@example.com`	MX	Where remote servers deliver inbound mail
Sending application mail	API or SMTP submission	How your application hands outbound mail to a relay
Authorizing senders	SPF TXT	Which infrastructure may send for a domain or envelope domain
Cryptographically signing mail	DKIM TXT or CNAME	How recipients verify a message signature
Publishing handling policy	DMARC TXT	How recipients evaluate aligned SPF/DKIM failures
Measuring link clicks	CNAME, often on a subdomain	Branded tracking-link routing
Processing bounces	Envelope sender / return-path domain	Where delivery-status notifications are directed

A sending provider may ask for DKIM, SPF, verification, tracking, or return-path records. Those are not automatically MX records. Read each requested record type, host, and value precisely before editing DNS.

What an MX record actually does

An MX record contains two essential pieces of information: a numeric preference and a mail-host target. Lower preference values are tried first. If several targets have the same preference, a sending server can choose among them.

In zone-file notation, a typical configuration looks like this:

example.com.  3600  IN  MX  10  mail1.example.net.
example.com.  3600  IN  MX  20  mail2.example.net.

The record says that inbound mail for @example.com should be attempted at mail1.example.net first and mail2.example.net second. The trailing dots represent fully qualified domain names in zone-file syntax. Many hosted DNS dashboards add the final dot for you, but behavior varies, so follow your DNS provider's input guidance.

The MX target is a hostname, not an IP address. This is invalid:

example.com.  IN  MX  10  203.0.113.25

Instead, the target hostname must resolve to an A record, an AAAA record, or both:

mail1.example.net.  IN  A     203.0.113.25
mail1.example.net.  IN  AAAA  2001:db8:100::25

Do not point an MX record to a CNAME. MX targets are expected to resolve directly to address records, not through an alias. A DNS name that has a CNAME also cannot normally coexist with other record types at the same name, which is one reason aliases create operational surprises in email setups.

MX priorities are preferences, not mail categories

A common misunderstanding is that priority 10 could mean “Google Workspace” while priority 20 means “transactional mail.” It does not work that way.

Remote senders do not inspect your intent. They simply see a ranked list of receiving servers for the same destination domain. If you publish an existing mailbox provider at priority 10 and an unrelated transactional platform at priority 20, senders may attempt the second target when the first one is unavailable. That can create split delivery, unexpected rejects, or mail landing in an inbox system that does not know your users.

MX priority is for resilience among mail receivers that are deliberately configured to accept mail for the same domain. It is not a routing switch for separate vendors, departments, or email types.

No MX does not always mean no inbound mail attempts

If a domain has no MX record, SMTP rules historically allow senders to fall back to the domain's A or AAAA address. That can lead to futile connection attempts against a web server that does not accept SMTP.

If a domain truly must not receive any email, publish a Null MX record rather than merely removing MX records:

no-mail.example.com.  3600  IN  MX  0  .

This specifically communicates that the domain accepts no mail. Do not use a Null MX at a domain that sends messages with a return address, expects replies, or needs delivery-status notifications. For an active transactional sending domain, a Null MX can create a contradiction: recipients may need to send a human reply or a bounce somewhere.

Why transactional sending usually should not touch your MX records

When you connect an application to a transactional email platform, the application is submitting mail outbound. It may use an API endpoint or authenticate to an SMTP relay with credentials. The provider then performs DNS lookup and SMTP delivery to each recipient's domain.

Your own MX records are relevant only when someone else sends mail to your domain—for example:

A customer replies to support@example.com.
A recipient forwards a receipt to a colleague at your domain.
A remote server generates a delivery-status notification for an envelope sender at your domain.
A user submits a contact form that forwards into your organization.
A mailbox provider delivers a vacation responder, abuse complaint, or moderation message.

The practical implication: if your company already uses a mailbox provider for @example.com, preserve that provider's MX records while onboarding a transactional sender. The sender can be authenticated with other DNS records without becoming your inbound mailbox destination.

A REST API response is also not an inbound-mail test. An HTTP 202 Accepted generally means a service accepted the request for processing; it does not prove that replies to your From address will reach a mailbox. Likewise, an SMTP relay's 250 response generally means the relay accepted the message, not that the recipient's server has delivered it to an inbox.

The records a sending provider is more likely to request

A transactional provider commonly asks you to add some combination of the following:

; SPF authorization at the domain or a sending subdomain
notify.example.com.  IN  TXT  "v=spf1 include:spf.sender.example -all"

; DKIM selector delegation
s1._domainkey.notify.example.com.  IN  CNAME  s1.domainkey.sender.example.

; Branded tracking domain
click.notify.example.com.  IN  CNAME  tracking.sender.example.

; Optional custom return-path / bounce domain
bounce.notify.example.com.  IN  CNAME  bounce.sender.example.

The exact hostnames and values are provider-specific. Do not copy the example values into production. Copy the record values from the provider's current documentation or setup instructions, then validate them with DNS queries.

The important pattern is that these records are often placed on subdomains such as notify.example.com, bounce.example.com, or click.example.com. That preserves your root-domain MX routing while giving the sending system a distinct, controlled namespace.

If you need implementation details for a particular API or authenticated relay, consult the platform's email API setup guides rather than guessing at connection parameters or DNS values.

The safest architecture: separate mail roles with subdomains

A root domain can work for both employee mail and application mail, but subdomains reduce coupling. They make ownership clearer, simplify migrations, and limit the blast radius of an accidental DNS edit.

For example, an organization might use this layout:

example.com                 employee mail and public-facing addresses
notify.example.com          product notifications and receipts
updates.example.com         opted-in product updates
bounce.notify.example.com   envelope sender / return-path
click.notify.example.com    branded click tracking

This does not mean every subdomain requires an MX record. Add an MX record only if that subdomain needs to receive mail. A sending-only subdomain may need SPF, DKIM, and DMARC records, while its inbound mail policy should be intentional rather than accidental.

A practical root-domain pattern

Suppose your employees use person@example.com, and your application sends receipts from receipts@example.com. A conservative configuration is:

; Existing inbound mail remains owned by the mailbox provider
example.com.  IN  MX   1  inbound.mailbox-provider.example.

; Root-domain authentication, if your sending setup requires it
example.com.  IN  TXT  "v=spf1 include:_spf.mailbox-provider.example include:spf.transactional-provider.example -all"

; DMARC policy for visible From addresses at example.com
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; Provider-issued DKIM names are examples only
selector1._domainkey.example.com.  IN  CNAME  selector1.provider.example.
selector2._domainkey.example.com.  IN  CNAME  selector2.provider.example.

The critical point is that the MX record remains with the mailbox provider. The transactional provider is authorized to send via SPF and DKIM, but it is not put into inbound failover unless it explicitly provides a mail-receiving service you intend to use.

A cleaner subdomain pattern

For many teams, it is cleaner to send application mail from a subdomain:

; Employee mail continues at the apex domain
example.com.  IN  MX   1  inbound.mailbox-provider.example.

; Application sending identity
notify.example.com.  IN  TXT  "v=spf1 include:spf.transactional-provider.example -all"
_dmarc.notify.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; DKIM records supplied by your sending provider
selector1._domainkey.notify.example.com.  IN  CNAME  selector1.provider.example.
selector2._domainkey.notify.example.com.  IN  CNAME  selector2.provider.example.

Your app can then send from alerts@notify.example.com, while a visible reply address can remain support@example.com if that is appropriate for your workflow. Make sure that the Reply-To address is monitored, and remember that the envelope sender used for bounces can be separate from the visible From address.

This architecture makes it much harder for an application-mail onboarding task to overwrite the DNS that employees depend on.

Avoid the DNS collisions that look like MX problems

Not every email DNS failure is an MX failure. A record can be syntactically valid yet still conflict with another record at the same hostname.

Do not create a CNAME where other records already exist

A DNS name with a CNAME cannot also hold ordinary records such as MX, TXT, A, or AAAA. This catches teams when a sending provider asks them to create a CNAME and they use a hostname already assigned to mail routing or another service.

For example, this is a conflict:

mail.example.com.  IN  MX     10  inbound.example.net.
mail.example.com.  IN  TXT    "v=spf1 -all"
mail.example.com.  IN  CNAME  mail.vendor.example.

The solution is not to force the CNAME through. Choose an unused hostname, such as mail-links.example.com for tracking or bounce.example.com for a custom return path, then create only the records that belong at that hostname.

Do not use a CNAME at the zone apex (example.com) in standard DNS. The apex already needs SOA and NS records. Some DNS providers offer proprietary “flattening” behavior, but that does not make it a portable solution for email DNS. Treat email authentication and mail routing as normal DNS records at explicitly named hostnames.

Do not overwrite an existing SPF TXT record

SPF is evaluated from a single policy record beginning with v=spf1. Publishing multiple SPF policy TXT records at the same name can cause a permanent SPF error.

This is wrong:

example.com.  IN  TXT  "v=spf1 include:_spf.workspace.example ~all"
example.com.  IN  TXT  "v=spf1 include:spf.transactional.example ~all"

Merge authorizations into one record instead:

example.com.  IN  TXT  "v=spf1 include:_spf.workspace.example include:spf.transactional.example ~all"

Do not merge blindly. Every include, a, mx, redirect, and exists mechanism can add DNS lookups, and SPF evaluation has a limit of ten DNS-querying mechanisms. A complicated corporate setup can exceed the limit after adding only one more service.

Also, avoid using the SPF mx mechanism as a shortcut unless the servers named by your MX records genuinely send mail for the same identity. The mechanism authorizes the IP addresses behind your MX hosts. If your MX records identify inbound mailbox servers but your application sends through a separate relay, v=spf1 mx -all may authorize the wrong infrastructure and fail to authorize the application sender.

Do not confuse verification records with routing records

Domain ownership proofs are frequently TXT records. DKIM can use TXT records or CNAME delegation. Link tracking often uses a CNAME. None of these should be substituted for your inbound MX record.

Before saving DNS, classify every change in one of four buckets:

Inbound routing: MX records and the mail hosts behind them.
Sender authorization: SPF TXT records.
Sender identity and alignment: DKIM and DMARC records.
Ancillary mail features: tracking, return-path delegation, verification tokens, and webhooks.

If a requested record seems to belong in more than one bucket, stop and review the provider's documentation. A single hostname can have a focused role; a whole email architecture should not depend on assumptions about what a record “probably” does.

SPF, DKIM, and DMARC can expose a bad MX design

MX records do not authenticate outbound mail by themselves, but poor MX decisions often surface alongside authentication failures.

SPF: authorize the actual sender, not the inbound receiver

SPF evaluates the domain in the SMTP envelope sender, commonly called MAIL FROM, return-path, or bounce domain. It compares the sending IP address with the published SPF policy for that domain.

A simple policy might look like this:

notify.example.com.  IN  TXT  "v=spf1 include:spf.transactional-provider.example -all"

The record must match the actual domain used in the envelope sender. If a sending service uses a provider-controlled bounce domain by default, it may handle SPF itself. If you configure a custom bounce subdomain, publish the exact records it requires there.

Do not publish an SPF record at an unrelated hostname and assume it covers the whole domain. DNS does not work that way: bounce.notify.example.com, notify.example.com, and example.com are separate names with separate policies.

DKIM: keep selectors separate from other DNS functions

DKIM records live at names like:

selector._domainkey.example.com

A provider may give you a public key in a TXT record or ask you to publish a CNAME that delegates the selector to its infrastructure. Both methods are normal. What matters is that the selector hostname exactly matches the signing configuration and does not collide with a pre-existing record.

Multiple DKIM selectors are normal. They support key rotation and simultaneous use of multiple sending systems. You do not need to remove an old selector merely because you add a new one, provided the old system is still signing with it.

DMARC: align the visible From domain with authentication

DMARC evaluates the RFC 5322 visible From domain that recipients see in their mail client. It passes if SPF or DKIM passes and aligns with that From domain under the policy's alignment rules.

A monitoring-first DMARC record might be:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

p=none requests monitoring rather than quarantine or rejection. It is a sensible starting point while you inventory every legitimate sender. Move to p=quarantine or p=reject only after reports show that expected traffic passes alignment.

This connects back to MX planning because a sender's visible From address often receives replies. If you send from billing@example.com but no one can receive mail at example.com after an MX change, your DMARC may look perfect while the real customer experience is broken.

A safe change process for mail DNS

Do not make mail DNS edits as one-off copy-and-paste changes in a production dashboard. Treat them as an infrastructure change with a record inventory, owner, rollback plan, and verification window.

1. Inventory the current authoritative DNS

First, find the DNS provider actually serving your domain's authoritative nameservers. Your registrar and your DNS host are not always the same company.

Run these commands from a terminal:

dig +short NS example.com
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

To inspect the full answer, including TTLs and authority information:

dig MX example.com
dig TXT example.com
dig +trace MX example.com

On Windows, use:

nslookup -type=mx example.com
nslookup -type=txt example.com

Record every existing MX target and its priority before editing. Also identify which team owns it: IT, workplace operations, a managed service provider, a legacy application, or a security gateway. “Nobody remembers why it is there” is not a safe reason to delete it.

2. Write down the intended mail flow

Answer these questions in a change ticket or runbook:

Which system receives @example.com mail today?
Which system sends application mail?
Which visible From domains will the app use?
Where should human replies go?
Which envelope-sender domain receives bounces?
Is there a support desk, forwarding rule, or inbound parser depending on an MX record?
Which vendors currently publish SPF includes or DKIM selectors?
Who can roll back the DNS change if inbound delivery fails?

This turns a vague “set up email” task into explicit routing decisions.

3. Add new records; do not replace unrelated ones

If the provider asks for a DKIM CNAME at s1._domainkey.notify.example.com, add that exact CNAME. Do not touch example.com MX unless the change request is specifically about inbound mail routing.

If you need a new sending identity, prefer a dedicated subdomain. This avoids sharing the root domain's SPF policy, DKIM selector namespace, tracking hostname, and operational ownership with employee mail.

4. Respect TTL, but verify authoritative answers

TTL controls how long resolvers may cache a DNS answer. Lowering a TTL before a planned migration can shorten the time that old answers remain cached, but it does not instantly purge caches that already stored the old TTL.

Check the authoritative nameservers directly when possible, then check from several public recursive resolvers. Tools such as MXToolbox are useful for quickly inspecting MX records and basic diagnostics. Use them as a second opinion, not as a replacement for checking your authoritative DNS configuration.

5. Test both directions of mail

A successful outbound send is only half the test. Test:

Send an application message to a mailbox you control.
Reply to that message and confirm the reply reaches the intended inbox.
Send a new message from an external mailbox to a root-domain address such as support@example.com.
Test any sending subdomain that is intended to receive replies.
Trigger a controlled invalid-recipient bounce where your provider supports it, and confirm that the event is processed correctly.
Review SPF, DKIM, and DMARC results in received-message headers.

For a deliverability-oriented message test, mail-tester.com can provide a disposable test address and report on authentication, server configuration, blacklists, and content signals. It is a useful diagnostic, but it cannot prove inbox placement for every recipient population.

Read failures correctly: SMTP and HTTP status codes

A sender can report success even when your MX records are wrong, because the two events occur at different points in the delivery chain.

Outbound submission results

For an HTTP email API, these are common categories:

200 OK or 201 Created: the API processed the request successfully, depending on the provider's contract.
202 Accepted: the service accepted the message for asynchronous processing or queueing.
400 Bad Request: the request is malformed or fails validation.
401 Unauthorized or 403 Forbidden: authentication or authorization failed.
422 Unprocessable Content: semantically invalid input in APIs that use this status.
429 Too Many Requests: rate limit reached.
5xx: service-side failure or temporary unavailability.

Exact response bodies and status choices vary by provider. Code your integration to parse the provider's documented error schema and message identifier, rather than treating every non-2xx response identically.

For SMTP submission, a 250 response after DATA generally means the relay accepted the message. A 235 response is commonly used for successful SMTP authentication. Neither response guarantees final recipient delivery.

Destination and MX-related failures

When an outbound provider tries to reach the recipient domain, relevant results can include:

550 5.1.1: the destination mailbox does not exist or is unavailable.
550 5.1.2: the destination system address is invalid or unable to accept mail; this can appear when the recipient domain has no valid mail destination.
421 4.4.2: a temporary connection or routing problem, often worth retrying.
451 4.4.3: a temporary directory-server or DNS-related failure can be reported by some systems.
554 5.7.1: a policy, authentication, reputation, or security rejection; this is not inherently an MX error.

A 4xx result is usually temporary and should be retried according to your provider's queueing policy. A 5xx result is generally permanent for that attempt and should be classified rather than blindly retried. Store provider event data and enhanced status codes so your application can distinguish a bad recipient address from a transient DNS outage.

Before sending high-value transactional messages, validate user-entered addresses. A dedicated email address verification tool can reduce avoidable hard bounces, although no verifier can guarantee that a mailbox will accept every future message.

Common MX record conflict scenarios and fixes

“We changed MX records to verify our sending domain”

This is usually an implementation mistake. Domain verification commonly uses a TXT or CNAME record, not MX. Restore the prior inbound MX configuration from your DNS history or change record, then add only the verification record requested by the sending service.

After restoring, test mail from an outside mailbox to multiple real addresses at the domain. Do not rely only on a test from another user at the same provider, because internal routing can conceal external DNS problems.

“We added the transactional provider as an MX backup”

Remove it unless the provider explicitly offers inbound mail hosting or a receiving endpoint you have configured to accept mail for your domain. A transactional relay is not automatically a mailbox failover system.

An MX backup must be able to accept inbound SMTP for the domain, preserve recipient validity or queue mail appropriately, and route mail to the primary destination without becoming an open relay. Those are inbound-mail responsibilities, not normal outbound API features.

“Our app sends successfully, but customers cannot reply”

Check the visible From address and Reply-To header first. Then query the MX records for the Reply-To domain, and send an external test message to that address.

If your app sends from receipts@notify.example.com, but only example.com has mailbox MX records, decide whether replies to notify.example.com are expected. If they are, configure an inbound destination for that subdomain. If they are not, use a monitored Reply-To address at example.com and make the choice clear in the message copy.

“SPF began failing after an MX migration”

Look for mx in your SPF policy. If it exists, changing MX targets changes which sending IP addresses the SPF policy authorizes. That is a hidden dependency.

Replace an overly broad mx mechanism with explicit authorization for the actual outbound systems where feasible, such as the provider's documented include: domain. Recheck the total SPF DNS lookup count after every change.

“The DNS dashboard will not let us add the record”

The dashboard may be preventing a legitimate conflict. Check whether the hostname already has a CNAME, whether you are trying to create a second SPF policy TXT record, whether the host field has been entered twice, or whether the dashboard automatically appends your domain.

For example, when editing the example.com zone, a host field of notify often represents notify.example.com. Entering notify.example.com may produce notify.example.com.example.com in some interfaces. Verify the final published name with dig, not just the dashboard preview.

Operational practices that keep mail routing stable

Email DNS is shared infrastructure. A marketing tool, support platform, identity provider, and transactional service can all ask for records under the same domain. Reliability comes from process as much as from correct syntax.

Maintain a simple domain mail map with these columns:

DNS name	Record type	Purpose	Owner	Change source	Last verified
`example.com`	MX	Employee inbound mail	IT	Mailbox provider	Date
`example.com`	TXT	Root SPF policy	Email platform team	Combined policy	Date
`_dmarc.example.com`	TXT	DMARC policy/reporting	Security	DMARC rollout	Date
`s1._domainkey.notify.example.com`	CNAME	App-mail DKIM	Engineering	Transactional sender	Date
`click.notify.example.com`	CNAME	Branded tracking	Lifecycle team	Transactional sender	Date

Review this map before adding vendors and before removing “unused” records. Retire a record only after you have confirmed that no active sender, inbound forwarding rule, or legacy application depends on it.

Also separate credentials and code paths from DNS. Your application should use environment variables or a secrets manager for SMTP credentials and API keys. DNS changes should be made through approved infrastructure tooling or a documented manual process, not embedded in deployment code or performed opportunistically during an incident.

Conclusion: preserve inbound routing, add outbound identity deliberately

Avoiding MX record conflicts is less about memorizing priorities and more about assigning one clear purpose to each DNS name. MX records belong to inbound mail routing. Transactional email APIs and SMTP relays belong to outbound submission. SPF, DKIM, and DMARC establish sending authorization and identity. Tracking and bounce domains are separate supporting functions.

When you add a transactional provider, do not replace your working MX records by default. Inventory current mail flow, use a dedicated sending subdomain where appropriate, merge SPF carefully, keep DKIM selectors distinct, and test replies as well as sends. That approach protects both deliverability and the ordinary inbound mail your organization depends on.

FAQ

Do I need to change MX records to send transactional email?

Usually, no. Transactional mail is normally sent through an HTTPS API or authenticated SMTP relay. You typically add authentication or verification records such as SPF, DKIM, and sometimes CNAME records, while leaving the MX records that route inbound mail unchanged.

Can I have multiple MX records for different email providers?

You can have multiple MX records for redundancy, but each listed host should be intentionally configured to receive mail for the same domain. Do not use MX priority to split employee email, transactional email, and marketing email between unrelated providers.

Can I point an MX record to an IP address or CNAME?

No. An MX record target should be a hostname that resolves directly to A and/or AAAA records. Do not use an IP address as the target, and do not point MX records at a CNAME.

Why did SPF break after I changed MX records?

Your SPF policy may use the mx mechanism, which authorizes the IP addresses behind the domain's MX hosts. Changing MX records can therefore change SPF authorization. Review the SPF record and authorize your actual outbound sender using the provider's documented method.

Should a sending-only subdomain have an MX record?

Only if you expect it to receive mail, including replies or bounces directed there. A sending-only subdomain commonly needs SPF, DKIM, and DMARC; its inbound behavior should be designed deliberately rather than assumed from the parent domain.

MX Record Conflicts: Avoid Breaking Your Email Flow