MX record conflicts
Why Mailfully's MX record sits on a sending subdomain and cannot collide with the Google Workspace or Microsoft 365 records at your apex.
Mailfully's MX record goes on send.mail.acme.com, not your apex. Your inbound mail MX stays at acme.com, and MX records are looked up per name, so the two records never compete for the same lookup.
Why there is an MX record at all
The MX record serves the custom MAIL FROM subdomain, which is what lets SPF align and where SES routes bounce feedback. See Publishing your DNS records for what each of the six records does.
Where each record lives
| Name | Record | Serves |
|---|---|---|
acme.com | Your mail provider's MX | Inbound mail to your organization |
<token>._domainkey.mail.acme.com | Mailfully's three DKIM CNAMEs | Signing outgoing mail |
send.mail.acme.com | Mailfully's MX and SPF TXT | The custom MAIL FROM subdomain |
Google Workspace and Microsoft 365
Adding Mailfully's records does not touch inbound mail. You do not remove, replace, or modify the MX records Google Workspace or Microsoft 365 hold at your apex; Mailfully's MX lives on a different name entirely.
One SPF record per name
The constraint people actually run into is about TXT, not MX. A single name must not carry two SPF records: publish two on the same name and both are invalid, since there's no merge step to reconcile them. Mailfully's SPF TXT lives on send.mail.acme.com, so it does not interact with an SPF record on your apex at all. If you already publish an SPF TXT on that exact subdomain, merge include:amazonses.com into the existing record instead of adding a second one.
Verify
Query both names side by side and compare the results:
dig +short acme.com MX
dig +short send.mail.acme.com MXThese are separate lookups against separate names. send.mail.acme.com should return Mailfully's MX; acme.com returns whatever your mail provider publishes there, or nothing at all if the domain is used only for sending.