Troubleshooting “No MX Records Found”

When external email servers cannot deliver messages to your domain and return bounces like 550 5.1.2: Host unknown, Domain does not exist, or No MX records found, incoming mail transfer agents are unable to locate any Mail Exchange (MX) entries in your public DNS zone. Without valid MX records, the internet has no routing instructions explaining which server accepts mail for your domain, bringing all inbound email to an immediate halt.

Quick Answer

“No MX records found” means public DNS resolvers cannot find any mail routing entries for your domain. This happens when MX records are missing, configured with incorrect hostname syntax, blocked by a conflicting apex CNAME record, or when nameserver delegation at your registrar points to an unconfigured zone.

---

What “No MX Records Found” Means

The Mail Exchange (MX) record is a core DNS resource record that directs incoming email to a specific mail server. When a sender writes to user@example.com:

1. The sending mail server asks public DNS: “What are the MX records for example.com?”
2. DNS should reply with a list of mail hostnames and numerical priorities (such as 1 smtp.google.com).
3. If DNS replies with an empty answer (NODATA) or indicates that the domain cannot be resolved (NXDOMAIN), the sending server has no destination for the email.

While older RFC standards allowed mail servers to fall back to the root A record if no MX record existed, modern email providers (including Gmail, Microsoft 365, and Yahoo) strictly enforce MX lookups. Missing records result in an immediate bounce.

[External Sender] ──► Queries DNS for: example.com (MX)
                                │
          ┌─────────────────────┴─────────────────────┐
          ▼                                           ▼
   [MX Record Found]                           [MX Record Missing]
   smtp.google.com                             Returns NODATA / Empty
          │                                           │
          ▼                                           ▼
Message Delivered to Inbox                     Permanent Bounce:
                                               "550 5.1.2 No MX records found"

---

Common Causes of Missing MX Records

1. Hostname Syntax Errors in DNS

When creating MX records, administrators often misconfigure the Host or Name field:

• Entering the full domain (example.com) into a DNS manager that automatically appends the domain name creates example.com.example.com.
• Entering a subdomain (like mail or www) instead of @ or leaving the field blank means mail sent to the apex domain (user@example.com) has no instructions.

2. Conflicting Apex CNAME Record (RFC 1912 Violation)

RFC 1912 states that if a CNAME record exists at a node, no other record types (such as MX, A, or TXT) can exist at that same node. If you place a CNAME at your root domain (example.com CNAME ghs.googlehosted.com), it can override and suppress your MX records on external recursive resolvers.

3. Nameserver Delegation Disconnect

If you recently registered a domain or switched web hosts, your domain’s active nameservers at your registrar may not match where you are editing DNS records. If the registrar points to ns1.registrar.com but you are adding records inside Cloudflare or AWS, public resolvers will never see your updates.

4. Registrar Suspension (Domain Status Blocks)

If you failed to respond to the annual ICANN registrant email verification, the registrar may place your domain on clientHold or serverHold, which suspends public DNS lookups entirely.

---

Diagnostic Steps

Step 1: Query Authoritative vs. Public DNS

Test whether the records are missing globally or only on public caches:

# Query Google Public DNS
dig example.com MX +short

# Query your domain's authoritative nameserver directly
dig @ns1.yournameserver.com example.com MX +short

• If the authoritative query returns records but Google returns blank: You are dealing with resolver cache delays or a negative caching issue. See How to Fix DNS Propagation Lag for New Domains.
• If both queries return blank: The records do not exist in the active zone. Proceed to Step 2.

Step 2: Check for a Root CNAME Conflict

Check if a CNAME is blocking the apex:

dig example.com CNAME +short

If this query returns a hostname, that CNAME is invalidating your root MX records and must be removed.

Step 3: Check Domain Registration Status

Run a WHOIS lookup to confirm the domain is active:

whois example.com | grep "Domain Status"

Ensure the status reads ok or active. If you see clientHold, log in to your domain registrar and complete any pending email verifications.

---

Step-by-Step Fixes

Fix 1: Add the Correct Google Workspace MX Records

To route email to Google Workspace, publish Google’s unified MX record:

1. Open your DNS provider’s management console.
2. Locate the MX Records section.
3. Remove any old or invalid MX entries.
4. Add the current Google Workspace MX destination:
   • Host/Name: @ (or leave blank depending on provider)
   • Record Type: MX
   • Priority: 1 (or 10)
   • Target/Value: smtp.google.com (note: ensure no trailing space)
   • TTL: 3600 (1 hour) or 300 seconds for rapid testing.

(Note: If your DNS provider does not support the single-record format, use the legacy 5-record configuration: ASPMX.L.GOOGLE.COM priority 1, ALT1... priority 5, etc.)

Fix 2: Remove Conflicting Apex CNAME Records

If you discovered a CNAME record at your root domain (@):

1. Delete the root CNAME record.
2. Replace it with an A record pointing to your web server’s static IP address.
3. Once the CNAME is removed, recursive resolvers will immediately begin returning your MX records.

Fix 3: Audit Live DNS with Automated Tools

To verify that your newly added MX records meet Google’s configuration standards, run a full automated check following the steps in How to Use Google Admin Toolbox “Check MX”.

Once MX routing is active, confirm that your domain’s baseline security records are ready to accept and send messages securely by consulting The Workspace Email Authentication Master Checklist.