Defaults.Exposed › Fixes › IPv6 support

How to fix IPv6 support

IPv6 is the newer, much larger version of the internet's addressing system, brought in because the old one (IPv4) has run out of room. Adding IPv6 support means your website and email can be reached over the modern network as well as the old one. On our scoring this is informational — not having it does not lower your grade — but it is a real-world reach issue: a growing slice of mobile and overseas customers connect over IPv6-only networks, and they reach you smoothly only if you support it. The fix is free and lives in your DNS and hosting setup.

Bottom line for your business: A rising share of internet users — especially on mobile carriers and in fast-growing markets in Asia and parts of Europe — now connect over IPv6. If your site is IPv4-only, those visitors still usually get through (their carrier translates the connection for them), but that translation adds a hop, can be slightly slower, and is one more thing that can fail or be throttled at busy times. Supporting IPv6 means a cleaner, more direct connection for modern customers, a small future-proofing win, and a tidy signal to technical buyers that your infrastructure is current. It changes nothing about your grade — treat it as forward-looking polish, not an emergency — but it is free to add and aligns you with where the internet is heading.

What this can cost you

A customer on a mobile carrier that runs IPv6-only has to reach your IPv4 site through their carrier's translation layer. It almost always works — but it adds latency and is one more dependency that can hiccup at peak times, making your site feel marginally slower than a competitor who is reachable directly.
A technical buyer or partner's security/infra team runs a quick scan before signing and notes you're IPv4-only. It doesn't fail you, but a competitor who shows dual-stack (IPv4 + IPv6) lands in the 'modern, well-run' column while you sit in 'fine, a bit behind'.
You expand into a market — parts of Asia, India, some European mobile networks — where IPv6 is already dominant. Being directly reachable there, rather than always via translation, removes a small but real source of slow or flaky connections for your newest customers.
Your hosting or CDN already supports IPv6 for free, but nobody ever switched it on, so you're missing an easy, zero-cost improvement that your competitors picked up by default.
A government or enterprise procurement checklist asks whether your services are IPv6-ready (many public-sector mandates now do). 'No' is an awkward line to explain when the fix was free all along.

Why it matters. On our methodology, IPv6 support is informational — the check is registered with zero points and never moves your grade. We report it because it is a genuine, forward-looking reach-and-modernity signal: the internet ran out of old-style (IPv4) addresses years ago, and the share of users connecting over IPv6-only networks keeps climbing, particularly on mobile and in IPv6-dominant regions. Supporting IPv6 gives those users a cleaner, more direct path to your site and email, and signals current infrastructure to anyone who checks. It's free to add and rarely breaks anything — which is exactly why it's worth doing even though it doesn't affect your score.

IPv6 support, in plain words

The internet identifies every server with a numeric address. The original system, IPv4, has a fixed, fairly small pool of addresses — and the world ran out of fresh ones years ago. Its replacement, IPv6, has an effectively unlimited pool, and the internet has been quietly migrating to it ever since.

IPv6 support means your website (and email) can be reached over this newer network as well as the old one. In practice it comes down to one thing in your DNS: alongside the record that lists your old-style address (an A record), you also publish a record that lists your IPv6 address (an AAAA record — four A’s). Running both side by side is called dual-stack, and it’s the normal, safe way to do this.

This check is informational. It does not change your grade. We look up whether your domain publishes any AAAA records and simply report what we find — present, or absent. We’re flagging it because it’s a real-world reach-and-modernity signal that’s free to fix, not because it’s a failure.

What this can cost you

It rarely causes a hard outage — that’s exactly why it’s informational rather than scored. But “invisible cost” is still cost. Here are the realistic ways an IPv4-only setup quietly works against you:

