IPv6 adoption is accelerating. Major providers and hosting platforms have enabled it by default for years. If you're running email infrastructure, there's a good chance you're already sending mail over IPv6, whether you know it or not.
The problem: IPv6 reputation and blacklisting work differently than IPv4, and most RBL monitoring setups are still IPv4-only. Adding IPv6 without updating your monitoring creates blind spots. You can be listed on an IPv6 blacklist, lose deliverability, and never know why.
How IPv6 Reputation Differs from IPv4
In IPv4, reputation is tied to specific /32 addresses (individual IPs) or /24 blocks (256 addresses). When you send mail from 203.0.113.45, that specific address builds a reputation. If it gets blacklisted, you know exactly which IP is affected.
IPv6 uses /64 and /48 allocation. A single organization might have a /48 (280 trillion addresses). Sending mail from a specific IPv6 address doesn't build the same kind of focused reputation that IPv4 does. Instead, mailbox providers and blacklists track reputation at the /64 or /48 level.
This has consequences:
New IPv6 addresses start with zero reputation. In IPv4, you can sometimes benefit from the prior reputation of an IP if the previous owner was a legitimate sender. In IPv6, most addresses have never sent mail before. You start cold.
Warming up IPv6 is different. You can't just switch from IPv4 to IPv6 overnight and expect the same deliverability. IPv6 addresses need their own warm-up process: start with low volume to engaged recipients, ramp up gradually, and build positive engagement history.
Shared /64 blocks pool reputation. If multiple senders share a /64 (common in hosting environments), one bad actor can damage the reputation of the entire block. This is similar to shared IPv4 pools, but the scale is different. A /64 is 18 quintillion addresses. Blacklisting an entire /64 affects far more potential senders than blacklisting a /24.
How IPv6 Blacklisting Works
Most DNS-based blacklists (DNSBLs) were designed for IPv4. IPv6 support was added later, and not all lists handle it the same way.
Some lists blacklist individual /128 addresses (the IPv6 equivalent of a single /32 IPv4 address). This is rare. It's impractical to maintain granular listings at /128 scale.
Most lists blacklist /64 or /48 blocks. If one address in the block is flagged for spam, the entire block gets listed. This is efficient for blacklist operators, but it means collateral damage is common.
Some lists don't support IPv6 at all. Older RBLs were built for IPv4 and never updated. If your monitoring only checks lists that support IPv4, you're missing IPv6-specific listings.
When you query a DNSBL for an IPv6 address, the lookup format is different from IPv4. Instead of reversing octets, you reverse each nibble (hexadecimal digit) of the full 128-bit address. For example:
2001:db8::1 becomes:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.dnsbl.example.com
Most monitoring tools abstract this complexity, but it's worth understanding that IPv6 DNSBL queries are structurally different. If your monitoring tool doesn't explicitly support IPv6, it's not checking these lookups.
Common Monitoring Gaps
Monitoring only IPv4 while sending from both IPv4 and IPv6. Many organizations enable IPv6 on their mail servers but never update their RBL monitoring to check IPv6 addresses. They're blind to IPv6 listings.
Assuming IPv6 listings are rare. They're not. Spammers use IPv6. Compromised servers send spam over IPv6. Blacklists track IPv6 abuse just as actively as IPv4.
Not monitoring all IPv6 addresses in your allocation. If you have a /64 or /48, you might send from multiple addresses within that block. You need to monitor the addresses you're actually using, not just one representative address. Some blacklists list the entire block, others list specific addresses within it.
Not checking IPv6-specific blacklists. Some RBLs focus exclusively on IPv6 abuse. If you're only checking general-purpose blacklists, you're missing IPv6-specific listings.
What to Monitor
If you send mail over IPv6, monitor:
- All IPv6 addresses your mail servers use. Check your MTA configuration and DNS records. If you're using multiple outbound addresses (round-robin, load balancing, etc.), monitor all of them.
- Your IPv6 /64 or /48 allocation. Some blacklists list entire blocks. Query for your network prefix, not just individual addresses.
- IPv6-capable RBLs. Not all blacklists support IPv6. Verify that the lists you're checking actually handle IPv6 lookups. Major lists like Spamhaus, Barracuda, and Sorbs support IPv6. Smaller or older lists may not.
- IPv6-specific blacklists. Some lists focus exclusively on IPv6. Examples:
b.barracudacentral.org(supports both),all.s5h.net(IPv6-aware).
Blacklist Monitoring supports both IPv4 and IPv6 addresses. You can monitor specific addresses or entire blocks, and the system handles the complexity of IPv6 DNSBL lookups automatically. For hosts configured with both IPv4 and IPv6, the IPv6 Hosts documentation explains how to set up dual-stack monitoring.
Reputation Bootstrapping for New IPv6 Addresses
When you add IPv6 to your mail infrastructure, treat it like a new sending IP:
- Start with low volume. Don't immediately send your full mail volume over IPv6. Begin with a small percentage (5-10%) of your most engaged recipients.
- Ramp up gradually. Increase volume incrementally over 2-4 weeks. Monitor bounce rates, complaint rates, and deliverability.
- Maintain consistency. Don't send sporadically. Consistent sending patterns build trust.
- Monitor engagement. High open rates and low complaint rates signal to mailbox providers that your IPv6 address is legitimate.
- Use both IPv4 and IPv6 in parallel. Dual-stack sending (sending from both IPv4 and IPv6 simultaneously) lets you build IPv6 reputation without losing IPv4 deliverability. Most modern MTAs support this.
If your IPv6 address gets blacklisted during warm-up, identify the cause (complaint rate, spam trap hit, compromised server, etc.), fix it, and request delisting. Don't ignore it and assume IPv4 will carry you.
Dual-Stack Monitoring is Not Optional
If you're sending mail over both IPv4 and IPv6, you need to monitor both. A listing on one address family can affect deliverability even if the other is clean. Some recipients only accept mail over IPv6. If your IPv6 address is listed, those messages fail, and you won't see it in your IPv4 monitoring.
Check your mail server logs. Look for AAAA record lookups and IPv6 connections. If you see them, you're sending over IPv6. If you're not monitoring IPv6 addresses, you're flying blind.
Set up monitoring for both address families, track reputation separately, and warm up IPv6 with the same care you'd give a new IPv4 address. IPv6 is not a secondary concern. It's part of your infrastructure, and it needs the same level of visibility and control.