What is an AAAA DNS record (Quad-A explained)?

What are the requirements?

An AAAA record contains an IPv6 address

RFC 3596 defines the AAAA record type as a resource record that stores one IPv6 address in its RDATA. RFC 3596 also specifies that its type value is 28.

An IPv6 address has 128 bits. RFC 4291 defines IPv6 address text representation, including hexadecimal groups separated by colons and the :: compression convention for one contiguous sequence of zero-valued groups.

; Illustrative only. Publish the IPv6 address assigned to your own service.
www.yourdomain.com. 3600 IN AAAA 2001:db8:1234:5678::10

Do not copy the example address into a live zone. 2001:db8::/32 is reserved for documentation, and your provider or network team must supply the routable IPv6 address for the service.

The record owner name must match the service name

The left side of the record identifies the DNS name clients query. A zone editor may display the zone apex as @, but @ is a provider-editor shorthand, not a literal DNS label sent to resolvers.

For example, a record for www.yourdomain.com can direct clients to an IPv6 web endpoint, while a record for smtp.yourdomain.com can direct clients to a distinct IPv6 SMTP endpoint. Do not assume that an AAAA record for one name applies to every host beneath the domain.

A service may have multiple AAAA records. DNS can return more than one IPv6 address for the same owner name, and the client chooses how to use the returned addresses. That DNS result does not establish that each address has the same application configuration or health.

A dual-stack service can publish A and AAAA records together

An A record contains an IPv4 address, while an AAAA record contains an IPv6 address. A host can publish both:

; Illustrative only.
www.yourdomain.com. 3600 IN A    192.0.2.10
www.yourdomain.com. 3600 IN AAAA 2001:db8:1234:5678::10

Publishing both records does not make IPv4 and IPv6 interchangeable. Each address must route to a host that can serve the intended protocol, certificate name, and application behavior. Test the actual hostname on both address families after a change.

An AAAA record is forward DNS, not reverse DNS

An AAAA record maps a name to an IPv6 address. Reverse DNS maps an address back to a name through the ip6.arpa namespace. The reverse mapping uses a PTR record, which is a separate administrative control. See the related guide to PTR records and reverse DNS before treating a forward AAAA record as evidence that reverse DNS is configured.

This distinction matters for outbound email. A public AAAA lookup can show the address a hostname publishes. It cannot show which IP address a production mail platform uses to send a specific message, whether the address has an appropriate PTR record, or whether a receiving mailbox provider accepts that mail.

When does the requirement take effect?

There is no mailbox-provider enforcement date for publishing an AAAA record. It is a DNS and IPv6 mechanism, not a sender-volume requirement.

RFC 3596 was published in October 2003 as a Standards Track RFC and obsoleted RFC 1886. It remains the controlling RFC for the AAAA resource record type. RFC 4291, published in February 2006, defines the IPv6 addressing architecture and standard textual representation used for IPv6 addresses.

A DNS provider may have its own interface labels and validation rules. Those are implementation details, not changes to the AAAA record standard. Confirm the current path in the provider's documentation before editing a production zone.

How do I implement the requirement?

1. Confirm that the target service supports IPv6

Get the exact public IPv6 address from the hosting, network, or platform owner. Confirm that the service is configured to listen on IPv6 and that firewall and routing rules allow the intended traffic.

Do not create the AAAA record first and use it to discover whether the service is ready.

2. Identify the exact hostname

Choose the hostname clients will use, such as www.yourdomain.com, api.yourdomain.com, or smtp.yourdomain.com.

Check existing A, AAAA, and CNAME records for that name. A name with a CNAME has DNS constraints that require the alias target to provide the address response. Do not add conflicting records without understanding the existing zone design.

3. Add the AAAA record in the authoritative DNS zone

Create an AAAA record for the hostname and enter the assigned IPv6 address as the value. Select a TTL that fits the operational change window and your normal DNS caching policy.

Record the prior DNS state before replacing an existing AAAA value. An incorrect IPv6 address can affect clients that prefer or select IPv6 even when the IPv4 service remains healthy.

4. Query the authoritative DNS servers

Find the authoritative nameservers for the zone, then query one directly. This separates a zone-publishing problem from cache behavior at a public resolver.

dig @ns1.example-dns.net AAAA www.yourdomain.com +short

The response should contain the intended IPv6 address. Replace ns1.example-dns.net with an authoritative nameserver for your own zone.

5. Test the hostname over IPv6

Use an IPv6-capable test network or monitoring location to request the exact hostname and protocol. For a web service, test HTTPS with the hostname so certificate and virtual-host configuration are included.

curl -6 --verbose https://www.yourdomain.com/

A successful DNS answer alone does not prove this request will succeed.

How do I validate compliance?

Validate an AAAA deployment in layers.

First, query the authoritative server and at least one public resolver. Confirm that both return the intended IPv6 address after caches expire.

Second, test the actual service over IPv6 using the hostname. For a website, verify the HTTPS request, certificate name, redirect behavior, and expected application response. For SMTP or another protocol, use a controlled test that exercises that protocol rather than a web request.

Third, compare IPv4 and IPv6 behavior if the service is dual-stack. The same hostname can resolve correctly on both families while one path points to an old application release, a different certificate, or a blocked port.

For email infrastructure, inspect the headers of a real message sent through the production path and then review aggregate reporting when it is available. A correct AAAA record does not prove that the sending source passes SPF, that DKIM signs the message, or that DMARC aligns. DNS text-based authentication controls have their own requirements, including TXT records.

Check the published IPv6 record before changing production traffic

If you have the hostname and need to inspect its public DNS response, use the Palisade DNS lookup tool to check the published record before redirecting production traffic. Compare the result with an authoritative-server query and an IPv6 service test.

A public DNS lookup does not prove that the destination accepts connections, that the production mail path uses that IPv6 address, or that a receiver will accept a future message.

If your organization needs to track which sending sources still fail authentication or alignment across domains, Start with Palisade. Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes the next policy step for human review. It does not change your DNS or DMARC policy automatically, and it cannot prove IPv6 application reachability from a published AAAA record.