A slightly slower experience for mobile customers. Many mobile carriers now run IPv6-only internally. A customer on such a network reaching your IPv4-only site goes through their carrier’s translation layer — an extra hop that adds latency and can congest at peak times. Your competitor with IPv6 gives that same customer a direct, cleaner connection. On a checkout page, small slownesses add up to abandoned carts.
A weaker impression with technical buyers. Before a contract is signed, a buyer’s IT or security team often runs a quick infrastructure scan. IPv4-only doesn’t fail you — but dual-stack reads as “modern and well-run,” and its absence reads as “a bit behind.” When you’re close on everything else, these small signals tip decisions.
Friction in IPv6-dominant markets. If you’re expanding into regions where IPv6 is already the norm — parts of Asia, India, several European mobile networks — being directly reachable there removes a real source of slow or flaky connections for your newest, hardest-won customers.
A failed procurement checkbox. A growing number of public-sector and enterprise procurement processes now ask, explicitly, whether your services are IPv6-ready. “No” is an awkward answer to give when the fix was free.
Leaving free improvement on the table. Very often your host or CDN already supports IPv6 at no extra cost — it was simply never switched on. That’s an easy, zero-cost win your competitors picked up by default and you didn’t.

What it actually is

Every device on the internet needs an address. IPv4 addresses look like 203.0.113.10 — four numbers, a pool of about 4.3 billion, long since exhausted. IPv6 addresses look like 2001:db8::1 — longer, hexadecimal, with a pool so vast it’s effectively limitless.

In your DNS — the internet’s address book — these live as two record types:

A record → your IPv4 address (the old network).
AAAA record → your IPv6 address (the new network).

Our check does the equivalent of running dig AAAA yourdomain.com and reports whether any AAAA records come back.

What “good” looks like: a dual-stack setup — your existing A records untouched, with AAAA records published alongside them, both pointing at a server (or load balancer, or CDN) that genuinely answers on both networks and serves the same site. IPv4 users carry on exactly as before; IPv6 users get a direct path. You don’t drop IPv4 — you add IPv6 next to it.

What “absent” means: no AAAA records. IPv6-only users can still usually reach you via their carrier’s translation, but never directly. It’s not broken — it’s just a missed modernisation, which is why it doesn’t cost you points.

How to fix it (free, ~15–30 minutes)

Hand this to your IT person or whoever manages your website — the fix is free. It’s a DNS-and-hosting change, not a purchase. The golden rule: add IPv6 alongside IPv4, never instead of it (dual-stack), and confirm the target actually answers on IPv6 before you publish.

1. Find out whether your hosting/CDN supports IPv6 at all. This is the gate. If your host has no IPv6 address to offer, there’s nothing further to do and no penalty for it. Most modern platforms and CDNs do support it — often already on.

2. Apply it on your platform:

Cloudflare: IPv6 is typically on by default. When your site is proxied through Cloudflare (orange cloud), Cloudflare answers on IPv6 for you automatically — you usually don’t add AAAA records yourself at all. Check Network → IPv6 Compatibility is enabled. This is the easiest path by far.
Google Workspace / Microsoft 365 (email side): the email-receiving side is generally already IPv6-capable on the provider’s infrastructure — you don’t manage that. This page’s website AAAA records are about your site, not their mail servers; no action needed for the mailbox provider itself.
AWS: enable dual-stack on your load balancer (ALB/NLB) or instance, then add an AAAA alias record in Route 53 pointing at it. For CloudFront, IPv6 is a toggle in the distribution settings.
Google Cloud / Azure: enable IPv6 (dual-stack) on the load balancer or instance, obtain the IPv6 address, and publish the AAAA record in your DNS.
Self-hosted / managed VPS: ask your provider for an IPv6 address, configure your web server to listen on IPv6 (and confirm it serves the same site there), then add the DNS record:
```
yourdomain.com.      AAAA   2001:db8::1
www.yourdomain.com.  AAAA   2001:db8::1
```
(Replace with your real IPv6 address. Keep your existing A records exactly as they are.)

