> ## Documentation Index
> Fetch the complete documentation index at: https://docs.37audits.com/llms.txt
> Use this file to discover all available pages before exploring further.
# DNS Mail MX
> Checks that the domain publishes MX records so other servers know where to deliver its email.
**Security Auditor** — checks that the domain of the audited URL publishes MX records, so sending mail servers know where to deliver email addressed to it.
Email from customers, partners and password-reset flows only arrives when MX records point at a mail server.
Follows RFC 5321 Simple Mail Transfer Protocol §5.1 and recognises the RFC 7505 null MX.
When a mail server has a message for `someone@example.com`, it asks DNS for the MX records of `example.com` and connects to the host with the lowest preference value. A domain without MX records leaves the sender to guess (RFC 5321 falls back to the domain's own address record), and a domain whose only MX record is the null MX `0 .` tells every sender that it accepts no email at all. This auditor queries the MX records of the domain of the audited URL. It never fetches the page.
## How it works
1. **Domain** — takes the hostname of the audited URL and strips one leading `www.`, so `https://www.example.com/contact` is audited as `example.com`. An empty or malformed URL, or one without a hostname, ends the audit with `501`.
2. **Lookup** — queries the MX records of that domain through the system resolvers, with no cache. A resolver failure (SERVFAIL, timeout) ends the audit with `500`: it is not a missing record. NXDOMAIN and NODATA count as "no MX records".
3. **Rules** — no MX record at all fails (`400`); a domain whose MX records all point at the root (`0 .`, the RFC 7505 null MX) warns (`300`).
4. **Aggregate** — FAIL wins over WARNING; when at least one MX record points at a real host the audit is `SUCCESS` (`200`) and the message lists the hosts sorted by preference.
5. **Specification pin** — every run emits `37A-DnsMailMxAuditor-100` (`INFORMATION`), naming [RFC 5321 Simple Mail Transfer Protocol §5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1) (October 2008). It does not change the overall status.
## What it audits
Every row maps to one `checkRule*` method and one `CheckCode`, in the order the auditor runs them. CheckCode suffixes use status ranges: `100` information, `200` success, `300–399` warning, `400–499` fail, `500–599` error.
| CheckCode | Status | When it fires | Recommendation | Why it matters |
| - | - | - | - | - |
| `37A-DnsMailMxAuditor-100` | `INFORMATION` | Always. Records the specification this auditor implements. | — (recommendation is `null`; nothing for the site to change) | — |
| `37A-DnsMailMxAuditor-400` | `FAIL` | The domain publishes no MX record at all (NXDOMAIN, NODATA or an empty answer). | Publish at least one MX record for `{domain}` pointing at the server that accepts its email, for example "`{domain}`. MX 10 mail.`{domain}`.". | Without MX records, sending servers fall back to the domain's web address, so email from customers and partners bounces or is lost unless the web server also runs mail. |
| `37A-DnsMailMxAuditor-300` | `WARNING` | Every MX record of the domain is the RFC 7505 null MX (`0 .`), which declares that the domain accepts no email. | If `{domain}` should receive email, replace the null MX record "`{records}`" with MX records pointing at its mail servers; if it is meant to never receive email, no change is needed. | A null MX tells every sending server to reject mail for the domain on the spot, so a domain that is expected to receive email loses every message addressed to it. |
| `37A-DnsMailMxAuditor-200` | `SUCCESS` | At least one MX record points at a real host. Message lists the hosts sorted by preference: "`{domain}` publishes `{count}` MX records: `{host}` (priority `{priority}`), …". | — | — |
| `37A-DnsMailMxAuditor-500` | `ERROR` | The resolver could not answer the MX query (SERVFAIL, timeout, network error). | Make sure the name servers of `{domain}` answer MX queries, then run the audit again. Last error: `{error}`. | — |
| `37A-DnsMailMxAuditor-501` | `ERROR` | The audited URL is empty, malformed or has no hostname to query. | Provide a URL with a scheme and a hostname, for example [https://example.com/](https://example.com/); received "`{url}`". | — |
## Output documentation
| Status | Description | Test logic |
| - | - | - |
| **SUCCESS** | The domain publishes MX records | At least one MX record points at a real host (`200`); the check data lists `domain`, `mxRecords` (`priority`, `target`, sorted by preference), `mxCount` and `mxHosts`. |
| **WARNING** | The domain declares it accepts no email | Every MX record is the null MX `0 .` (`300`). |
| **FAIL** | The domain has no MX records | The MX query answered NXDOMAIN, NODATA or no records (`400`). |
| **ERROR** | The auditor could not run the check | Resolver failure (`500`); empty, malformed or host-less URL (`501`). |
| **INFORMATION** | Specification pin | Always emitted (`100`); does not change overall status. |
## Risks and considerations
### Why MX records matter
* Contact forms, order confirmations, password resets and replies from customers all depend on senders finding the domain's mail server. A domain without MX records receives whatever the fallback to its address record happens to deliver, which is usually nothing.
* A null MX (`0 .`) is a deliberate, valid statement that the domain never receives email (RFC 7505). It is right for a domain used only for a website or for sending, and wrong for one that has mailboxes, so this auditor warns rather than fails.
### What is audited
* The domain is the hostname of the audited URL minus one leading `www.`. A page on `shop.example.com` is audited as `shop.example.com`, whose MX records may legitimately differ from `example.com`.
* The auditor queries DNS only. It does not connect to the listed mail servers, check that they resolve, or test SPF, DKIM or DMARC (see the other DNS Mail auditors).
* A domain that mixes a null MX with real hosts violates RFC 7505; the auditor reports the real hosts as a success and leaves the null MX in the check data.
### Changes from the previous version
* A null MX (`0 .`) used to be reported as `SUCCESS` with an empty host; it is now a `WARNING` (`300`).
* An empty, malformed or host-less URL used to be a `FAIL`; it is now an `ERROR` (`501`), because nothing about the domain was observed.
* A resolver failure (SERVFAIL, timeout) used to be reported as "no MX records" (`FAIL`); it is now an `ERROR` (`500`), so a transient DNS problem no longer looks like a missing record.
* Unexpected exceptions used to be caught and returned as `FAIL`; the core now reports them as `ERROR`.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.