IPv6-Only vs Dual-Stack Hosting for Websites, Email and SEO

IPv4 scarcity and growing IPv6 adoption raise a key hosting question: should we go IPv6‑only or stay on a dual‑stack (IPv4+IPv6) model for the next few years? This is no longer a purely network‑engineering topic. Your decision directly affects who can reach your website, how reliable your email delivery is, and how search engines see (and crawl) your content. This guide explains the trade‑offs between IPv6‑only and dual‑stack hosting for websites, email and SEO, with design patterns to evaluate for shared hosting, VPS, dedicated servers and colocation environments.

Key Concepts: IPv4, IPv6, Dual‑Stack and IPv6‑Only in Plain Language

IPv4 vs IPv6 in one minute

IPv4 is the classic addressing scheme the internet grew up on (e.g. 203.0.113.10). The available pool of unallocated addresses is largely exhausted, making IPv4 a scarce resource whose cost varies by market and provider. If you want to understand the economics behind this, we explained it in detail in our article on why IPv4 address prices are hitting record highs and what you can do about it.

IPv6 is the newer protocol with a vastly larger address space (addresses look like 2001:db8::1234). Its much larger address space reduces address scarcity and can simplify network design; performance relative to IPv4 depends on routing and network implementation.

What is dual‑stack hosting?

Dual‑stack means your service supports both IPv4 and IPv6. For a public website, its hostname typically publishes both A (IPv4) and AAAA (IPv6) records, and the server or public edge must accept connections over both protocols. Clients with working IPv6 may prefer it; IPv4‑only clients use the A record. Fallback after a failed IPv6 attempt depends on the client.

From the website owner’s point of view, dual‑stack preserves access for IPv4‑only visitors while allowing IPv6‑capable users and crawlers to connect over IPv6. Both paths must work correctly; publishing an AAAA record alone does not ensure this.

What is IPv6‑only hosting?

IPv6‑only hosting means your server has only IPv6 addresses. If you expose that server directly to the public internet, it is reachable only from IPv6‑capable clients. To serve IPv4‑only visitors, you need an IPv4‑reachable ingress that forwards traffic to the IPv6 server. Distinguish this from outbound translation:

• NAT64 + DNS64 normally lets IPv6‑only clients initiate connections to IPv4 servers. It does not automatically make an IPv6‑only website reachable by IPv4 visitors; IPv4‑initiated NAT64 access requires separately configured static bindings.
• Reverse proxies or load balancers that have both IPv4 and IPv6 and forward to an IPv6‑only backend

For more on outbound translation, see our article on running an IPv6‑only VPS with NAT64/DNS64 for access to IPv4 services. Public websites still need an IPv4‑reachable ingress if they must serve IPv4‑only visitors.

Who Can Actually Reach You? Reachability and User Impact

Global IPv6 adoption vs your real audience

Global adoption figures do not establish whether your own visitors have working IPv6. We have covered these trends in depth in our article on rising IPv6 adoption rates and what they mean for your infrastructure. However, IPv6 adoption is very uneven by country, ISP, enterprise network and mobile carrier.

For a public‑facing website, the core reachability rules today are:

• Dual‑stack: Both IPv4 and IPv6 users can reach you without protocol translation, provided the relevant network path and service configuration work. This avoids excluding visitors solely because they lack one address family.
• Pure IPv6‑only (no IPv4 ingress): Only visitors with working IPv6 connectivity can connect directly. Corporate networks and legacy ISPs may still be IPv4‑only.
• IPv6‑only with an IPv4 front layer: A dual‑stack reverse proxy, CDN or load balancer can accept IPv4 visitors and forward requests to your IPv6‑only backend. Verify both public address families and IPv6 origin connectivity; this provides dual‑stack public reachability without requiring IPv4 on the backend.

Practical consequences for different project types

Here is how the reachability requirements differ for common projects:

• Corporate and e‑commerce sites: These almost always need full reachability, including corporate networks and legacy ISPs. We strongly recommend dual‑stack on the public edge (A + AAAA records) even if your internal backends are IPv6‑only.
• Internal tools, APIs for mobile apps, staging environments: Candidates for IPv6‑only only when all required clients and network paths have working IPv6. A mobile app, VPN or private network does not by itself ensure IPv6 reachability.
• Developer test environments and cost‑sensitive labs: IPv6‑only can make a lot of sense because the lab server needs no public IPv4 address. NAT64/DNS64 can provide outbound access to IPv4 services, while a dual‑stack reverse proxy can provide inbound access for IPv4 visitors.

For public websites, the critical question is simple: can any significant part of my audience be IPv4‑only? If yes, pure IPv6‑only without a front layer is usually too risky today.

