MX infrastructure: configure and check MX records correctly

What an MX record controls, and what it does not

To deliver a message to name@example.com, the sending mail server queries DNS for the MX records of example.com. Each MX record contains a preference number and the name of a receiving server, known as the exchange. The sender orders the targets by preference and establishes an SMTP connection to one of them. RFC 5321, section 5.1

The MX record concerns reception only. SPF describes which servers may send messages using your domain; DKIM concerns message signing; DMARC describes how recipients should handle unauthenticated messages. None requires your own receiving MX. Only the optional SPF mx mechanism refers to MX targets: it counts towards the limit of ten SPF terms that trigger DNS lookups, each MX name may trigger at most ten address lookups, and this mechanism has no implicit MX if an MX record is absent. RFC 7208, sections 4.6.4 and 5.4 Mail client settings for IMAP, POP3 or submission are also a separate task; these use SRV records under RFC 6186 or providers' configuration services.

Sources: RFC 5321, section 5.1; RFC 7505, sections 1 and 3.

Structure of an MX record

; Example zone with documentation names and addresses, not a real configuration
example.com.        3600  IN  MX    10 mx1.example.com.
example.com.        3600  IN  MX    20 mx2.example.com.
mx1.example.com.    3600  IN  A     203.0.113.10
mx1.example.com.    3600  IN  AAAA  2001:db8::10
mx2.example.com.    3600  IN  A     203.0.113.20

The first name identifies the domain for which mail is received. 3600 is the cache lifetime (TTL) in seconds, 10 and 20 are preferences, and the final value is the target. Preference is a number from 0 to 65535; lower values are preferred. RFC 1035, section 3.3.9 In zone files, fully qualified names end with a dot; DNS providers' management interfaces often present the same fields differently.

The target must be a hostname with its own address records. An IP address is not an MX target, and an alias (CNAME) must not be used there. RFC 2181, section 10.3 RFC 5321 explicitly places an answer leading to an alias outside the standard. Whether individual senders follow an alias anyway is therefore not a reliable basis. The example includes the AAAA line only because mx1 is assumed to accept mail over IPv6 as well; see IPv4, IPv6 and reverse DNS.

Preference, failure and queues: what the sending server decides

Preference determines order only. A sender must sort MX records accordingly and try the lowest number first. If several targets have equal preference and there is no clear reason to favour one, the sender must randomise the order to distribute load. This does not promise an even split; that depends on the number and behaviour of senders. If a target name returns several addresses, the sender tries them in the order supplied by its resolver. RFC 5321, section 5.1

For a single delivery attempt, RFC 5321 requires the sender to be capable of trying relevant addresses in turn until delivery succeeds. It may limit the number of alternatives and should try at least two addresses. Postfix, for example, defaults to a limit of five MX addresses and two completed SMTP sessions per delivery request (smtp_mx_address_limit, smtp_mx_session_limit). A third target is therefore not always reached in the same run. Postfix: configuration parameters

Sources: RFC 5321, sections 4.2.1, 4.5.4.1 and 5.1.

Retries and give-up time are controlled by the sender

RFC 5321 requires a sender to queue temporarily undeliverable messages and retry them periodically. After a failure, it must wait before the next attempt; the interval should generally be at least 30 minutes. The give-up time is described as “generally … at least 4-5 days”: a general guideline without a mandatory keyword. The retry algorithm's parameters, however, must be configurable. RFC 5321, section 4.5.4.1

Defaults vary accordingly: Postfix gives up after five days by default (maximal_queue_lifetime), while Exim's default configuration uses four days from the first failure. Other senders may use shorter or longer periods. RFC 7505 describes retries for targets without an SMTP service as lasting “typically a week”. Postfix, Exim default configuration, RFC 7505, section 1

Backup MX: when it helps and what it requires

