An MX record indicates which servers receive mail for a domain. It points to a hostname. The resolver follows this name to find A or AAAA records. The sending server can then deliver the messages.
An MX record contains a name, a type, a priority, a target, and a TTL. The TTL indicates how long the response remains cached in the local resolver.
| Name | Type | Priority | Target | TTL in seconds |
|---|
| @ | MX | 10 | mail.example.net. | 3600 |
In this example, the name @ targets the domain root. The target is a hostname that must publish A or AAAA. A lower priority is preferred. A TTL of 3600 corresponds to one hour.
Publishing multiple MX records for the same name is common. The sending server first chooses the lowest priority. In case of failure, it tries the next one.
| Name | Type | Priority | Target | TTL in seconds |
|---|
| @ | MX | 10 | mx1.example.net. | 3600 |
| @ | MX | 20 | mx2.example.net. | 3600 |
This redundancy increases service continuity. It does not replace active monitoring or regular testing.
An MX record points to a name, not to an address. The target must not be a CNAME. The targeted name must publish A or AAAA and be reachable on port 25. The MX can exist at the apex or on a subdomain if the email address uses this subdomain.
A short TTL makes a change visible faster. Useful when switching to a new messaging service.
A medium or long TTL reduces queries to authoritative servers. Suitable for a stable service.
Reduce the TTL a few hours before the switch, then increase it when everything is validated.
Good to know
MX records are used for reception. Outgoing mail uses other settings like SPF, DKIM, DMARC and outbound relay configuration.
Publish the MX on the domain that receives mail. Most often, this is the root. For a dedicated domain like support.example.com, publish the MX on this subdomain. The messaging hosts referenced by MX records keep their own A or AAAA.
To avoid
Pointing an MX to a CNAME or to a direct address.
Forgetting the A or AAAA record of the target.
Leaving an old MX active after a migration.
An online DNS lookup allows you to enter a domain name. You get the list of MX with their priorities, their targets and the TTL visible from the Internet. This is a useful first check. Then do a local test from your machine.
Windows provides nslookup. You can use it in interactive mode.
nslookup
set q=mx
example.com
nslookup
set q=mx
server 1.1.1.1
example.com
The first part queries according to the machine's network configuration. The second forces the use of a third-party resolver, here Cloudflare's.
On these systems, the dig command is convenient and easy to use.
dig MX example.com
dig MX example.com @1.1.1.1
Multiple lines indicate multiple servers. The smallest priority number is preferred. Identical priorities share attempts in a balanced manner.
A high remaining TTL can explain a lag after a change.
A target without A or AAAA prevents delivery.
- Prepare messaging hosts with their A or AAAA.
- Reduce the TTL of MX to 300 or even 60 seconds a few hours before the switch.
- Add the new MX with the planned priority. Keep the old ones during the transition.
- Test reception from multiple networks. Check the headers of received messages.
- Remove the old MX then increase the TTL when everything is stable.
Practical tip
Note the complete list of MX before modification. Keep the date, priorities, TTL and reason for the change. This trace avoids errors and facilitates a rollback.
Publish the MX provided by the provider. The targets belong to the provider's domain. Keep a reasonable TTL.
Point the MX to the filtering provider. This provider then relays to your servers. Monitor latency and availability.
Declare a secondary server with a higher priority. It holds messages if the primary server is unavailable, then delivers them when it returns.
- In case of bounce, verify that the MX target resolves to A or AAAA.
- Check network accessibility on port 25 to the target.
- If MX still point to the old provider, remove them after the switch.
- If the response remains old, wait for TTL expiration and purge the local resolver cache if possible.
In summary, an MX record indicates the receiving server for a domain. It points to a hostname that publishes A or AAAA. The lowest priority is chosen first. A well-chosen TTL facilitates changes. Verification goes through an online tool, then through nslookup and dig.
With these landmarks, management remains clear. Changes proceed without stress. Messages arrive without incident.