Email on IPv6‑Only vs Dual‑Stack: Where Things Get Tricky

Receiving mail: MX, IPv6 and fallbacks

For receiving email, your DNS MX records can point to hostnames that have IPv4 (A), IPv6 (AAAA) or both. Delivery over IPv6 requires the sending system to have working IPv6 connectivity and support for IPv6 SMTP delivery; an AAAA record alone does not ensure that.

If none of your MX targets is reachable over IPv4, an IPv4‑only sender cannot connect directly. Preferring IPv4 is not the same as lacking IPv6 support. Depending on the sender’s retry policy, unreachable mail may be queued and eventually returned as undeliverable rather than delivered to your mailbox.

For reliable inbound reachability:

• For domains that accept important business mail, use dual‑stack MX endpoints (both A and AAAA).
• If your actual mail server is IPv6‑only, place a dual‑stack SMTP proxy or smart host in front, which speaks IPv4+IPv6 to the outside and IPv6 to the backend.

Sending mail: reputation, blocklists and IPv6‑only pain points

For sending email, IPv6‑only adds both reachability and deliverability considerations. Working IPv6 connectivity is not enough: sender reputation, authentication and valid forward and reverse DNS also matter. Configuration problems can lead to rejection, deferral or spam placement, and correct configuration does not guarantee inbox delivery.

We wrote a dedicated field guide on this topic: Email deliverability over IPv6: PTR, HELO, SPF and blocklists. The most important operational lessons from that guide are:

• Configure a correct PTR (reverse DNS) record for each sending IPv4 and IPv6 address, with the PTR hostname resolving back to that address. We also have a separate primer on what PTR / reverse DNS is and how it affects email delivery.
• Use consistent HELO/EHLO hostnames that match forward and reverse DNS.
• Authorize all legitimate IPv4 and IPv6 senders in SPF. Enable outgoing DKIM signing and publish its public keys, then publish a DMARC policy with alignment to the visible From domain through SPF or DKIM. DKIM and DMARC records do not list sending IP addresses.
• Monitor blocklists that track IPv6 ranges, not only IPv4.

If you move to pure IPv6‑only sending with no IPv4 fallback or relay, you cannot connect directly to recipient systems that have no reachable IPv6 MX endpoint. Your sending server may queue those messages and eventually return a delivery failure. For customer‑facing domains, that is usually an unacceptable risk today. Dual‑stack sending remains the practical sweet spot.

SEO and Crawlability: How Search Engines See IPv6‑Only vs Dual‑Stack

Can search engines crawl over IPv6?

An IPv6‑capable crawler can access an IPv6‑only website if its network path and your server configuration allow it. Do not assume this covers every search engine or crawler: verify the engines you rely on before removing IPv4 access. Crawl access alone does not guarantee indexing or ranking. Three related operational areas also favor keeping a dual‑stack public edge:

• Consistency of crawling infrastructure: Some SEO tools, link checkers and third‑party bots you rely on may still be IPv4‑only. If they cannot reach your content, you might miss broken links, performance regressions or technical SEO issues.
• CDN and HTTP feature support: An edge or CDN can provide HTTP/2, HTTP/3, TLS termination and caching, which may improve loading performance. Verify that the chosen edge accepts both IPv4 and IPv6 visitors and can connect to an IPv6‑only origin; client-facing IPv6 support alone does not establish origin support.
• Third‑party callbacks and webhooks: Payment notifications or headless CMS webhooks sent to your site need a compatible network path. IPv4‑only senders require an IPv4‑reachable endpoint. Browser-loaded embeds and analytics beacons instead depend on the visitor’s connectivity to those third‑party services; they are not inherently broken by an IPv6‑only origin.

If you are already working on performance and SEO from the hosting side, you might have read our guide on how HTTP/2 and HTTP/3 affect SEO and Core Web Vitals when you choose hosting. The key takeaway is to distinguish crawlability, user experience and ranking. Reliable reachability lets crawlers access your pages, and Core Web Vitals are used by Google’s ranking systems, but neither good performance nor choosing IPv6 guarantees higher rankings.

Does IPv6 itself give an SEO boost?

There is no public evidence that “having IPv6” gives an automatic ranking boost. Instead, IPv6 can enable the following infrastructure benefits, depending on network routing and deployment:

• better network paths on modern mobile and ISP networks
• less NAT and fewer middleboxes, which can reduce latency
• easier scaling of infrastructure (more addresses, cleaner routing)

These factors can improve user experience if they translate into lower TTFB, better LCP and higher availability. LCP is a Core Web Vital used by Google’s ranking systems; TTFB and availability are not themselves Core Web Vitals. For related performance guidance, see our article on how hosting infrastructure affects Core Web Vitals. The protocol version (IPv4 vs IPv6) is less important than the final user experience.

