AAAA Record Lookup Guide: Check a Pasted AAAA Record
If an A record is the IPv4 address book entry for a hostname, an AAAA record is its IPv6 counterpart. It maps a hostname to an IPv6 address, which is written as eight groups of hexadecimal digits separated by colons, such as 2606:2800:220:1:248:1893:25c8:1946. IPv6 exists because the IPv4 address space, with roughly four billion addresses, is no longer enough for the number of connected devices, while IPv6 offers a vastly larger space. As more networks and providers adopt IPv6, a missing or mistyped AAAA record can mean that some visitors reach your site over one protocol and others fail over the other, with confusing, inconsistent symptoms.
The AAAA Record Lookup tool checks the format of a pasted AAAA record. As with its A-record counterpart, the scope is format validation only: it performs no live DNS lookup, and it cannot tell you whether the record is published, whether the address is reachable, or whether the server behind it is configured for IPv6. What it does is verify that the pasted text is shaped like a valid AAAA record, with a plausible hostname and a plausible IPv6 address, free of the typos that IPv6's long, colon-filled notation invites. Given how easy it is to drop a group, mistype a hex digit, or misplace a double colon, that check earns its keep quickly.
IPv6 notation has rules that make it both compact and error-prone. Each address has eight groups, each group holding one to four hexadecimal digits, where hexadecimal digits are 0 to 9 and a to f. Leading zeros inside a group may be omitted, so 00ff can be written as ff. One run of consecutive all-zero groups may be replaced by a double colon, so an address with several zero groups in a row can be shortened dramatically. But the double colon may appear only once in an address, because two of them would make it impossible to know how many zero groups each one stands for. An address with more than eight groups, a group of five hex digits, or a character outside the hexadecimal range is malformed, however plausible it looks at a glance.
A worked example you can follow
Take a sample record: www.example.com pointing to 2606:2800:220:1:248:1893:25c8:1946. Check the name first: www, example, and com are letter-only labels, none starting or ending with a hyphen, so the name passes. Then count the address groups by counting colons: this address has 7 single colons separating 8 groups, since 8 groups need 8 minus 1, or 7, separators. Check each group for length and characters: 2606 has 4 hex digits, 2800 has 4, 220 has 3, 1 has 1, 248 has 3, 1893 has 4, 25c8 has 4, and 1946 has 4. Every group is between 1 and 4 digits long, and every character is a hex digit, so the sample passes.
Now take a shortened sample: 2001:db8::1. Here the double colon stands for consecutive zero groups. Counting visible groups gives 3: 2001, db8, and 1. Since a full address needs 8 groups, the double colon must stand for 8 minus 3, or 5, zero groups. Expanding it gives 2001:0db8:0000:0000:0000:0000:0000:0001, which is 8 groups, confirming the shortened form is valid. A broken sample shows the traps: 2001:db8::1::2 contains two double colons, which is never allowed, because the expansion becomes ambiguous. Another broken sample, 2001:db8:12345::1, contains a group of 5 hex digits, and 5 minus 4 equals 1 digit too many, so it fails. A third broken sample, 2001:db8::g1, contains the letter g, which is not a hexadecimal digit, so it fails as well. In each case, the fix is to correct the single offending group and re-check the whole address.
When you paste a record, watch for the same copying hazards as with A records: trailing spaces, line breaks inside the address, and dots typed where colons belong, or the reverse. IPv6 addresses are long, and a single dropped colon can merge two groups into one over-long group, which the checker will flag. Read the reported error position, fix that spot, and re-check the full record.
Common mistakes to avoid
The first mistake is treating a format pass as proof the record works live; publication, reachability, and server configuration are separate checks. The second mistake is using the double colon twice, or using it when no run of zero groups exists, which makes the address ambiguous or needlessly confusing. The third mistake is mixing IPv4 and IPv6 notation carelessly, for example by pasting an IPv4 address into an AAAA record field. The fourth mistake is publishing an AAAA record for a server that is not actually reachable over IPv6, which can make IPv6-capable visitors fail while IPv4 visitors succeed, producing reports that are hard to reproduce unless you test both protocols.
The DNS Lookup tool helps you think about DNS records in general, and the SSL Certificate Checker tool covers the certificate side once a site resolves. For background on DNS-adjacent configuration, see SPF, DKIM and DMARC Guide.
Checking the result before you publish it
A passing format check is step one of three. Step two is confirming the record is in the correct zone with no conflicting record for the same name. Step three is testing after propagation, ideally over both IPv4 and IPv6, so a protocol-specific failure is caught before visitors report it. A record that passes all three steps, format, placement, and live testing, is one you can rely on, and skipping any step leaves a class of error entirely unexamined.
A final point worth remembering is consistency between the two address families. A hostname that publishes both an A record and an AAAA record should point both at servers that actually serve the site, because visitors may arrive over either protocol depending on their network. If the IPv4 address points at a live server while the IPv6 address points at a retired one, some visitors will fail while others succeed, and the failure pattern will look random until someone tests both protocols separately. Checking both records together, rather than treating IPv6 as an afterthought, prevents that split-brain outcome and keeps the site reachable for every visitor, whichever protocol their network prefers.