Email checks and Domain Intelligence share one credit balance. See how credits work

Start for free

Blog

Can a domain receive email without an MX record?

Missing MX records do not settle whether a domain can receive mail. Follow the DNS answer through implicit routing, null MX and unresolved targets before deciding.

Published

On this page

Yes, sometimes. A domain without an MX record can receive email through SMTP’s implicit routing rule, provided the domain resolves to an address where a mail server accepts mail. A null MX explicitly declares that the domain accepts no email. RFC 5321, section 5.1 defines the fallback; RFC 7505, section 3 defines null MX.

This article concerns receiving internet mail. The DNS answer does not assess sending authentication or reputation. For the general vocabulary, see the MX record definition.

No MX record: follow the domain’s address records

When the MX lookup succeeds but returns no MX records, SMTP treats the domain itself as an implicit mail exchanger with preference 0. The destination comes from its A or AAAA address records. The rule applies only to an empty MX list. RFC 5321 specifies this host selection.

If successful address lookups also return no A or AAAA records, there is no implicit destination to use. A website at a resolved address does not establish that an SMTP server is listening there. DNS gives a possible route; actual acceptance still depends on the receiving service. RFC 7505 describes why address records alone can lead to unsuccessful delivery attempts.

Null MX: the domain explicitly declines mail

Null MX uses a single MX record with preference 0 and . as its exchange target:

nomail.example. 3600 IN MX 0 .

The dot denotes the DNS root label. It does not name a mail server. A domain publishing null MX must not publish other MX records alongside it. Both requirements come from RFC 7505.

If null MX appears beside an ordinary MX, the configuration contradicts itself. Emvero preserves that distinction with DOMAIN_MAIL_ROUTE_MISCONFIGURED; a verification returns unknown for this case, rather than guessing which declaration the owner intended.

An unusable explicit MX does not enable fallback

If MX records exist, a sender must resolve the hosts they name. If none is usable, the sender cannot substitute the domain’s own address records through the implicit rule. This boundary is explicit in RFC 5321, section 5.1.

For example, a working website on the domain does not repair an MX target with no address records. A failed lookup of an MX target also needs diagnosis: it may reflect missing records or a temporary DNS problem. Avoid treating every unresolved target as a permanent mailbox failure.

Keep DNS absence and DNS failure separate

NXDOMAIN means the queried name does not exist. NODATA means the requested record type is absent for that name. An MX query returning NODATA can therefore lead to an address lookup; it does not mean the domain is missing. RFC 2308, section 2 explains these negative answers.

SERVFAIL or a timeout leaves the lookup unsettled. Retry or investigate the resolver before drawing a mail-routing conclusion. SMTP itself requires a sender to defer and retry after a temporary lookup error. RFC 5321 describes that behaviour; the DNS failure meanings explain the corresponding verification distinctions.

Diagnose the answer before changing the address

If you have dig installed, inspect the MX response with:

dig MX example.com

Replace example.com with the domain you are investigating. Keep the response header and answer section visible; short output alone loses details needed to distinguish an empty answer from an error. The ISC dig manual documents the query syntax and output options.

  1. Check the response status first. Investigate NXDOMAIN, SERVFAIL or a timeout before treating the result as an empty MX list.
  2. If the answer contains MX 0 ., check whether it is the only MX record. A single null MX declines mail; mixed records need a configuration review.
  3. If ordinary MX records exist, query A and AAAA for their target hosts. Do not use the domain’s own addresses as an implicit replacement.
  4. If the MX list is empty after successful resolution, query A and AAAA for the domain itself. These are the possible implicit destinations.

These synthetic examples show why the same “missing MX” label can hide different findings. The .example names and documentation IP address are illustrations, not live lookup results.

Synthetic DNS finding Routing conclusion Next step
implicit.example. has no MX but has A 192.0.2.10 An implicit destination exists; the record does not prove an SMTP listener Check the receiving service if actual acceptance matters
nomail.example. IN MX 0 . is the only MX The domain explicitly accepts no mail Correct the domain if it was entered by mistake
broken.example. IN MX 10 mx.broken.example.; the target has neither A nor AAAA after successful lookups No usable explicit destination was found Ask the domain owner to review the MX target
mixed.example. has both null MX and ordinary MX Contradictory configuration Request a DNS configuration review
The domain query returns NXDOMAIN The name does not exist in the DNS answer Check for an incorrect domain
The query returns SERVFAIL or times out Routing remains unresolved Retry or investigate DNS; retain uncertainty

Read Emvero’s domain evidence within its scope

Emvero’s public domain checker evaluates inbound routing without opening an SMTP session. It reports the routing conclusion, not raw MX hostnames or preference values. Use a DNS tool when you need to inspect those records.

When MX records do name a route, identify the visible email provider without confusing a gateway with the mailbox host.

For an address-level integration, the email verification API accepts variant: "domain". Read checks.mail_routing alongside status and reason_codes. IMPLICIT_MX is informational. NULL_MX and DNS_NXDOMAIN support undeliverable; DNS_SERVFAIL, DNS_TIMEOUT and contradictory routing preserve unknown. DNS_NODATA is part of the DNS vocabulary, but a low-level empty MX answer is not itself a guaranteed API reason code or an address verdict.

A domain route does not establish a mailbox

A route for example.com says nothing about whether person@example.com exists. A full check can collect recipient-level evidence where the receiving server permits it; the SMTP handshake explains that exchange. Acceptance can still reflect catch-all behaviour or deferred recipient decisions.

Use the full check and domain check comparison to choose the evidence your decision needs. To inspect inbound routing now, check the domain’s mail routing. The public lookup is free and requires no account.

Choose what to check next.

Run a check from your account and inspect the evidence in its result.