Practically, dual‑stack gives you the best of both worlds: IPv6 advantages where available, with IPv4 still there to avoid reachability gaps that could hurt traffic and conversions.

When IPv6‑Only Makes Sense (and When It Does Not)

Good candidates for IPv6‑only infrastructure

Several architecture patterns can be a good fit for IPv6‑only backends, provided their clients, network components and dependencies support IPv6:

• Private microservices and internal APIs: Services that are never exposed directly to the public internet, only to other servers over internal VLANs, VPNs or overlay networks.
• Container clusters and service meshes: K8s or K3s clusters where each pod gets its own IPv6 address, and a dual‑stack ingress acts as the edge. The public never sees the internal IPv6‑only design.
• Lab, test and CI environments: You can run entire staging stacks IPv6‑only, connecting to the outside world via NAT64/DNS64 or a dual‑stack gateway, and save scarce IPv4 addresses for production.
• Cost‑sensitive or address‑constrained deployments: Where obtaining additional IPv4 addresses is painful or expensive, moving more servers to IPv6‑only and keeping a small pool of dual‑stack edges is very efficient.

For more on planning IPv6 adoption, see The calm sprint to IPv6. One architecture to consider is “IPv6‑everywhere inside, dual‑stack at the edge”, subject to dependency testing.

Where pure IPv6‑only (no IPv4 edge) is risky

Going fully IPv6‑only on the public edge without any IPv4 termination creates reachability risks for:

• Customer‑facing websites and e‑commerce: IPv4‑only users without a suitable proxy cannot reach your site directly. Lost access can mean lost sales; the impact depends on your audience.
• Public SaaS apps: If a customer’s corporate network or proxy provides only IPv4 connectivity, your app may be unreachable from that organisation.
• Business email domains: IPv4‑only counterparties cannot exchange mail directly with IPv6‑only endpoints, and connectivity or configuration problems can cause delays or delivery failures.

In these cases, we strongly prefer to keep dual‑stack on the public MX and HTTP/HTTPS endpoints, even if the underlying application servers and databases are IPv6‑only.

Hosting Architecture Patterns to Evaluate

Pattern 1: Classic dual‑stack hosting (simple and robust)

This is the easiest pattern for most users:

• Choose a shared hosting account, VPS or dedicated server plan that explicitly provides both IPv4 and IPv6 connectivity.
• DNS publishes A and AAAA records for your domains.
• Your web server and mail server listen on both protocols.

Pros:

• Preserves reachability for IPv4‑only and IPv6‑capable clients when both paths are configured correctly.
• A direct dual‑stack deployment does not require a separate protocol‑bridging proxy layer, though firewall rules, logs and monitoring must cover both address families.
• Avoids excluding SEO and email tools solely because they lack IPv6 support; their other compatibility requirements still need checking.

Cons:

• Public endpoints still require IPv4 connectivity, though multiple services can share an IPv4 address.
• Less pressure to modernise internal networks and address plans.

Pattern 2: Dual‑stack edge, IPv6‑only origin

In this pattern you combine the best of both worlds:

• Public service hostnames resolve to dual‑stack TLS endpoints (reverse proxies, load balancers or WAFs) reachable over IPv4 and IPv6. These endpoints must also support IPv6 connections to the origins.
• Application servers, caches, and databases run on IPv6‑only networks behind them.

This is an architecture to evaluate for new VPS and dedicated deployments when you want to reduce backend IPv4 use while preserving public reachability. CI/CD systems, service discovery and other dependencies must support the internal IPv6 paths or have suitable proxies or translation. For a practical DNS checklist, see our guide Ready for IPv6? My no‑drama dual‑stack playbook for AAAA records and real‑world tests.

Pattern 3: IPv6‑only lab with NAT64/DNS64 for outbound

For internal labs or developer sandboxes, consider an IPv6‑only network design with:

• NAT64/DNS64 for outbound access to IPv4‑only external services such as package repositories and APIs. Test application and resolver compatibility: literal IPv4 addresses bypass ordinary DNS64 synthesis, and DNSSEC validation needs a compatible resolver arrangement.
• No public IPv4 on the lab servers except possibly a bastion or VPN endpoint; the NAT64 translator still needs IPv4 connectivity and addresses.

This can reduce IPv4 consumption while letting teams test application compatibility, IPv6‑specific firewall policies and monitoring before adopting the design in production.

A Practical Migration Roadmap

Step 1: Audit your current dependencies

Before touching DNS records, list the external systems that must reach you or that you must reach:

