MX Record Check

This check always passes, regardless of what your MX records say. It exists to surface what is published, not to gate your score: a domain that legitimately does not receive mail is just as valid as one that does. The deeper MX analysis (hostname hygiene, MX-pointing-at-CNAME violations, null-MX detection, multi-host failover) lives in the Email Security category. Treat this fix page as a chance to audit your MX setup intentionally, not because something failed.

Three situations to check

You have MX records (the common case)

The evidence shows your published MX records. Audit them:

• Confirm the hostnames are correct and current. After a mail provider migration, old MX records often linger.
• Confirm you are not pointing at a parked, decommissioned, or abandoned host. dig MX yourdomain shows priorities and hostnames; check each one resolves to a working mail server.
• Confirm priorities (the number before each hostname) reflect your intended failover order. Lower priority is preferred first.
• If you use multiple providers (a primary mailbox provider plus a transactional sender, for example), verify both are listed at the right priorities and that your transactional sender is configured to send from the right subdomain.

You receive mail but no MX records were returned

This is the urgent case. With no MX records, sending mail servers fall back to your domain's A or AAAA records and try SMTP on port 25 there (RFC 5321 implicit MX fallback). If your A record points at a web server with no mail listener, mail bounces. If it points at a SaaS host, mail leaks somewhere unexpected. Publish MX records pointing at your actual mail provider.

yourdomain.tld.   IN  MX  1   aspmx.l.google.com.
yourdomain.tld.   IN  MX  5   alt1.aspmx.l.google.com.
yourdomain.tld.   IN  MX  5   alt2.aspmx.l.google.com.
yourdomain.tld.   IN  MX  10  alt3.aspmx.l.google.com.
yourdomain.tld.   IN  MX  10  alt4.aspmx.l.google.com.

Use the exact records your provider documents (Microsoft 365, Fastmail, ProtonMail, Zoho, your own MTA, etc.). Wait one MX-record TTL after publishing, then send a test message to verify routing.

You do not receive mail. Publish a null MX

If your domain is web-only (marketing site, app domain, internal service domain), publish a null MX as defined in RFC 7505. It tells sending servers "this domain does not receive mail," prevents implicit fallback to your A record, and produces an immediate bounce instead of mystery delivery to your web host:

yourdomain.tld.   IN  MX  0   .

The hostname is a single dot (the DNS root, treated as "no host"). Most managed DNS UIs accept this as priority 0, target dot. If your provider's UI rejects it, switch to zone-file mode and add the record manually.

Verify the fix

• Run dig +short MX yourdomain @1.1.1.1 to see what is published.
• If you receive mail, send a test message to your usual mailbox at this domain and confirm it arrives within the expected window.
• If you published a null MX, attempt a test send and confirm it bounces with an explicit refusal (sending MTAs that respect RFC 7505 will refuse to even try).
• Re-run the RedScore lookup to refresh the evidence.

Common pitfalls

• MX pointing at a CNAME. RFC 5321 says MX targets must be A or AAAA, not CNAME. Some mail servers tolerate it, others refuse. Always point MX at a hostname with direct A/AAAA records.
• Abandoned MX from a previous provider. After leaving a mail vendor, the old MX often stays. New mail might still attempt the dead provider first. Remove old MX entries during migration.
• Typos in the MX hostname. mial.example.com instead of mail.example.com breaks delivery silently and can be hard to spot in a long zone file.
• Wildcard MX. A *.yourdomain.tld MX makes every typo'd subdomain a mail destination. Set MX explicitly per zone, not via wildcard.
• Null MX with the wrong target. The target must be a single dot (root). Some DNS UIs interpret a bare . as the current zone; always verify with dig MX yourdomain after saving.

For deeper MX analysis (host hygiene, MX-CNAME violations, missing null MX when no inbound mail is configured, multi-host failover), see the Email Security category in your scan.