Definition
An MX record has three parts: the domain it belongs to, a priority (lower is tried first), and a target hostname. The target must be a hostname with its own A or AAAA record; an IP address is not valid in an MX record. A domain may publish several MX records to provide fallbacks.
Why it matters
The MX record is the switch. Whatever host it names receives the domain's mail; everything else (mailboxes, SPF, DKIM) is only useful once it points at the right place. Changing email provider is, at its core, changing this one record. A wrong or missing MX record means mail bounces back to the sender or is silently delivered to an old host.
How it works
- A user at another organisation sends a message to someone@yourdomain.co.zm.
- Their mail server queries DNS for MX records on yourdomain.co.zm.
- It receives, say,
10 mx.provider.exampleand20 mx2.provider.example. - It resolves mx.provider.example to an IP address and connects on port 25. If that fails it tries the priority-20 host.
- The receiving host checks that the recipient exists, applies filtering, and stores the message.
Example
yourdomain.co.zm. 3600 IN MX 10 mail.provider.example.
Read as: for yourdomain.co.zm, cache for 3600 seconds, the priority-10 mail exchanger is mail.provider.example. The trailing dot marks a fully qualified name. In a registrar's panel this becomes: type MX, host @, priority 10, value mail.provider.example.
Common problems
- IP address as the target. Many senders reject it outright. Use a hostname.
- Target has no A record. The hostname must resolve. Check it separately.
- Old MX record still cached. After a change, resolvers keep the old answer until the TTL expires. Lower the TTL a day before a migration.
- MX on the wrong name. Publishing the record on
mail.yourdomaininstead of the bare domain means mail for you@yourdomain is not covered. - Two providers at once. Records pointing at two unrelated hosts split delivery unpredictably. Keep one provider's records only.
- CNAME at the apex. A CNAME on the bare domain conflicts with MX and other records. Use A records at the apex.
How ontechmail handles it
When you add a domain, the dashboard displays the exact MX record to publish, alongside the SPF, DKIM and DMARC records, with copy buttons and instructions for common registrars. The platform re-checks DNS on a schedule; as soon as the MX record resolves to ontechmail the domain is marked verified and inbound mail is accepted. If DNS is hosted on ontechmail's nameservers, the record is created for you. For self-hosted deployments behind an ISP that blocks inbound port 25, the MX record points at Ontech's relay, which forwards mail over a tunnel to your server. The step-by-step order for a migration is on the custom domain email page.
Frequently asked questions
What is an MX record?
An MX (mail exchanger) record is a DNS record that names the server responsible for receiving email for a domain, with a priority number. Sending servers look up the MX record, then deliver to the lowest-priority host that answers.
Can a domain have more than one MX record?
Yes. Multiple MX records with different priorities give senders a fallback if the primary host is unreachable. Equal priorities are used in round-robin.
What happens if my MX record is wrong?
Mail bounces back to senders or is delivered to the wrong host. A common mistake is pointing MX at an IP address; it must point at a hostname that itself has an A record.
What MX record does ontechmail use?
The dashboard shows the exact hostname and priority for your domain when you add it, along with the SPF, DKIM and DMARC records, each with a copy button.