MX Record Checker
Check any domain's MX records and preference order in seconds, free, no signup. A missing or misdirected MX is a common reason inbound mail never arrives.
What is an MX record in DNS?
An MX (Mail Exchange) record is the DNS record that names the servers responsible for receiving email on behalf of a domain. Each record carries a preference number, and sending servers work through them from the lowest number up. Without an MX record, senders fall back to the domain's A or AAAA record under RFC 5321's implicit MX rule, usually a web server with no mail service, so delivery fails after days of retries rather than immediately.
How to read your result
| Result | What it means | What to do |
|---|---|---|
| Mail exchange (MX) record is present | The domain publishes at least one mail exchange host, listed here in preference order. | Confirm every host belongs to a provider you still use. A retired host left in the list can take delivery attempts with it. |
| MX record is missing | No mail exchange host is published. Senders fall back to the domain's A or AAAA record under RFC 5321's implicit MX rule, which is rarely a mail server, so delivery fails slowly. | Publish an MX record for your mail provider. If the domain is never meant to receive mail, publish a null MX instead. |
| Null MX (preference 0, host .) | The domain deliberately declares that it accepts no email, under RFC 7505. This is correct for a website-only or send-only domain. | Nothing, if that is intended. If the domain should receive mail, replace it with a real MX record for your provider. |
| Multiple hosts at different preferences | Senders try the lowest preference number first and fall back down the list when a host is unreachable. | Check that the fallback host actually accepts mail for the domain. A backup that rejects delivery is worse than no backup. |
| Domain is used for advertising | The domain is on the advertising-domain list and is not audited. | Use the domain your organization actually sends and receives mail on. |
| Domain could not be audited | The domain does not exist, or its DNS is not publicly resolvable from our side. | Re-check the spelling and confirm the domain's name servers answer public queries. |
What this checker can prove
Palisade's MX checker proves what public DNS returns for the domain's mail exchange records: which hosts are published, in what preference order, and whether the domain publishes a null MX declaring that it accepts no mail. It does not connect to those hosts, so it cannot tell you whether a server is currently accepting connections, whether a specific message was delivered, or how a receiver will filter mail once it arrives.
MX answers inbound routing only. Whether your outbound mail is trusted is a separate question, settled by SPF, DKIM, and DMARC: run the email security score to see all four at once.
From a published record to mail that actually arrives
A correct MX record gets mail to your server. Getting your own mail accepted by everyone else is the harder half, and it runs on evidence: which senders use your domain, whether each one aligns under SPF or DKIM, and what receivers report back. Palisade turns DMARC aggregate reports into a prioritized workflow so operators can identify senders, investigate alignment failures, review proposed record changes, and move each domain toward enforcement.
For MSPs it's built multi-tenant: every client domain checked, remediated, and enforced from one console, with portfolio-based per-client-domain pricing whose rate improves as you scale, without metering client email volume.
Related checks and terms
DMARC software that does the work
Palisade organizes DMARC report evidence into prioritized sender and alignment work, helping operators review changes and move domains toward enforcement from one console.
1 domain free up to 1,000 emails/month
Email authentication knowledge base
How do MX records work?
MX records point to the host names of the servers that receive email for your domain, never to IP addresses directly. Each record carries a preference number. A sending server looks up your MX records and tries the lowest preference number first; if that host is unavailable, it tries the next one.
Why do domains publish more than one MX record?
Multiple records give a domain somewhere else to deliver when the primary host is unreachable. Senders work through the list in preference order, so a second host reduces the risk that a temporary outage turns into bounced or delayed mail.
How do I set up MX records for my domain?
Open the DNS management interface at whatever provider hosts your domain's DNS, add one MX record per receiving host, and give each a preference number. The host names you point at must themselves resolve through A or AAAA records.
What does a null MX record mean?
A single MX record with preference 0 and a host of "." (the root label) is a null MX, defined in RFC 7505. It is a deliberate statement that the domain accepts no email at all, which is the correct configuration for a domain used only for a website or only for sending. Senders reject mail to it immediately instead of falling back to the address record and retrying for days.
What happens if my MX records are missing or wrong?
Mail does not simply stop. Under RFC 5321 a domain with no MX record is treated as having an implicit one at preference 0 pointing to the domain itself, so senders fall back to its A or AAAA record. That is usually a web server with no mail service, so delivery fails after days of retries rather than immediately. If the domain is not meant to receive mail, publish a null MX and senders get a clear answer on the first attempt.
How long do MX record changes take to take effect?
Changes propagate as cached copies expire, which is governed by the TTL on the records. Until every resolver's cached copy expires, some senders still use the old value, so keep the previous host accepting mail until the change has fully rolled out.
Can I use the same server for MX and website hosting?
Technically yes, but separating them is usually better for both performance and security, and it means a web outage does not also stop mail delivery.
Do MX records affect email authentication?
Not directly. MX governs inbound routing, while SPF, DKIM, and DMARC govern how your outbound mail is authenticated. They matter together: the hosts you receive on are frequently the same platform you send through, and that platform is what has to be authorized in SPF and signing with DKIM.
What are the most common MX mistakes?
Pointing an MX record at an IP address instead of a host name, pointing it at a host that has no A or AAAA record, leaving a retired provider's host in the list after a migration, and removing MX entirely on a domain that should publish a null MX.
Can I use a third-party email provider with my domain?
Yes. Point your MX records at the host names that provider gives you, remove the previous provider's records once the migration is complete, and update SPF and DKIM at the same time so your outbound mail stays authenticated.
Every tag and mechanism across DMARC, SPF, and DKIM, explained in one place.
DMARC
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.
SPF
- v
- The version tag must exclusively be “spf1”. Incorrect or missing versions result in the SPF record being disregarded.
- ip4
- This tag lists IPv4 addresses authorized to send emails for the domain.
- ip6
- This tag specifies IPv6 addresses permitted to email on the domain’s behalf.
- a
- The A record tag permits sender validation via the domain’s IP address, defaulting to the current domain if unspecified.
- mx
- The MX record tag validates the mail server’s MX record, defaulting to the current domain if not specified.
- ptr
- The PTR tag initiates a PTR check for client IP hostnames, advised against in RFC 7208 due to excessive DNS lookups.
- exists
- The exists tag verifies the presence of an A record on the specified domain.
- include
- The include tag is crucial for accurate SPF records, confirming all listed domains/subdomains as legitimate sending sources to recipients.
- all
- The all tag is mandatory, positioned at the SPF record’s end, guiding recipients on handling emails from unauthorized sources based on its qualifiers (~, +, -, ?).
DKIM
- v
- The version tag specifies DKIM’s version, consistently required to be 1.
- p
- The public key tag, a character string created in DKIM setup, must not be left empty to remain valid.
- t
- This tag enumerates flags as a colon-separated sequence, with “y” and “s” as defined flags; any undefined flags should be disregarded.
- s
- This tag details service types relevant to the record. Absent or unrecognized service types must be overlooked by receiving servers.
- h
- This tag specifies permitted hash algorithms, defaulting to allow all. Receivers should ignore unknown algorithms, with the sender determining the list’s entries.
- n
- This tag serves as an optional note field for administrators, recommended for use only when needed.