Sending servers' queues can bridge short interruptions even with just one MX. This requires the sender to retain the message and reception to resume before its give-up time. A backup MX with a higher preference number instead accepts messages during an outage and relays them later. This may help with longer maintenance windows or when you want messages queued under your own control.

A published MX record is visible to everyone, however, and preference is only a rule for senders. Anyone establishing an SMTP connection can contact any published target directly, including the backup MX while the main server is reachable. This creates three requirements:

1. Same recipient validation: The backup MX must know which addresses exist and reject unknown recipients during the SMTP dialogue. Once it has accepted the complete message with the final 250 response after DATA, it is responsible for delivery or an error notification; if later forwarding fails, it generally has to send a non-delivery notification to the reverse path, which may be forged in spam. An empty reverse path must not generate another error notification. RFC 5321, section 6.1 Postfix therefore provides a valid-recipient list for a backup MX (relay_recipient_maps), preventing the queue from filling with undeliverable notifications. Postfix: backup MX
2. Same filtering: Spam and malware checks that run only on the main system can be bypassed through the backup MX.
3. Gateway in front of the mailbox system: If a Secure Email Gateway or filtering service sits in front of your mailbox system, all MX records belong to the gateway, and the system behind it should accept connections only from the gateway. ARC and Secure Email Gateways explains how gateways, forwarding and authentication results interact.

For hosted services, use exactly the MX set documented by the provider. Add your own backup MX there only if the provider explicitly makes provision for it; otherwise messages bypass its recipient checks and filtering and reach a system the service does not know. Use the documented values for your actual receiving service.

The Email Security Check does not measure backup MX targets or examine firewall, filtering or recipient rules. MX names matching a known gateway or provider pattern say nothing about whether a backup is protected against direct access.

Null MX: declare that a domain accepts no email

A null MX is a single MX record with preference 0 and the target ., an empty name. It declares that no email is accepted at that name. No other MX record may coexist with a null MX. RFC 7505, section 3

; Name that should never receive email (example)
static.example.com.   3600  IN  MX  0 .

Sending systems can then recognise on the first attempt that delivery is impossible; queuing and retries are unnecessary. Misaddressed messages fail immediately instead of hours or days later, and feedback to forged sender addresses in that domain can be discarded quickly. RFC 7505, section 4.1

Both codes are recommendations (SHOULD); the message wording is unrestricted. If a sending server has already accepted the message, it reports failure to the sender through a non-delivery notification. RFC 7505, section 4.1, RFC 7504, section 4

C: RCPT TO:<info@static.example.com>
S: 556 5.1.10 Recipient address has null MX

Do not publish null MX for domains used as a reverse path or visible sender domain: recipients may reject those messages; RFC 7505 explicitly recommends this. RFC 7505, section 4.2 For domains that neither send nor receive, an SPF policy of v=spf1 -all adds the declaration about sending; a DMARC policy is another separate measure. Null MX neither prevents use of your domain in forged sender details nor blocks sending.

Candidates include names that should never receive email, such as hosts used only for web, assets or tracking. First check that they are not used as sender or reverse-path domains and that nobody expects messages there. A null MX applies only to the name where it is published; each additional subdomain needs its own decision.

The Email Security Check recognises a valid null MX at the entered name and reports contradictory combinations. It does not examine other subdomains. If the name has null MX and no regular SPF record, the check assesses it using a separate profile for non-sending domains covering SPF -all, DMARC policy and null MX. It does not verify that nobody actually sends with the domain.

IPv4, IPv6 and reverse DNS: receiving and sending requirements

An MX target may have A records (IPv4), AAAA records (IPv6) or both; RFC 5321 prescribes no particular combination. RFC 5321, section 5.2 Publish an address family only if the server actually accepts email over it. Otherwise, unsuccessful connection attempts may occur before a sender tries another address or defers the message. An AAAA record does not prove working IPv6 reception; its absence does not prove a defect in reception deliberately operated over IPv4.

