Check MX Ownership Before Connecting an Email Sending Domain

Before adding Migma’s MAIL FROM MX record, identify the exact DNS hostname and the service that currently owns it. Preserve the records that route business inbox mail, and resolve any collision at the proposed MAIL FROM name before making a change.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 13, 2026.

Migma’s MX guidance distinguishes the sending domain’s send hostname from the inbox domain. We recommend following that separation when connecting Migma because it gives the DNS owner a precise change to review. Do not turn a provider setup screen into permission to replace unrelated inbound routing.

Draw the names in full#

For a fictional brand using example.com, the intended map might be:

These are illustrative reserved-domain names, not values to copy into a live zone. Migma’s documentation describes send.[sending-domain]; use the actual hostname and target supplied for your setup.

The similarity of two names does not make them interchangeable. A record at the root and a record at a deeper hostname can have different owners and purposes. Write the full name in the change ticket so a short label such as “send” is not interpreted relative to the wrong zone.

Inspect before editing#

A DNS owner can begin with read-only queries for the actual names:

dig MX example.com
dig MX mail.example.com
dig MX send.mail.example.com

The commands above demonstrate the query shape only. Replace the reserved example domain with the approved domain when conducting a real review. Record the resolver, query time, full answers, and relevant TTL values. A missing answer from one recursive resolver should prompt investigation, not immediate certainty that no production service uses the name.

Compare the query result with the DNS provider’s zone view and the current service owner’s configuration. Also check whether the interface expects a relative host label or a fully qualified name. Migma’s guide notes that some DNS interfaces append a domain to an MX target; inspect the resulting full value rather than relying on the text entered into one field.

A collision is an ownership question#

If the exact MAIL FROM name already points to another active provider, stop and determine what uses it. Do not assume changing priorities makes two unrelated services coexist safely. A priority edit changes routing preference; it does not establish that the services agree about handling the mail.

Ask the owner whether the old use is retired, whether another supported hostname is appropriate, or whether migration work is required. Keep the answer and rollback values in the change record. The Migma guide describes seeking support for custom MAIL FROM configuration; verify the available option for the actual account before planning around it.

For teams using a connected provider, confirm the selected route. Migma’s Mailgun integration requires the domain to be ready in Mailgun. That does not justify applying a different provider’s DNS values to the same hostname.

Approve a bounded change record#

The record should name the exact record set, current values, intended values, business owner, validation method, and restoration plan. It should also state which inbox-routing names must remain untouched. Have the DNS owner review that concrete proposal before applying it through the organization’s normal process.

After an authorized change, compare the intended record with the published DNS answer and the provider’s verification state. Separately verify normal business inbox operation using an approved mail test. A green sender-verification badge alone is not evidence that every unrelated inbox route remains intact.

This differs from the sending-domain rollout guide, which focuses on reputation and rollout. Here the concern is exact-name ownership and preserving inbound routing. Begin by filling the three-name map with the actual domain owner; no DNS mutation is needed to make the review useful.