A record and email: how Address records participate in mail delivery

An A record (Address record) is the basic DNS record type that maps a domain name to an IPv4 address. When any client looks up example.com, the resolver returns an IP address through that A record. It is the foundation of DNS and, by extension, the foundation of email routing.

A records have no direct role in accepting mail — that is what MX records are for. But A records serve the hosts that MX records point to, and they act as a last-resort delivery mechanism when no MX records exist.

A records as backing for MX hosts

An MX record contains a hostname, not an IP address. To connect to a mail server, the sending MTA must resolve that hostname to an IP:

The sending MTA gets the MX record (mail.example.com), then queries for the A record of that host (198.51.100.25), and connects to the server at that IP. Without an A record for the MX host, delivery fails even when the MX entry itself is correct.

This is a common migration pitfall. An admin updates the MX record to point to a new hostname but forgets to create an A record for it. Or the reverse: the A record for the MX host still points to the old IP where the server no longer runs. In both cases, incoming mail stops arriving, even though MX technically points to the right name.

A record fallback when MX is missing

RFC 5321 (section 5.1) defines the lookup order for finding a mail server:

1. The MTA queries for MX records on the recipient domain.
2. If MX records exist, the MTA uses them in priority order.
3. If no MX records are found, the MTA queries for an A record (or AAAA for IPv6) on the domain itself and attempts delivery to that IP on port 25.

Example: no-mx.com has no MX record, but its A record points to 203.0.113.50. An MTA will connect to 203.0.113.50:25 and try to deliver. If an SMTP server is running on that IP, the message gets accepted.

In practice, relying on this fallback is a bad idea. Gmail and other large providers support the behavior, but less common MTAs may return "no MX record found" without trying the A record. A domain with no MX also looks misconfigured, which can lower trust with receiving servers.

A record vs AAAA record

A records handle only IPv4 addresses (32-bit, xxx.xxx.xxx.xxx format). IPv6 (128-bit) uses AAAA records. Email still runs mostly on IPv4: the overwhelming majority of MTAs send and receive over IPv4. Large providers are gradually adding IPv6 support, though.

If your mail server is reachable on both protocols, set up both A and AAAA records for the MX host. PTR records for both addresses are mandatory too. Gmail checks reverse DNS for IPv6 addresses on sending servers and rejects mail when no valid PTR is found.

TTL and mail server migration

Every A record has a TTL (Time To Live): how long resolvers cache the value. With a TTL of 86400 seconds (24 hours), other servers across the internet will keep connecting to the old IP for up to a day after you update the record.

For a mail server migration this matters a lot. The standard approach: one or two days before the cutover, drop the A record TTL for the MX host to 300 seconds (5 minutes). Wait for the old TTL to expire at all resolvers. Then switch the IP. Propagation of the new value takes 5 minutes instead of 24 hours. Once things stabilize, bring the TTL back to something reasonable (3600 to 86400).

A records in SPF

SPF records support an a mechanism that authorizes the IP from the domain's A record to send mail:

The a mechanism here means: allow sending from the IP listed in the domain's A record. Convenient when the web server and the outbound mail server share the same address. But if your site and your mail run on different IPs, that a mechanism creates a false permission: anyone sending from the web server's IP will pass SPF.

A records and PTR: the forward-reverse pair

An A record maps a name to an IP (forward DNS). A PTR record maps an IP back to a name (reverse DNS). For mail servers these need to be consistent: the A record for mail.example.com points to 198.51.100.25, and the PTR for 198.51.100.25 returns mail.example.com. This pairing is called forward-confirmed reverse DNS (FCrDNS).

Many receiving servers check FCrDNS on inbound connections. A mismatch between A and PTR is a signal of potential spam or a compromised server, and mail from those IPs ends up in spam filters more often.

A records in email validation

When validating an email address, a validator first looks up MX records for the domain. If none are found, it falls back to the A record. If neither MX nor A records exist, the domain cannot receive mail, and the address is marked invalid.

The validator also checks that the A record for the MX host resolves to a working IP and that an SMTP server is actually responding there. This catches dangling DNS entries where MX points to a host whose A record leads to a powered-off server or a non-routable IP.