Reverse DNS (PTR) associates an IP address with a name. SMTP requires no PTR for servers used only for reception. Sending is different: Google requires all senders to personal Gmail accounts to have valid forward and reverse records for their sending IP addresses; the PTR name must resolve back to the sending address through A (IPv4) or AAAA (IPv6). Yahoo also requires valid forward and reverse records for sending IPs. Google: email sender guidelines, Yahoo: Sender Best Practices Sending over IPv6 therefore requires a matching IPv6 PTR. This creates no obligation to send or receive over IPv6.

Many self-operated servers both receive and send. In that case, sending-address requirements also apply to the host listed as an MX. Separately, RFC 1912, section 2.1 (Informational), recommends maintaining a PTR matching the A record for each IP address. The address-range owner sets the PTR, usually your hosting or network provider through its management interface, not your own domain zone.

; Forward resolution in your zone (documentation addresses)
mx1.example.com.   3600  IN  A     203.0.113.10
mx1.example.com.   3600  IN  AAAA  2001:db8::10

; Reverse resolution, maintained by the address-range owner
10.113.0.203.in-addr.arpa.  IN  PTR  mx1.example.com.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  mx1.example.com.

Forward-confirmed reverse DNS (FCrDNS) is checked as follows: address → PTR name → A or AAAA record for that name → the same address again.

The Email Security Check tests PTR and forward resolution only for the first IPv4 address of the first MX. It does not check IPv6 reverse DNS, additional addresses, other MX hosts or the servers actually sending. Additional points for a matching PTR at the MX are a product weighting, not a standards requirement for receiving servers.

DNSSEC for MX answers: what the signature protects

Without DNSSEC, an attacker capable of forging DNS answers or poisoning a resolver cache may supply false MX targets to a sender. If your zone is signed and the sender's resolver checks signatures, it detects forged or altered answers and does not return them. Protection therefore requires both a signed zone and a validating resolver on the sender's side.

DNSSEC does not encrypt messages, protect against changes through a compromised account at the DNS provider or registrar, or prove delivery. Nor does it automatically secure MX target zones: if mx1.example.net is in another, unsigned zone, its address answers are unprotected.

# Example query, not executed here
dig +dnssec example.com MX

An ad flag in the response means the queried resolver considers the answer authentic. RFC 4035, section 3.2.3 This is meaningful only if you trust that resolver and the path to it. A missing flag may mean the zone is unsigned, the resolver does not validate or the chain of trust is broken. If a signed answer fails validation, a validating resolver returns SERVFAIL. RFC 4035, section 5.5

DANE for SMTP builds on DNSSEC: it publishes TLSA records for MX hosts and requires DNSSEC-validated MX and TLSA answers. MTA-STS works without DNSSEC through an HTTPS policy. Details: DNS security: DANE and TLSA, SMTP TLS and MTA-STS.

For email service providers wishing to demonstrate conformity with it, BSI Technical Guideline TR-03108 (version 2.0) requires, among other things, a DNSSEC-validating resolver, DNSSEC signing of receiving-domain and mail-server zones, and DANE. BSI TR-03108 This does not create a general obligation for every domain. Email compliance addresses whether legal requirements apply to your organisation.

The Email Security Check evaluates its own validating resolver's AD signal for MX and TXT answers at the entered name. It does not verify signatures itself; zone boundaries, DS records, algorithms and MX target zones are outside this measurement.

Alias targets, flattening and DNS providers' proxy features

Under the standard, an MX points to a name with its own address records, not an alias. Some DNS providers offer features that return address data directly instead of an alias (“CNAME flattening”), or route web traffic through a proxy. Both may change the answer a sender actually receives. Cloudflare's documentation provides an example:

