Skip to main content
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.

Deliverability

Email from customers, partners and password-reset flows only arrives when MX records point at a mail server.

Standards

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 (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.

​
Output documentation

​
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.