Query and retrieve Mail Exchange (MX) records for any domain name. Check mail server prioritizations.
An MX (Mail Exchanger) record is a specific type of resource record in the Domain Name System (DNS) that specifies the mail server responsible for accepting email messages on behalf of a domain name. Unlike A records, which map a hostname to an IP address, MX records map a domain to a mail server hostname, ensuring that Simple Mail Transfer Protocol (SMTP) traffic is routed to the correct destination.
When an email is sent to user@example.com, the sending Mail Transfer Agent (MTA) queries the DNS for the MX records of example.com. The DNS response provides one or more hostnames and an associated preference value (priority). The MTA attempts to deliver the mail to the server with the lowest numerical priority value first.
The priority value is critical for establishing failover mechanisms. By assigning different values, administrators can designate primary and backup mail servers. For example, a server with priority 10 is preferred over one with priority 20. If the primary server is unreachable, the sending server automatically pivots to the next available record in the priority queue, preventing data loss and ensuring high availability of communication channels.
A standard MX record consists of the domain, the TTL (Time to Live), the class (usually IN for Internet), the type (MX), the priority, and the target mail server. It is important to note that MX records must point to a hostname (A or AAAA record) and never directly to an IP address; doing so violates RFC 1035 and can lead to email delivery failures across various mail providers.
To utilize this tool, enter the fully qualified domain name (FQDN) into the search field. The system will perform a recursive DNS query to fetch all associated MX records, resolve the target hostnames to their respective IP addresses, and display the priority hierarchy.
Developers can automate MX lookups using system-level tools or programming libraries. Below is a professional implementation using bash via the dig command and a Python approach using the dnspython library.
# Using dig in Bash for a quick lookup
dig example.com MX +short
# Python implementation using dnspython
import dns.resolver
answers = dns.resolver.resolve('example.com', 'MX')
for rdata in answers:
print(f'Host: {rdata.exchange} Priority: {rdata.preference}')Integrating these lookups into a CI/CD pipeline allows teams to validate DNS changes before deploying production mail server migrations.
MX lookups are public DNS queries and do not expose sensitive server internals. However, analyzing MX records can reveal the email service provider (e.g., Google Workspace, Microsoft 365), which is why security professionals use this data to audit SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records to prevent spoofing and phishing attacks.
This tool is engineered for a variety of technical roles requiring precise DNS visibility:
Multiple MX records are implemented to provide redundancy and high availability for email reception. The priority number (preference) tells the sending server which host to try first; the lowest number indicates the highest priority. If the primary server (e.g., priority 10) is offline or times out, the sending MTA will automatically attempt delivery to the next server (e.g., priority 20), ensuring that emails are not bounced back to the sender during server maintenance or outages.
No, according to RFC 1035 and subsequent DNS standards, an MX record must point to a domain name (an A or AAAA record) and not an IP address. If you configure an MX record with an IP address, many sending mail servers will treat the record as invalid and fail to deliver the email. To correctly route mail, you must create an A record for your mail server (e.g., mail.example.com) and then point your MX record to that hostname.
An A record maps a hostname to a physical IP address, serving as a general-purpose pointer for any traffic. An MX record is a specialized pointer that specifically tells the rest of the internet which server is designated to handle email for that domain. While an A record for 'example.com' might point to a web server, the MX record for 'example.com' points to the specific mail server, allowing the web and email functions to reside on different hardware or services.
The time it takes for MX changes to propagate depends on the Time to Live (TTL) value assigned to the record. The TTL tells recursive DNS servers how long to cache the record before checking for a new version. If the TTL is set to 3600 seconds, it can take up to one hour for the change to be recognized worldwide. During a migration, it is recommended to lower the TTL to 300 seconds a few days before the switch to ensure a rapid transition.
If no MX records are found, most sending MTAs will fall back to attempting delivery to the A record (or AAAA record) of the domain itself. This is known as 'fallback delivery.' However, this behavior is not guaranteed across all mail servers and is considered unreliable. For professional email delivery, explicitly defining at least one MX record is mandatory to avoid intermittent delivery failures and to ensure compliance with modern spam filters.