IPv6 Compatibility Test

Check if your domain has AAAA records and is accessible via the modern IPv6 protocol.

Evidence ASSESSED

Checked against: AAAA record plus IPv6 reachability

RED TEAM 0 findings BLUE TEAM control did not hold

Why IPv6 Matters?

IPv6 is the latest version of the Internet Protocol, designed to replace IPv4 as the world runs out of IP addresses.

Future-Proofing: As more devices and ISPs switch to IPv6, having native support ensures all users can reach your site with optimal performance.
Performance: IPv6 can be slightly faster as it eliminates the need for Network Address Translation (NAT) in many cases.
SEO & Compliance: Search engines like Google prioritize modern, accessible web standards, and IPv6 is a key part of that.

Our IPv6 Readiness Test checks whether your domain is genuinely reachable over IPv6 — not just whether an AAAA record exists, but whether the web server, mail servers and nameservers all answer over the protocol.

What is IPv6 Readiness?

IPv6 readiness means your infrastructure is reachable over IPv6 end to end, not merely that a record exists in DNS.

Full readiness has several layers. The web server needs an AAAA record and must actually listen on that address. Mail servers need AAAA records on their MX hosts if they are to accept mail over IPv6. The authoritative nameservers themselves should be reachable over IPv6, so that an IPv6-only client can resolve your domain without needing IPv4 at any point.

Partial readiness is common and can be worse than none. A published AAAA record pointing at a server that does not answer causes dual-stack clients to attempt IPv6 first, wait for a timeout, and only then fall back — turning a fast connection into a slow one.

Requires AAAA records and servers actually listening on them
Covers web, mail and DNS infrastructure, not just the website
IPv6-only clients need IPv6-reachable nameservers to resolve you
A broken IPv6 path is slower than having no IPv6 at all
Over 40% of traffic to major providers now arrives over IPv6

Why IPv6 Readiness Matters

IPv4 addresses ran out years ago. Mobile carriers in particular now run IPv6-only networks internally, translating to IPv4 at a NAT64 gateway for legacy destinations. Every visitor arriving that way passes through a translation layer that adds latency, obscures their real address in your logs, and breaks protocols that embed addresses in their payload.

There is also a procurement dimension. Government contracts in several countries mandate IPv6 support, and enterprise security questionnaires increasingly ask about it. For a public-facing service it has moved from optional to expected.

Mobile carriers increasingly operate IPv6-only networks
NAT64 translation adds latency and hides real client addresses
Government procurement in several countries mandates IPv6
A half-configured IPv6 path actively slows dual-stack visitors
Direct IPv6 connectivity gives accurate client data in logs

How This IPv6 Readiness Test Works

The tool checks each layer of your infrastructure for IPv6 availability.

Validates the domain input against format and SSRF safety checks
Queries for AAAA records on the domain and the www hostname
Checks whether MX hosts have their own AAAA records
Checks whether the authoritative nameservers are IPv6-reachable
Reports an overall readiness assessment with the gaps identified

How to Use the IPv6 Readiness Test

Enter your domain name in the input field
Run the test to check each infrastructure layer
Review which components have IPv6 and which do not
Prioritise the web server, then nameservers, then mail
After enabling IPv6, verify the server genuinely responds rather than just resolving

Understanding Your IPv6 Readiness Results

Each layer is assessed separately:

Field / Value	Meaning
`Web AAAA record`	Whether the domain and www hostname resolve to IPv6 addresses. The most visible layer, and usually the first to enable.
`Server responds`	Whether the IPv6 address actually answers. A record without a listening server is worse than no record, because clients try it first and wait for a timeout.
`Mail server IPv6`	Whether MX hosts have AAAA records. Needed to accept mail from IPv6-only sending servers. Note that reverse DNS for IPv6 is required by some receivers.
`Nameserver IPv6`	Whether your authoritative nameservers answer over IPv6. Without this an IPv6-only client cannot resolve your domain at all without falling back to IPv4.
`Dual-stack`	Both A and AAAA records present and both working. The correct configuration during the long transition period.
`Partial readiness`	Some layers have IPv6 and others do not. Usually fine, but a published AAAA record on a non-responding server is the one case that actively causes harm.

