Home / Blogs

Fine Grained Mail Filtering With IPv6

One of the hottest topics in the email biz these days (insofar as any topic is hot) is how we will deal with mail on IPv6 networks. On existing IPv4 networks, one of the most effective anti-spam techniques is DNSBLs, blackists (or blocklists) that list IP addresses that send only or mostly spam, or whose owners have stated that they shouldn’t be sending mail at all. DNSBLs are among the cheapest of anti-spam techniques since they can be applied to incoming mail connections without having to receive or filter spam. On my system about 85% of incoming IPv4 mail connections are handled by DNSBLS, and I gather that number is pretty typical.

On IPv6, DNSBLs can’t work the same way.

The problem is that the IPv6 address space is much, much larger. The IPv4 address space has 232 (4 billion) addresses of which maybe half are in use. Two billion is a lot of data for people, but not a big deal these days for computers, so large mail systems track every IP address that sends mail and has an opinion (the jargon word is reputation) about what kind of mail each IP sends.

IPv6, on the other hand, has 128 bit addresses. Usually each individual network, such as a home LAN or a single customer at a hosting provider, is assigned a 64 bit prefix, which means that each LAN has 264 addresses, way too many to track individually on any plausible computers. On the assumption that all of the 264 addresses are under the same control, a common plan for DNSBL operators is to disregard the low 64 bits of an address and just filter on the high half. Unfortunately, that doesn’t really help, for two reasons. One is that even the remaining addresses are way too big to track. Currently there is about 53 bits allocated IPv6 networks (disregarding the low bits), and 253 of anything is still way too big to track. The other is that some hosting providers have ignored the standard configuration advice, and have put multiple customers in the same 64-bit LAN, so the 64 bit rule will treat all those customers as one. (The providers claim their routers made them do it.)

The thinking is that since IPv4 mail will continue to work for a very long time, we can be pickier about IPv6 mail and only accept it if it has DKIM signatures or otherwise makes itself easy to recognize. While I expect I’ll be doing that, it occurs to me that the vast IPv6 address space offers senders and receivers a lot more finegrained whitelist and blacklist opportunities than we had before.

If I were providing public mail server like Gmail or Yahoo or Hotmail, there’s plenty of bits to give every user a unique IP in a single /64. A recipient can treat the whole /64 as a unit, or if they want, they can track individual addresses, maybe all of them, or maybe just ones that come to their attention via spam complaints or the like. Recipients can use IP addresses to block mail from senders with a bad history, or maybe slow it down, or send it to different servers.

For ESPs (bulk mail service bureaus), we can add an extra level and assign IP bits both to users and mail campaign per user, perhaps like this:


The high 64 bits is the network number, same as any other IPv6 address. The low half has 8 spare high order bits for future cleverness, 40 bits of user (a trillion users per provider should be enough), and 16 bits to identify the campaign. If you want to handle one campaign specially, block, delay, or reroute or whatever, it has a unique IP. If you want to handle all of the user’s mail specially, just ignore the low 16 bits and do something with that user’s block of IPs.

Maybe this particular bit setup isn’t ideal, but it’s definitely worth thinking about what to do with all those address bits, beyond ignoring most of them and recreating techniques from IPv4.

By John Levine, Author, Consultant & Speaker

Filed Under


The cost of fragmenting IP addresses per campaign Alessandro Vesely  –  Jan 29, 2014 10:06 AM

It is worth recalling the underlaying cost of using several addresses.  It forces an ESP to set up a sending strategy that is compatible with the user/campaign classification.  TCP and TLS connections cannot be kept alive across an IP change, so the latter might be seen as an overkill with respect to an (authenticated) originator email address change.

Besides technicalities, marketing campaigns —differently from discussion lists— tend to be short lived operations for some specific purpose.  The 16 bit campaign code has to match a moving target.  The difficulty of treating such identifier is similar to that of managing subscriptions.  A prospect buyer cannot subscribe to a campaign for the launch of a product that did not exist before, and a generic new products label is too broad of a mail stream identifier to be useful.  Perhaps, it would make sense to use something like the Global Industry Classification Standard codes, which would be independent of the issuing ESP.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix


Sponsored byDNIB.com


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global