3. Test before you trust it. After publishing, verify from an IPv6-aware tool that the AAAA record resolves and the site actually loads over IPv6 (an online “IPv6 test” or curl -6 https://yourdomain.com from an IPv6-capable machine). A published AAAA record that points nowhere is worse than none.

4. Re-scan. Once AAAA records are live and answering, this check will report IPv6 as enabled. (It won’t change your grade — it was informational all along — but you’ll have closed the gap.)

Common mistakes

Publishing an AAAA record that points to a server not listening on IPv6. This is the classic self-inflicted wound: IPv6 users get sent to a dead address and your site appears broken for them only — hard to notice, since it works fine for you on IPv4. Always confirm the target answers on IPv6 before publishing.
Replacing IPv4 instead of adding IPv6. You never remove your A records. Dual-stack keeps both; dropping IPv4 would cut off the majority of users overnight.
Adding the apex domain but forgetting www (or vice versa), or covering the site but not the mail/subdomains you care about. Be consistent across the hostnames that matter.
Assuming it’s done because the host “supports” IPv6. Support and enabled are different. On Cloudflare it’s usually automatic; on a raw VPS you have to configure and publish it yourself.
Treating this as urgent. It isn’t. It’s informational. Do your scored security checks (HTTPS, DMARC, DNSSEC, the security headers) first; add IPv6 as forward-looking polish when it’s convenient.

FAQ

If my IPv4-only site still loads for everyone, why does IPv6 matter at all?

Because 'still loads' is doing a lot of work. Users on IPv6-only networks — common on mobile carriers and increasingly elsewhere — reach an IPv4-only site through their carrier's translation layer (NAT64/464XLAT). That usually works, but it's an extra hop that adds a little latency and is one more shared piece of infrastructure that can be slow or congested at peak times. Supporting IPv6 gives those users a direct connection instead. It's a smoothness-and-future-proofing improvement, not a 'broken vs working' switch — which is why it's informational and not scored.

This doesn't affect my grade — should I bother?

It's genuinely optional, but it's also free and low-risk, so it's worth doing when your IT person is next in the DNS or hosting console. Many providers (Cloudflare, the big cloud platforms, lots of hosts) support IPv6 out of the box — sometimes it's just a toggle. If yours doesn't support it at all, that's a fine reason to leave it for now; nothing bad happens to your score either way. Treat it as a tidy-up, not a fire drill.

I'm not technical — what do I actually do?

Hand the 'How to fix it' section to whoever runs your website or DNS and ask: 'Can we add IPv6 (AAAA records) for our site? It's free and shouldn't break anything.' If you're on Cloudflare it's usually already on. If you're on a managed host or a big cloud platform, it's often a single setting. If your host doesn't support IPv6 at all, there's nothing to do — and no penalty for it.

What is an AAAA record, in plain terms?

Your DNS is the internet's address book. An 'A record' lists your site's old-style (IPv4) address; an 'AAAA record' (four A's) lists its newer IPv6 address. Adding IPv6 support means publishing AAAA records alongside your existing A records, so devices on the new network can find you directly. Our check simply looks up your AAAA records (the technical equivalent of running 'dig AAAA yourdomain.com') and reports whether any exist.

Could adding IPv6 break my website or email?

It's low-risk when done right, but not zero-risk, which is why you test. The safe pattern is 'dual-stack' — you keep all your existing IPv4 (A) records exactly as they are and add IPv6 (AAAA) records alongside them. IPv4 users carry on unchanged; IPv6 users get a new direct path. The thing to verify is that whatever the AAAA record points to (your server or load balancer) is actually listening on IPv6 and serving the same site — a stale or wrong AAAA record can send IPv6 users to a dead address. On managed platforms and CDNs this is handled for you; on self-hosted setups, confirm the server answers on IPv6 before publishing.

Does IPv6 make my site more secure?

Not by itself — it's primarily a reach and modernity improvement, not a security control, which is part of why it doesn't score. It's referenced in broader risk-management frameworks (for example NIS2's general cybersecurity risk-management duties) as part of running current, resilient infrastructure, but adding an AAAA record doesn't harden you the way HTTPS, DMARC or DNSSEC do. Do the scored security checks first; treat IPv6 as forward-looking infrastructure hygiene on top.