Common Problems & How to Fix Them

The domain is unreachable directly over IPv6. Visitors on IPv6-only networks arrive through their provider NAT64 gateway, adding latency and obscuring their real addresses.

Request an IPv6 address from your hosting provider and add an AAAA record. Most major CDNs provide IPv6 automatically once enabled in their dashboard, which is the simplest route for many sites.

This is the one configuration worse than having no IPv6. Dual-stack clients prefer IPv6, attempt the connection, wait for a timeout, then fall back — adding seconds to the first request.

Confirm the web server binds to the IPv6 address. In nginx that means listen [::]:443 ssl;. Then check the firewall, since IPv4 rules do not apply to IPv6 and a separate ip6tables or nftables ruleset is usually required.

An IPv6-only client cannot resolve your domain without falling back to IPv4 for the DNS query itself, which defeats much of the purpose.

Most managed DNS providers offer IPv6-reachable nameservers by default. If yours does not, it is a strong reason to move. Check whether glue records at your registrar include IPv6 addresses where applicable.

You cannot accept mail directly from IPv6-only sending servers, though in practice nearly all senders retain IPv4 connectivity.

Add AAAA records to your MX hosts when you are ready. Set up IPv6 reverse DNS at the same time — some receivers apply stricter requirements to IPv6 senders than to IPv4 ones, and a missing PTR is more likely to cause rejection.

IPv4 firewall rules do not apply to IPv6 traffic. Many servers ship with permissive IPv6 defaults, so enabling IPv6 can silently expose services that were firewalled on IPv4.

Audit ip6tables or nftables separately and mirror your IPv4 policy. This is the most common security mistake made when enabling IPv6.

Best Practices

Run dual-stack with both A and AAAA records during the transition
Verify the server actually responds on IPv6 before publishing the AAAA record
Mirror your IPv4 firewall policy in ip6tables or nftables
Use IPv6-reachable authoritative nameservers
Set up IPv6 reverse DNS for any mail server with an AAAA record
Test from a genuine IPv6-only network, not just a dual-stack connection
Ensure IPv4 and IPv6 endpoints serve identical content and certificates

Security Recommendations

Audit IPv6 firewall rules separately — a hardened IPv4 firewall says nothing about IPv6 exposure
Check that internal services are not reachable on their IPv6 addresses, which is a common oversight on dual-stack hosts
Apply the same rate limiting, WAF and access control rules to IPv6 traffic
Be aware that IPv6 address space is large enough that scanning is impractical, which can create a false sense of security — services are still found through DNS and certificate logs
Ensure logging and monitoring parse IPv6 addresses correctly, since tools built for IPv4 often silently drop them
Remove AAAA records pointing at decommissioned addresses, as reassigned IPv6 space can be claimed by others

Frequently Asked Questions

It means your infrastructure is genuinely reachable over IPv6 — web server, mail servers and nameservers all answering over the protocol — rather than simply having an AAAA record published.

For a public-facing service, increasingly yes. Mobile carriers run IPv6-only networks and those visitors reach you through a NAT64 gateway that adds latency and hides their real addresses. Some government procurement also mandates it.

Yes. Dual-stack clients prefer IPv6, so a published AAAA record pointing at a non-responding server causes them to attempt IPv6, wait for a timeout, and only then fall back to IPv4 — making every first connection slow.

Running IPv4 and IPv6 simultaneously, with both A and AAAA records published and both working. This is the correct configuration during the transition, since neither protocol can yet be dropped.

It can, through one specific oversight: IPv4 firewall rules do not apply to IPv6. Many systems ship with permissive IPv6 defaults, so services firewalled on IPv4 can become reachable on IPv6. Audit ip6tables or nftables separately.

Obtain an IPv6 address from your provider, configure the network interface, bind your services to the IPv6 address, add firewall rules, publish an AAAA record, and verify the server responds. Using a CDN that provides IPv6 is often far simpler.

For full readiness, yes. An IPv6-only client must resolve your domain before it can connect, and if your nameservers are IPv4-only it cannot do that natively. Most managed DNS providers offer IPv6 nameservers by default.