• Payment gateways, CRM, ERP, shipping APIs
• External SMTP relays, newsletter tools and ticketing systems
• Monitoring services and uptime checkers
• CDN or WAF providers, if used

Check which of them support IPv6 today. For critical IPv4‑only dependencies, distinguish direction: incoming clients need an IPv4‑reachable edge such as a reverse proxy or mail relay, while outbound connections need a suitable proxy, relay or NAT64/DNS64 path. A dual‑stack edge alone does not provide outbound IPv4 access for internal IPv6‑only servers.

Step 2: Enable IPv6 on your hosting or VPS

First confirm that the chosen hosting service supports IPv6 and identify its address-allocation and activation process. On shared hosting, network configuration is normally handled by the provider. For a dedicated server or colocation deployment, confirm upstream IPv6 routing and who is responsible for network equipment, host configuration and firewall policies. For a VPS with IPv6 connectivity available, the high‑level steps are:

• Assign an IPv6 address from the address or subnet allocation supplied by your provider.
• Configure the OS network settings (Netplan, NetworkManager or classic networking).
• Open the appropriate IPv6 ports in your firewall (nftables, ufw, firewalld, etc.).
• Ensure your web server and mail daemons listen on both IPv4 and IPv6.

We wrote a detailed walk‑through for this in our IPv6 setup and configuration guide for your VPS server.

Step 3: Add AAAA records and test dual‑stack

Once IPv6 connectivity is working at the OS level, test the intended web and mail services over IPv6 before publishing their AAAA records. Then:

• Add AAAA records only for hostnames whose intended services have passed IPv6 checks (for example, www, api or mail).
• Keep A records in place to preserve IPv4 reachability.
• Test from multiple networks: mobile (often IPv6‑first), home ISP, corporate VPNs.
• Use tools like ping6, traceroute6 and online IPv6 checkers for network diagnostics, and test HTTPS and mail transactions over both address families to verify service availability.

Use logs to distinguish IPv4 and IPv6 traffic, and monitor HTTP errors, connection failures and email deferrals or bounces against your baseline. IPv6 traffic volume depends on your clients and their network paths; a lack of observed traffic alone does not prove a fault. Continue external checks over both address families, since connections that fail before reaching the service may not appear in its logs. Investigate regressions rather than relying on automatic IPv4 fallback.

Step 4: Gradually move internal services to IPv6‑only

Once your public edge is dual‑stack and stable, test IPv6‑only internal components in staging, including their dependencies and a rollback path, before moving production workloads:

• New application servers with only IPv6 addresses, behind a dual‑stack reverse proxy.
• Cache servers (Redis/Memcached) and databases that live only on IPv6 networks.
• Internal APIs that you control entirely, with no public exposure.

Caching and PHP tuning remain separate performance concerns; they do not establish IPv6 compatibility. Related reading includes our guide on WordPress object caching with Redis or Memcached and the DCHost blog. Check that cache clients and other application dependencies work over IPv6 before removing IPv4.

Step 5: Revisit email and DNS after each change

Email and DNS are where subtle mistakes hurt the most. After any network or IPv6 change:

• Verify MX records still point to reachable, dual‑stack endpoints.
• Check that SPF authorizes the actual IPv4 and IPv6 sending addresses, DKIM signatures verify, and SPF or DKIM passes with alignment to the visible From domain for DMARC.
• Confirm PTR (reverse DNS) for each new sending address points to a hostname whose A or AAAA record resolves back to that address.
• Send test messages to major providers and check spam folders and headers.

Think of this as part of your regular hosting hygiene, just like your SSL/TLS updates or backup tests.

Summary: How to Decide Between IPv6‑Only and Dual‑Stack for Your Next Project

The practical recommendation is to keep public websites and business email reachable over both IPv4 and IPv6. A working dual‑stack public edge avoids excluding IPv4‑only clients; any performance benefit should be measured for your audience rather than assumed. Under the hood, application servers, caches, databases and internal APIs can move to IPv6‑only after dependency testing. Keep the traffic directions separate: incoming IPv4 traffic needs an IPv4‑reachable proxy or mail endpoint, while outbound access from IPv6‑only servers to IPv4 services needs a suitable proxy, relay or NAT64/DNS64 path. Outgoing mail also needs a delivery path to IPv4‑only recipients.

Pure IPv6‑only at the edge can be appropriate for controlled environments and internal tools, but is still too risky as the only public entry point for most businesses. For a new project or migration, use your traffic profile and dependency audit to choose the mix of IPv6‑only components and dual‑stack edges. Before choosing a hosting plan, confirm the IPv4 and IPv6 connectivity, proxy options and email arrangements that this design requires.