A live site shows that a web server answered. An MX lookup shows the mail-exchange data DNS published for the domain in the address, if any. RFC 1035 defines an MX record as a 16-bit preference and an exchange hostname. RFC 5321 tells SMTP to use that record when locating a delivery host. The lookup does not prove that a local part exists. SPF, DKIM, and DMARC authenticate the sending side. They do not prove a recipient mailbox exists. No mail server, or a server that cannot be reached, is inconclusive. In MailCheckup, mx_unreachable is free, and it is not invalid.
What a loading website proves
Open a browser, type a name, and get a page. That sequence answers one question: some HTTP service responded for the name you requested. The page can be a store, a parked domain, a CDN error, or a campaign landing page. None of those outcomes speaks SMTP.
People collapse the two because both use a domain name. The name is shared. The service is not. A name can publish address records so a website loads and publish nothing a mail client is allowed to treat as a mailbox host. The reverse is ordinary too. A name can publish mail exchangers and serve no website. Mail does not need a homepage, and a homepage does not need a mail exchanger.
The hostname in the browser is often the wrong name
The address pat@shop.example asks about shop.example. The site people visit is often www.shop.example. Those are different DNS names. A CNAME or address record on www says where the web host is. It does not publish an MX for the domain after the @.
RFC 5321, section 5.1, expects a fully qualified name. Inferring one from a nickname is outside the specification, and an intermediate relay must not do it. The string after @ is the name to query.
A redirect can hide the split. The browser may finish on www after starting at the apex. The mailbox domain is still the part after @. A site can also be deliberate about refusing mail: RFC 7505 lets a domain say so in DNS while the pages keep loading. Until you have read the MX answer, a rendered page stays a web fact.
What an MX record contains
RFC 1035, section 3.3.9, defines MX RDATA as two fields.
Preference is a 16-bit integer. Among MX records at the same owner name, lower values are preferred. Exchange is a domain name. The RFC describes it as a host willing to act as a mail exchange for the owner name.
That is the whole record. There is no local part, no mailbox quota, and no statement that anyone reads the mail. The owner name is the domain you queried. The exchange is another name, and it still has to resolve to an address before SMTP can start.
RFC 1035 says MX records cause type A additional-section processing for the exchange host. RFC 5321, section 5.1, requires that name, when queried, to return at least one address record, "for example, A or AAAA." Section 5.2 allows A, AAAA, or both, and says an IPv6-only client need not try IPv4-only servers. Reachability from your network is not part of the record.
Preference sorts attempts. It does not score the mailbox
When more than one MX exists, the preference must be used in sorting. Lower numbers are more preferred than higher ones. If several destinations share a preference and there is no clear reason to favor one, the sender-SMTP must randomize them to spread load. That rule is in RFC 5321, section 5.1.
Print order is not preference order, and a low number is not a reputation score. Preference 10 before 20 means try 10 first. It does not mean pat exists. The client must be able to try each relevant address in order, should try at least two, and may cap the alternates. Those rules are for a sending SMTP client. MailCheckup does not publish a resolver timeout or an attempt cap, and section 5.1 never defines "usable" with a timer. Do not invent either number.
The exchange has to yield an address, not an alias
When MX data is retrieved, it must contain a domain name, and that name must return at least one address record. RFC 5321, section 5.1, says any other response, specifically including a value that returns a CNAME when queried, lies outside the standard. The same paragraph points to RFC 2181, section 10.3, for the prohibition on labels in the MX data that resolve to CNAMEs.
An alias in the exchange field means the zone is outside RFC 5321. It does not prove a mailbox. A CNAME on the owner name is the other case in the same section: follow it and process the target as the initial name. A CNAME as the MX target is the case the standard puts outside its scope.
How SMTP is required to look a name up
RFC 5321, section 5.1, sets the order. Once the client has identified the domain, a DNS lookup must be performed, citing RFC 1035. The lookup first attempts to locate an MX record. The branches are the part people flatten into "has MX" or "does not."
If a non-existent domain error is returned, that situation must be reported as an error. The name is not in the DNS. That is not a slow server and not a policy record.
If a temporary error is returned, the message must be queued and retried later. Section 5.1 points that duty at section 4.5.4.1. A blip is a reason to wait, not a reason to call the address permanently bad.
If an empty list of MXs is returned, the address is treated as if it were associated with an implicit MX, preference 0, pointing at that host. That sentence is the whole implicit-MX rule. The next section quotes it and fences it in, because it is easy to over-read.
If MX records are present but none of them are usable, or the implicit MX is unusable, the situation must be reported as an error. The RFC does not define "usable" with a timeout or a packet-loss threshold in this paragraph. Keep the word as the standard's word.
If any MX record exists, SMTP must not use the name's own address records. The website address is not a backup exchanger. The implicit-MX section quotes that limit. Unusable MX records must be reported as an error, and the RFC still does not define a timer for "unusable."
A successful lookup can return several addresses, from multiple MX records, a multihomed host, or both. Preference is the first sort. For a multihomed host, the sender must try the addresses in the order the resolver presented. Locating a host is still not accepting a recipient. In MailCheckup, deliverable means the mailbox server accepted the recipient during the check. It does not mean the message will reach the inbox, that a person will read it, or that you have consent to send. The check order puts domain mail capability before recipient acceptance, and a later step is skipped when an earlier one already answered. An MX fact is an earlier step.
Evidence table: verified fact, assumption, recommendation
Use three columns before a delete. The verified fact is what DNS or the cited standard says. The assumption is the leap people make from a website, a printout, or the word valid. The recommendation is the action that stays inside the fact. Read each row across. The sections after this table apply the same columns to implicit MX, null MX, an unreachable host, and sender authentication.
| Verified fact | Assumption people often make | Recommendation |
|---|---|---|
| A successful HTTP response shows that a web server answered for the name the browser requested. | The domain has email because the website loads. | Keep the web result in a web column. Query mail DNS for the domain after @ before you treat the domain as able to receive mail. |
| RFC 1035, section 3.3.9, defines an MX as a 16-bit preference, lower preferred, plus an exchange domain name. | An MX record proves a specific mailbox exists. | Store the exchange names and preferences as routing data. Ask the mailbox question later. |
| RFC 5321, section 5.1: look up MX first. A CNAME at the owner name is followed. A non-existent domain must be reported as an error. A temporary DNS error means the message must be queued and retried. | Any DNS failure means the address is permanently bad. | Keep non-existent domain, temporary failure, and a positive no-mail record in different buckets. |
| If the MX list is empty, RFC 5321 treats the name as an implicit MX with preference 0 pointing at that host. | No MX record always means the domain rejects mail. | On an empty MX list, look for a null MX and for address records. Absence of MX is not the null-MX signal. |
| If one or more MX records exist, SMTP must not use the name's address records except through those MX targets. Implicit MX applies only when no MX records are present. | If the MX host is down, mail falls back to the website address. | Do not route mail to the apex address while any MX exists. |
| The exchange must return at least one A or AAAA. A target that returns a CNAME is outside RFC 5321, which points to RFC 2181, section 10.3. | Any hostname in the MX field is a working mail server. | Resolve the exchange. If the target is an alias, record a non-standard zone. Do not invent a mailbox verdict from it. |
| Lower preference numbers are more preferred. Equal preferences must be randomized by the sender-SMTP when nothing else distinguishes the hosts. | The first line a lookup tool prints is the only server that matters. | Sort by preference and keep the full set. Print order is not preference order. |
A null MX, RFC 7505, is a single MX with preference 0 and exchange .. No other MX may be published. The record says the domain does not accept email. | A null MX and a failed lookup are the same outage. | Treat a published null MX as the domain's no-mail statement. Treat a timeout or an unreachable host as an incomplete observation. |
| RFC 7505 describes domains with no MX: senders try A or AAAA, and if nothing answers SMTP, attempts can continue for a long period, which the RFC calls typically a week. | One failed connection proves the mailbox is dead. | Do not turn one unreachable attempt into a permanent invalid. Queue, retry, or leave the check inconclusive. |
MailCheckup: no mail server, or a server that cannot be reached, is not a confident invalid person. Unreachable servers are inconclusive. Mail server unreachable is free. The code is mx_unreachable. | Unreachable means delete the row as invalid. | Keep mx_unreachable with the inconclusive group. It is free. It is not invalid. Do not suppress the person on that code alone. |
| SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) authenticate mail that claims a domain. Gmail's sender guidelines require SPF or DKIM for mail to personal Gmail accounts, and SPF, DKIM, and DMARC above 5,000 messages a day to those accounts. | A passing SPF, DKIM, or DMARC setup proves recipient mailboxes exist. | Use those records for mail you send. Use a recipient check when the question is whether a mailbox exists. |
| In MailCheckup, deliverable means the mailbox server accepted the recipient during the check. It does not mean inbox placement. | A published MX plus deliverable means the person will read the mail. | Keep inbox placement, consent, and identity separate from the MX fact and from acceptance. |
Implicit MX, stated the way RFC 5321 states it
Implicit MX is one rule in RFC 5321, section 5.1, and the limit in the next paragraph.
> If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
> If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present.
RFC 7505 summarizes this as a lookup of MX and, if none is found, a fall back to A or AAAA. That is a summary. The empty-list condition, and the ban on using address records when any MX exists, are section 5.1.
An empty list means no MX records came back. Verified fact: that is the implicit-MX row, not the null-MX row, and not a non-existent domain. A non-existent domain must be reported as an error. A temporary DNS error must be queued and retried. A null MX is a record that is present, so implicit MX does not apply. The implicit record is client behavior. A published MX at preference 0 pointing at the same name is ordinary MX data. Assumption people often make: "no MX" always means the domain refused mail. Recommendation: name which answer you hold before you choose a label.
This zone is a shape, not a live lookup.
shop.example. A 192.0.2.10
www.shop.example. A 192.0.2.10There is no MX line. Verified fact: an empty MX list means treat shop.example as an implicit MX, preference 0, at that host. Assumption people often make: the website loads, so pat@shop.example is a mailbox. Recommendation: record the implicit-MX condition, then record what you still lack. Nothing here shows an SMTP listener, a real local part, or a later accept, reject, or timeout.
RFC 7505 says that when no SMTP listener sits on the A or AAAA address, senders keep trying for a long period, which the RFC calls typically a week. That figure is the RFC's description of ordinary sending software. It is not a MailCheckup timer. If the implicit host is unusable, RFC 5321 says report a delivery error, which means do not claim the message was delivered. It does not name a fake person. The results guide uses mx_unreachable when a mail server could not be reached. It does not say every empty MX list is stored under that code. The code is free.
Null MX, stated the way RFC 7505 states it
RFC 7505, section 3, says a domain that does not accept email advertises a single MX with preference 0 and a zero-length label, written as .. The dot is not a valid host name, so it cannot be confused with an ordinary exchanger. The domain must not publish any other MX. This shape is not a live query:
shop.example. MX 0 .
shop.example. A 192.0.2.10The site can still load. Verified fact: an MX is present, the domain says it does not accept email, and implicit MX must not be applied. Assumption people often make: the dot means "try the website address." Recommendation: do not. RFC 5321 already forbids using the name's address records when any MX exists.
RFC 7505 says the record will cause delivery attempts to fail immediately, unlike the no-MX case, where senders fall through to A or AAAA and may retry for a long time. When a server rejects an envelope recipient because of a null MX, the RFC says it should use reply code 556 and enhanced status 5.1.10. The IANA text in that RFC describes 5.1.10 as the code returned when the address is marked as invalid using a null MX. That description belongs to the SMTP status. It is not a MailCheckup result. The results guide has no row named null MX.
If you saw 0 . in DNS, you have RFC 7505's statement. If the export says mx_unreachable, you have a free, inconclusive result for a server that could not be reached. Do not swap those labels. RFC 7505 also says not to publish a null MX on a domain you use as the envelope sender or header From, and that null MX is not the null reverse-path in RFC 5321. SPF -all, which it cites from RFC 7208, is a sending declaration, not a recipient list.
Unreachable is not the same error as a missing domain
Keep the DNS-failure row honest in the order you will actually see the answers.
A non-existent domain must be reported as an error. You learned the name is missing. You did not learn a local part, and you should not file that under mx_unreachable. A temporary DNS error must be queued and retried. One blip is not a permanent fact about the person. The difference between unknown and invalid is the list form of that rule, and what a verification check covers already separates a temporary DNS failure from a stable configuration problem.
MX present but none usable, or an implicit MX that is unusable, must be reported as a delivery error: do not claim the message was delivered. MailCheckup's published rule is the list rule. No mail server, or a server that cannot be reached, is not a confident invalid person. Mail server unreachable is free. A null MX is neither of those failures. It is a policy record.
The results guide does not publish a timeout, a resolver address, or how many targets are tried. Do not invent them. Unknown, retry later, greylisted, mail server unreachable, provider blocked, and system error are free. mx_unreachable is in that group. Invalid, undeliverable, and dead are not. Provider blocked and system error are not MX facts. Unknown or mailbox full can be rechecked without redoing rows that already have a result. A new finished check can cost a credit. No published timer says every unreachable row must be retried.
One more shape, not a capture:
shop.example. MX 10 mail.shop.example.
mail.shop.example. A 192.0.2.20
shop.example. A 192.0.2.10Verified fact: preference 10 names mail.shop.example, which has an address, so the apex address is not a mail fallback. Assumption people often make: a silent exchanger plus a live website means the mailbox is invalid. Recommendation: keep an unreachable exchanger inconclusive. In MailCheckup that result is mx_unreachable, free, not invalid. Preference 20 would be tried after 10. Equal preferences are randomized when the sender has no better reason to choose. You do not know MailCheckup's attempt limit from the public docs.
SPF, DKIM, and DMARC are about the sender
SPF, DKIM, and DMARC authenticate the sending side. They do not prove a recipient mailbox exists.
RFC 7208 lets a domain authorize hosts that use its name in MAIL FROM or HELO. A pass says the connecting host was allowed to use that domain. It does not say a recipient local part exists. RFC 6376 lets the signing domain claim responsibility for a message, checked with a signature and a public key in DNS. A domain can sign outbound mail and refuse inbound mail. RFC 7489 publishes receiver policy for messages that use the domain, and it says DMARC does not produce elevated delivery privilege for authenticated email.
Gmail's sender guidelines, retrieved 6 October 2026, cover mail to personal Gmail accounts ending in @gmail.com or @googlemail.com. Senders need SPF or DKIM. Senders of more than 5,000 messages a day to Gmail accounts need SPF, DKIM, and DMARC. Those rules are about mail you send to Gmail.
Verified fact: the records judge mail that claims the domain. Assumption people often make: "domains with SPF" means the recipients are real. Recommendation: use SPF, DKIM, and DMARC for the sending question. Use a recipient check, not those records, when the question is whether pat exists. An MX hostname is only the routing step.
What to do with the result in a list
On MailCheckup's check order, broken syntax is invalid, and a typo suggestion does not rewrite the submitted address. Disposable domains and role addresses such as info@ are classifications, not bad syntax. Domain mail capability comes next. No mail server, or a server that cannot be reached, is not a confident invalid person. Recipient acceptance can be deliverable, undeliverable, catch-all, or mailbox full. Greylist, a block, a timeout, or no clear answer is unknown, and unknown is free. If you only ran DNS, say so.
Then apply the three columns and stop where the fact stops. A homepage without an MX query is the HTTP row: run the mail lookup. Ordinary MX records are the routing row: sort by preference, then ask the mailbox question if you need it. An empty MX list is the implicit-MX row. A lone 0 . is the null-MX row. Do not merge them, and do not call a product code "null MX" unless the product said that. mx_unreachable is the free inconclusive row: leave it out of the invalid set. SPF, DKIM, and DMARC are the sender row. Deliverable is acceptance during the check, not consent, and it does not erase an unsubscribe.
Do not automate "HTTP 200, therefore mailable," "no MX, therefore invalid," or "mx_unreachable, therefore delete." The results guide is the legend when you are holding an export. The table above is the legend when you are holding a DNS answer.
Key takeaways
- A loading website proves a web server answered. It does not prove the domain after
@accepts mail. - An MX record is a preference and an exchange hostname. Lower preference is tried first. It does not name a mailbox.
- Implicit MX applies only to an empty MX list. It does not apply when any MX exists, including a null MX.
- A null MX is preference 0 and exchange
., alone. It says the domain does not accept email. It is not a timeout. - Non-existent domain, temporary DNS error, unusable exchanger, and null MX are different outcomes. A delivery error means do not claim the message was delivered.
- No mail server, or a server that cannot be reached, is inconclusive in MailCheckup.
mx_unreachableis free and is not invalid. No resolver timeout is published. - SPF, DKIM, and DMARC authenticate the sending side. They do not prove a recipient mailbox exists.
- Deliverable means acceptance during the check. It is not inbox placement, identity, or consent.
Questions worth answering from the lookup
Does a live website mean the domain has email?
No. The site can be on www while the mailbox domain is the apex, or the domain can publish a null MX and still serve pages. With no MX, implicit MX names the host itself, which may not speak SMTP. Query the domain after @.
What does an MX lookup prove?
It proves the MX data returned for that name: preferences and exchanges, a DNS error, or a null MX if that record is what you received. It does not prove a local part, inbox placement, or consent.
What is implicit MX?
It is RFC 5321's rule for an empty MX list: act as if preference 0 pointed at that host. It applies only when no MX records are present. It is not a null MX and not a line already written in the zone.
What is a null MX?
It is RFC 7505's single MX at preference 0 with exchange .. The domain says it does not accept email. The website address is not a substitute, because an MX is present. MailCheckup's public results guide does not name a separate null-MX code.
Why is an unreachable mail server not invalid?
The check did not show the mailbox was absent. RFC 5321 tells a sender to report an unusable exchanger as a delivery error and to retry a temporary DNS failure. MailCheckup's rule for the list is that no mail server, or one that cannot be reached, is not a confident invalid person. mx_unreachable is free, not invalid.
Do SPF, DKIM, or DMARC prove the recipient exists?
No. They authenticate the sending side. They do not prove a recipient mailbox exists.
A practical next step
If the open question is the mailbox, not the homepage, check addresses you already have. Read unreachable and unknown as inconclusive. Read deliverable as acceptance during the check, not as inbox placement.
Verify a sample list with MailCheckup
Sources
Retrieved 6 October 2026.
- RFC 1035, Domain names — implementation and specification, section 3.3.9, MX RDATA. https://www.rfc-editor.org/rfc/rfc1035
- RFC 5321, Simple Mail Transfer Protocol, sections 5.1 and 5.2. https://www.rfc-editor.org/rfc/rfc5321
- RFC 7505, A "Null MX" No Service Resource Record for Domains That Accept No Mail. https://www.rfc-editor.org/rfc/rfc7505
- RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. https://www.rfc-editor.org/rfc/rfc7208
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures. https://www.rfc-editor.org/rfc/rfc6376
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489
- Gmail, Email sender guidelines. Claims used: requirements for sending to personal Gmail accounts; SPF or DKIM for senders; SPF, DKIM, and DMARC above 5,000 messages a day. https://support.google.com/mail/answer/81126
- MailCheckup public pages: https://mailcheckup.net/how-it-works , https://mailcheckup.net/results-guide , https://mailcheckup.net/resources/unknown-vs-invalid-email , https://mailcheckup.net/resources/what-email-verification-checks
