A and AAAA records map a hostname to IPv4 and IPv6 addresses. They are dependencies of a mail service, not declarations that the service is ready or authorized to send. Publishing an address can expose a route that clients actually try, so verify every advertised family and endpoint.
Follow the name used by the protocol
References: RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
For inbound SMTP, resolve the exchange hostnames returned by MX. The recipient domain's website address is not a substitute when explicit exchanges are unusable. If no MX exists, SMTP's implicit-MX rule can make the recipient domain's own A or AAAA records relevant instead.
For outbound SPF, examine the actual policy and evaluated identity. An a mechanism can authorize addresses returned for its specified name; a plain A record does not authorize anything by itself. Similarly, changing a hostname used by an SPF mx mechanism can change the addresses evaluated as authorized. Record these references before treating a DNS address edit as a website-only change.
Treat dual stack as two operating paths
References: RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
A hostname can have several A records and several AAAA records. Their presence does not guarantee reachability, SMTP service, the correct certificate or equivalent policy. A healthy IPv4 endpoint does not establish that IPv6 works. Conversely, failure on one client path does not prove every sender uses that path.
Capture the destination address actually attempted, address family, connection outcome and SMTP response. If investigating outbound traffic, capture the externally observed source address rather than assuming it matches the address used inside the application. NAT and provider egress pools can make those values different.
Reproduce an address-family fault
Synthetic fixture: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com. AAAA 2001:db8::10. In the lab, configure the IPv4 endpoint to accept TCP connections on port 25 and leave the IPv6 endpoint unreachable. Expected DNS checks succeed for both record types, while a family-specific connection test succeeds only for IPv4.
Query dig @AUTH mx.example.com. A +norecurse and then the same command with AAAA. Replace AUTH with the isolated authority. Record both answers. Use your approved lab SMTP client to pin each destination independently, recording connection and protocol outcomes. The fixture illustrates why DNS success is not service success; it makes no claim about a particular sender's fallback timing.
A second fixture changes only the A address from 192.0.2.10 to 192.0.2.20 while the SPF policy is v=spf1 a:mx.example.com -all. For an IPv4 SPF evaluation with otherwise successful lookups, the address eligible to match the a mechanism changes. An explicit ip4:192.0.2.10 mechanism would instead remain tied to that literal network until the policy itself changed.
Make address changes reversible
References: RFC 8767 §4.
Inventory all consumers of the hostname, including mail routing, SPF references, monitoring and certificate expectations. Prepare the endpoint before advertising it. Retain the old service while appropriate caches can still direct traffic there, based on the actual migration plan rather than a universal waiting period.
After the change, compare authoritative answers with recursive observations and message-level evidence. A failed IPv6 endpoint should be repaired or removed through an approved change, not hidden by weakening unrelated authentication policies. Close the work only when the intended addresses and operating paths match the documented service design.
Keep the evidence scope explicit
For the two-family scenario, keep the expected IPv4 success and IPv6 failure as proposed lab observations until tested. The SPF address-change example assumes successful lookups and the stated policy; it does not establish current authorization for any real sender.