MX record

An MX record, or Mail Exchanger, specifies which servers receive email intended for a domain. When a system sends a message to an address like [email protected], the sending server queries the DNS to locate the MX records for example.it and contacts one of the listed servers. Each record includes a hostname and a priority value: lower numbers typically indicate higher preference. If the preferred server is unavailable, the sender may attempt others based on delivery and retry rules. This mechanism ensures reliable mail routing even when primary servers are temporarily inaccessible.

Server Configuration

The MX value is a hostname, not an IP address. The specified hostname must resolve via A or AAAA records and must be capable of accepting mail for the domain. Setting an MX without configuring the receiving server does not create an email mailbox. Similarly, creating a mailbox with a provider is insufficient if the DNS zone does not point to their servers. Email providers typically offer multiple MX records for redundancy, each with specific priorities and values; copying official configurations avoids typing errors. Proper configuration ensures that mail reaches its intended destination without disruption.

A domain that does not publish MX records can, according to DNS rules, use its own A/AAAA record as a fallback for email delivery, but this is not recommended for modern services and may cause unwanted or failed deliveries. To explicitly disable mail reception, the Null MX record standard exists. The choice must be intentional: removing MX records is not always equivalent to a secure "no mail" configuration. Misconfigurations can lead to misdirected emails or complete delivery failures if not carefully managed.

MX and Email Authentication

MX handles incoming mail; it does not authorize sending alone. SPF publishes policies on which servers are allowed to send, DKIM signs messages, and DMARC defines how to handle messages that fail checks and specifies report reception. These records are distinct and must be configured together according to the provider’s guidelines. Changing nameservers or transferring a zone without copying TXT and authentication records can increase spam or bounces, even if incoming mail continues to function. A complete setup requires all relevant DNS records to be properly aligned for security and functionality.

To verify email, one first checks the authoritative MX response, then resolves hostnames, tests reachability, and confirms service configuration. Records may remain cached up to their TTL value. Changes are tested using test addresses for both sending and receiving, reviewing headers, spam status, bounces, and provider logs. A DNS panel showing a saved record does not confirm that public delegation points to that provider. Verification must include actual testing of mail flow and server responses to ensure proper operation.

Priority, Backup, and Migration

MX priorities help define primary and secondary servers, but backup servers must be configured to queue and properly deliver mail—not just listed in DNS. Two records with the same priority allow load distribution based on the sender’s implementation. Before migrating email, prepare the new service, transfer mailboxes and aliases, lower TTL when appropriate, and update MX within a controlled window. Old mailboxes can remain active during transition to prevent lost messages. Proper planning ensures continuity of communication and avoids disruptions in email delivery.

In summary, the MX record directs incoming mail to designated mail hosts. It must be configured alongside the actual mail service and SPF, DKIM, and DMARC policies. Migration requires zone copying, real-world sending and receiving tests, and cache verification. A well-configured MX setup supports reliable email delivery and enhances overall system security through proper integration with authentication standards.