• Flattening: Cloudflare resolves an apex CNAME by default and returns the target address instead of the alias; paid plans also support this for all or individual CNAMEs. If the alias target has no address, the answer remains empty. Cloudflare: CNAME Flattening, setup
• Proxy: Cloudflare returns its own anycast addresses for proxied names; SMTP does not run through that proxy. If an MX points to such a name, Cloudflare automatically inserts a name of the form _dc-mx.<identifier>.example.com in MX answers, pointing to the origin address. The public MX answer then differs from the entry in the management interface. Cloudflare: unexpected DNS records

Other providers offer similar, non-standardised features under their own names; their documentation is authoritative. Use a dedicated hostname for MX targets, without an alias or proxy, with the mail server's addresses. Then check the public answers as described under checking.

; Recommended: MX points to a name with its own address data
example.com.        IN  MX     10 mx1.example.com.
mx1.example.com.    IN  A      203.0.113.10

; Non-conforming: MX points to an alias
example.com.        IN  MX     10 mail.example.com.
mail.example.com.   IN  CNAME  mx.provider.example.

The Email Security Check issues no separate warning for alias targets; its SMTP probe resolves the name as a sender would. DNS security: choosing a DNS provider explains how provider choice affects DNSSEC and key rollover.

Check MX configuration: separate DNS, connection and message tests

Three layers answer different questions. Success at one layer does not prove the next.

1. Read DNS. The following queries read DNS only. Replace example.com with your domain and mx1.example.com with each returned MX host. Record the response status, resolver used and time. These commands were not executed for this guide.

dig example.com MX
dig mx1.example.com A
dig mx1.example.com AAAA

On Windows, query DNS explicitly as follows:

Resolve-DnsName -Name example.com -Type MX -DnsOnly
Resolve-DnsName -Name mx1.example.com -Type A -DnsOnly
Resolve-DnsName -Name mx1.example.com -Type AAAA -DnsOnly

Compare targets, preferences and addresses with your plan or mail service requirements. Empty output without a response status does not prove the absence of MX records. BIND: dig, Microsoft: Resolve-DnsName

2. Check the connection. Test SMTP acceptance on port 25 for your own MX hosts, including STARTTLS, from a network that permits outgoing port 25 connections. SMTP TLS provides suitable commands and their limits. Test only systems you operate or are authorised to check.

3. Send a message. Send a controlled test message from an external account to a mailbox on your domain. The Received headers show which server accepted it.

What MX data the Email Security Check collects

The primary location starts first; after three seconds without a usable result, or an earlier failure, the second location may join. The first complete result is used; this is not a systematic location comparison. A timeout or aborted test is an unresolved finding, not evidence of absent encryption. The MX finding itself contributes no points. Read the host, time and outstanding checks stated in the result; the check's scope is described on its page.

Common failure patterns

• MX points to an IP address or alias: Replace the target with a hostname that has its own A or AAAA records.
• Null MX alongside other MX records: Decide whether the name should receive mail, then publish either regular MX records only or null MX alone.
• Backup MX accepts every address: Align the recipient list and filtering with the main system; otherwise notifications to forged senders result.
• MX points to a proxied web name: Use a dedicated, unproxied name for the mail server; recognise _dc-mx names in answers as a provider feature.
• AAAA published, IPv6 reception not configured: Configure the service and firewall for IPv6 or remove the AAAA record at the MX name.
• No MX, but an A record pointing to the web server: Configure MX records if the domain should receive mail; publish null MX if it should not.
• Messages reach the old service after a provider change: Check old MX records, their TTL and the authoritative nameservers. While caches return old data, some senders still deliver to the old service; plan an overlap period to collect messages arriving there.
• Different resolvers return different answers: Check delegation and every authoritative nameserver for the zone; see DNS security.

Document findings and the limits of the evidence

When recording the state internally or for third parties, note the domain, DNS operator, MX records with preferences and TTL, target addresses by address family, hosts actually checked with the time, and outstanding or unperformed checks. A dated result documents a snapshot; it replaces neither continuous monitoring nor evidence of legal obligations. Email compliance covers requirements that may apply to your organisation. The report overview explains the structure and limits of saved results.

Relevant next topics