mx.ip_literal
MX Record Points to IP Address
What we check
We inspect each MX target to determine whether it is a hostname or an IP address literal (e.g., [192.0.2.1]). RFC 5321 §5.1 requires MX targets to be domain names, not IP addresses.
What this finding means
At least one MX record points to an IP address literal instead of a hostname. While some sending servers will attempt delivery to the literal address, this violates the MX specification and breaks features that depend on hostname-based verification: TLS certificate matching, MTA-STS policy enforcement, and DANE/TLSA lookups all require a hostname.
Why it matters
- RFC violation. MX RDATA must be a hostname (RFC 5321 §5.1). An IP literal is technically invalid and may be rejected by strict implementations.
- No TLS verification possible. TLS certificates are issued to hostnames; an IP literal cannot be matched against a certificate's subject or SAN field in the standard SMTP STARTTLS flow.
- No DANE or MTA-STS. Both mechanisms are keyed on hostnames — they cannot protect connections to IP literals.
- No PTR/FCrDNS context. Reverse-DNS checks against MX targets are meaningless when the target is already a bare IP.
How to fix
Replace the IP literal with a hostname that resolves to the same address:
; Before (wrong) example.com. IN MX 10 [192.0.2.1] ; After (correct) example.com. IN MX 10 mail.example.com.Ensure the hostname has A/AAAA records pointing to the mail server:
dig +short A mail.example.com # Expected: 192.0.2.1
How it's graded
An MX target that is an IP literal carries a 20-point deduction in the MX category. See Grading Methodology for the full scoring model.
Evidence example
$ dig +short MX example.com
10 [192.0.2.1]
MX target is an IP address literal, not a hostname