MX Record Errors Explained: "Doesn't Have 2 Fields", "Default Value", "Not Found"

What a correct MX record looks like

An MX record lives at a name (usually your root domain) and holds two fields:

Field	Example	Notes
Name / host	@	@ or blank means the root domain on most DNS hosts
Priority	1	Lower number is tried first
Value / target	smtp.google.com	A hostname with an A/AAAA record
TTL	Auto or 3600	Lower it before a migration

In zone-file form it reads example.com. 3600 IN MX 1 smtp.google.com. Check what's actually published with the MX lookup, or many domains at once with the bulk MX lookup.

"MX record doesn't have 2 fields"

The checker parsed the record value and didn't find "number, space, hostname". Common causes:

• Priority missing. The panel has a single value box and expects 10 mx.example.net, but only the hostname was typed.
• Priority typed into the value and the priority box. Some panels then store 10 10 mx.example.net.
• Extra text pasted from a guide, like MX 10 mx.example.net or a trailing comment.
• A TXT or CNAME value put into an MX row during a bulk import.

Fix: delete the row and recreate it using the panel's own fields. If the panel has a separate priority box, put only the hostname in the value. If it doesn't, put priority hostname with a single space. Many panels accept a trailing dot (smtp.google.com.); some add it themselves. Follow the host's documentation.

"MX record name set to default value"

This one is about the name/host field, not the value. It shows up when:

• the name is a leftover placeholder the DNS host created (some panels pre-fill rows for parked domains or the host's own mail service);
• the full domain was typed into a panel that appends the domain automatically, so example.com becomes example.com.example.com;
• the record was created on www or mail instead of the root.

Fix: for mail to [email protected], the MX belongs on the root: @ on most hosts, blank on some. Then remove any default MX rows the host created for its own mail service, unless you actually use it. Mixed MX rows from two providers split incoming mail between them, which looks like random lost email and random bounces.

"MX record not found"

The lookup for MX at that name returned nothing. Work through it in this order:

1. Nameservers. Look up the domain's NS records. If they point to Cloudflare but you edited the registrar's panel, your record isn't live anywhere. Edit DNS where the nameservers point.
2. Exact name. A record on mail.example.com doesn't answer for example.com.
3. Propagation. New records usually appear within minutes, but resolvers can cache the old "no record" answer for the previous TTL. Check from several resolvers with the DNS propagation checker.
4. A null MX. A record 0 . deliberately says the domain takes no mail. If that's not what you want, remove it. See null MX records.

If a domain truly has no MX, senders may fall back to its A record, but many verifiers and spam filters treat a missing MX as a strong sign the domain doesn't take mail. See how to check if a domain accepts email.

"MX points to an IP address" or "MX points to a CNAME"

Both are invalid. The MX target must be a hostname, and that hostname must resolve through an A or AAAA record, not a CNAME (RFC 2181, section 10.3). Some receiving servers tolerate a CNAME, many scanners flag it, and the safe answer is not to rely on tolerance.

Fix for a self-hosted server: create mail.example.com A 203.0.113.10 (your server's IP), then @ MX 10 mail.example.com. For a hosted provider, use the exact hostnames they publish.

Other MX warnings you'll see

• "Multiple MX records with the same priority": fine if they belong to the same provider; that's load balancing.
• "MX records from different providers": usually leftovers from a migration. Pick one.
• "MX host has no reverse DNS": matters for your own outbound server, less for hosted providers.
• "MX server not responding on port 25": the target exists but isn't accepting connections. Common on servers in cloud networks that block port 25.

Why MX errors matter for verification

An MX record is the first thing a verifier checks. No MX, or a broken one, means the verifier can't ask the receiving server whether a mailbox exists, so every address on that domain comes back invalid or unknown. That cuts both ways:

• Your own sending domain. If your MX is broken, replies and bounce notifications are lost, and receivers that check your domain see a domain that can't receive mail. Fix MX before warming or sending.
• The domains on your list. Leads on domains with no working MX will bounce. That's often the cheapest bounce to catch: a domain-level failure takes out every address on it.

Once your DNS is clean, run the prospect list through the verify page. Every address gets a domain and MX check, then a live mailbox check; dead domains are marked invalid, and catch-all domains come back as risky, never guessed valid. For a list sorted by provider, the bulk email provider lookup shows who hosts each domain's mail.

What it costs

• Pro, $39 a month: Unlimited email verification.*
• Starter, $9 a month: 2,500 emails a month.
• Free: the first 100 checks with a Google sign-in, no card.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.

The MX lookup, bulk MX lookup and propagation checker are free and need no sign-up. See pricing.

More reading: cold email domain setup, why cold emails bounce, managing DNS for many cold email domains.