Fix Missing MX Record on Domain (No Inbound Mail)

What's happening

An MX record at the apex (or at a subdomain that receives mail) tells sending MTAs which servers are responsible for accepting mail for that domain. Defined in RFC 5321 and RFC 7505, MX records are looked up by every sending MTA before delivery is attempted.

Without an MX record, sending MTAs fall back to the A or AAAA record at the apex (per RFC 5321 Section 5.1), which usually points to a web server that does not run an SMTP listener. Mail bounces with 550 5.1.2 "could not deliver to host" or times out with 421 4.4.1 "connection refused".

Some domains intentionally do not accept mail and should publish a null MX (mx 0.) per RFC 7505 to explicitly signal this. Most domains, however, are missing MX through misconfiguration rather than intent — and the result is that customers cannot email support@, contact@, or noreply@ addresses.

Why it matters

Inbound mail bounces. Customer support inquiries, delivery confirmations, vendor invoices, and reset-password replies all fail. Sales pipelines lose leads who try to email support and get a bounce.

Calendar invites and meeting confirmations fail because they often go to the apex domain's mailbox. Procurement reviews flag the missing MX as an indicator that the domain is unmanaged.

Sender domains without MX trigger reputation flags at large receivers. Gmail and Microsoft 365 reduce the inbound trust score for domains with no MX, which can affect outbound deliverability indirectly via reputation correlation.

Common causes

• Domain set up at registrar but inbound mail never configured.
• MX record was deleted during DNS migration.
• Mail provider (Google Workspace, Microsoft 365, Fastmail, Zoho) onboarding incomplete.
• Wrong record type published (A or CNAME at @ instead of MX).
• MX target hostname does not exist or has no A record.

Detect this on your site

Run a quick scan with the Email Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Decide whether the domain should accept mail

   If the domain truly does not accept mail (parking domain, marketing-only subdomain), publish a null MX (RFC 7505): example.com. IN MX 0. — and stop. If it should accept mail, proceed.

2. 2

   Identify your inbound mail provider's MX hosts

   Google Workspace uses smtp.google.com (single MX, priority 1). Microsoft 365 uses example-com.mail.protection.outlook.com (priority 0). Fastmail uses in1-smtp.messagingengine.com / in2-smtp.messagingengine.com. Zoho uses mx.zoho.com / mx2.zoho.com / mx3.zoho.com. Your provider's documentation lists the exact hosts.

3. 3

   Publish MX records at the apex

   In Cloudflare DNS, Route 53, Google Domains, or Namecheap, add MX records with name @ (or your bare domain), the provider hostname as target, and the priority the provider specifies. Lower priority = higher preference. TTL 3600 is fine.

4. 4

   Verify with dig MX

   Run dig +short MX example.com. Confirm every record matches the provider's documentation. Run dig +short A for each target hostname to confirm the targets resolve. NXDOMAIN on an MX target is a hard delivery failure.

5. 5

   Send a test message and read the bounce or success

   From a third-party mailbox (Gmail, Outlook), send a message to a known address at your domain. If it delivers, you are done. If it bounces, read the bounce text — "550 5.1.1 user unknown" means MX works but the mailbox does not exist; "421 connection refused" means MX is wrong.

6. 6

   Audit SPF and DMARC for the receiving domain

   Even though you are fixing inbound, make sure SPF and DMARC for outbound are sane. A domain that accepts mail but cannot send authenticated mail will fail many bounces and auto-replies. The two paths are independent but both should work.

Example

; Google Workspace
example.com. 3600 IN MX 1  smtp.google.com.

; Microsoft 365
example.com. 3600 IN MX 0  example-com.mail.protection.outlook.com.

; Null MX (domain explicitly does not accept mail per RFC 7505)
example.com. 3600 IN MX 0  .

MX record variants for major inbound providers and the null-MX RFC 7505 pattern.

Related fixes