What is MX and how it protects your mail infrastructure

MX records control how the internet delivers email to your domain - and a misconfigured MX can silently break mail delivery or expose your infrastructure to abuse.

Email delivery depends on a simple but critical piece of DNS infrastructure: the MX record. Get it wrong and your mail stops working - often without a clear error message.

What is an MX record?

MX stands for Mail Exchanger. An MX record is a DNS record that tells the internet which servers are responsible for accepting email on behalf of your domain. When someone sends a message to [email protected], their mail server queries DNS for the MX records of example.com, connects to the highest-priority mail exchanger it finds, and delivers the message.

Without MX records, the sending server has no authoritative way to know where to deliver mail. RFC 5321 allows a fallback to the A record of the domain itself, but this is a provisional mechanism - not a substitute for a proper MX configuration.

How MX records work

Each MX record has two parts: a preference number and a mail exchanger hostname. Lower preference numbers mean higher priority. A typical setup looks like this:

example.com.   3600   IN   MX   10   mx1.example.com.
example.com.   3600   IN   MX   20   mx2.example.com.

A sending MTA first tries mx1.example.com (preference 10). If that server is unavailable, it falls back to mx2.example.com (preference 20). This redundancy is intentional - mail delivery must survive transient failures.

There is also a special case defined in RFC 7505: the null MX record (MX 0 .). Publishing a null MX is an explicit declaration that a domain intentionally does not receive email. This prevents mail servers from falling back to the A record and clearly signals to sending MTAs that delivery should be rejected.

Why MX hygiene matters

A misconfigured MX record has direct consequences for mail delivery and security:

Broken delivery. A hostname that does not resolve to a publicly routable IP address means mail cannot be delivered. If all MX hosts fail to resolve, incoming mail bounces or queues indefinitely on the sending side.

Protocol violations that confuse MTAs. RFC 2181 prohibits CNAME records as MX targets. RFC 5321 prohibits IP address literals in MX exchange values. Both violations are technically invalid and can cause unpredictable behavior depending on the receiving MTA's tolerance for non-conformant DNS.

Silent misconfiguration. Duplicate hostnames in MX records and reserved IP addresses that appear to resolve are issues that do not cause immediate delivery failure but degrade trust and increase the chance of mail being marked as spam.

Common mistakes

Using a CNAME as an MX target. Many DNS providers make it tempting to create a CNAME for the mail exchanger hostname, but RFC 2181 explicitly forbids this. The MX exchange value must point directly to a hostname that resolves to A or AAAA records.

Pointing MX to an IP address. The exchange field in an MX record must be a hostname, never an IP address literal. Using MX 10 192.0.2.10 instead of MX 10 mail.example.com is a protocol violation.

Publishing a null MX alongside regular MX records. RFC 7505 §3 is explicit: the null MX must be the only MX record for a domain. Mixing MX 0 . with actual mail exchanger records creates an undefined routing situation.

Resolving to private or reserved addresses. An MX host that resolves to a private IP range (such as 10.0.0.0/8 or 192.168.0.0/16) is not publicly reachable. Sending MTAs on the public internet cannot connect to it, making mail delivery impossible.

How SecRift checks MX

SecRift performs a passive, DNS-only audit of your MX configuration across three dimensions:

MX record presence checks whether the domain publishes at least one MX record with a valid hostname, declares a null MX (RFC 7505), or has no MX records at all. A domain with no MX and no null MX gets a high finding - its reliance on A-record fallback is fragile and discouraged.

MX host validity checks the structural correctness of each MX exchange value. CNAME aliases (RFC 2181 §10.3 violation) and IP address literals (RFC 5321 §5.1 violation) each earn a critical finding. Duplicate hostnames across MX records are flagged separately as medium - they do not break delivery, but they signal a misconfigured zone.

MX host resolvability checks whether each MX hostname resolves to at least one publicly routable IP address. Hosts that resolve exclusively to reserved IP ranges (RFC 1918 private, CGNAT, loopback, link-local, and documentation ranges) are flagged. If no MX host is publicly reachable, the finding is critical - incoming mail cannot be delivered.

SecRift never connects to port 25 or any other SMTP port - the entire scan is passive and DNS-only, so it reads only what you already publish in DNS.

Run a free scan

MX is the foundation your mail transport sits on, so a clean MX record is the natural first step before you harden delivery with SMTP TLS.

Run a free scan on any domain at secrift.com and see your MX posture in seconds.