Sending Email over IPv6

If you plan to send mail over IPv6, expect receivers to apply stricter rules than on IPv4: a PTR record and passing authentication are effectively mandatory. The basis for those rules is a paper from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts (M3AAWG084, September 2014).

Note its age. It is a position and requirements paper from 2014, written as "an initial list of requirements for future services", not an operational guide. Its core predictions have held: major receivers, notably Gmail, do require a valid PTR and passing authentication on IPv6 connections. Treat its specific references to institutions as historical, for example the IETF WEIRDS working group, whose work has since been completed as RDAP.

The core problem: IP reputation does not scale to IPv6

• IPv4 anti-abuse relies on reputation for each address (/32): rate limiting, blocklisting and reputation assessment. It is less stable and reliable than one would like, but it works, and "most anti-spam systems will be unable to function if the effectiveness of these mechanisms are degraded."
• The /128 addresses of IPv6 break this. Tracking every /128 is impractical at scale, and a sender that can send each individual email from a unique /128 makes mechanisms based on single addresses ineffective.
• IPv6 therefore makes domain-based reputation essential (with or without an associated IP), together with better mechanisms for aggregating addresses.

M3AAWG set three goals for IPv6 mail: aggregate the address space into assignments that can be tracked; require operators to identify the hosts meant to act as outbound mail transfer agents (MTAs); and require a valid identifier based on domain authentication for reputation assessment.

Recommendation 1: track and act on aggregate assignments, not /128s

• IP-based mechanisms (connection rate limiting, blocklisting) must treat a large enough IPv6 range as a single entity to remain effective. A range that is too large causes false positives, because it lumps together the MTAs of unrelated actors.
• Ideally, Internet service providers (ISPs) would publish their aggregation sizes through a standard open service that anti-spam mechanisms could query. Without one, conventions on common aggregation boundaries are enough.
• Initial heuristic: use /64 as the minimum default assignment size. Under RFC 4291, the first 64 bits identify the routing prefix and subnet and the second 64 bits identify the interface, and a single interface is unlikely to contain the MTAs of several actors with significant volume. Operators may act on larger or smaller ranges where appropriate, and anti-spam vendors are expected to collect data on assignment sizes as part of their services.

What this means for senders: the whole /64 (or larger block) shares the same fate. Reputation damage from one host, or from one customer of an email service provider (ESP), can get the entire aggregate blocklisted. Segment IPv6 sending by allocating a separate /64 to each stream or class of customer, as in IP allocation practice.

Recommendation 2: reject mail from hosts not identified as outbound MTAs

• Botnets send abuse from compromised hosts whose owners never meant them to be MTAs, so accepting mail only from explicitly authorized sources greatly reduces the value of compromised hosts. Managing outbound port 25 (the MAAWG Port 25 recommendation) helps, but it is not implemented everywhere, and the Internet of Things (IoT) will greatly increase the number of vulnerable devices.
• No standard existed for operators to declare which hosts are intended outbound MTAs. SPF identifies a domain's authorized outbound MTAs, but "also permits malicious domain owners to identify large ranges of IP space that they do not actually own." M3AAWG called for a standardized method, keyed on IP address, that could be queried automatically. Nothing has been broadly adopted since.
• The interim mechanism is reverse DNS. Many operators already reject IPv4 connections without PTR records, or treat them as highly suspicious. Under IPv6 this is an even more effective high-pass filter, because operators will not publish PTR records for the vast majority of their IPv6 space (the benefit is small, and it is cumbersome at that scale), while PTR records can feasibly be maintained for the small set of dedicated relay hosts.
• "In the absence of a more appropriate mechanism … M3AAWG recommends rejecting email from host IPv6 addresses without reverse DNS records", until a better standard exists (none has replaced it).

What this means for senders: every IPv6 sending address must have a PTR record and, as receivers generally expect, a matching forward confirmation. A missing PTR on IPv6 is grounds for outright rejection, not only for suspicion.

Recommendation 3: reject mail without valid domain authentication

• The need for stable, accurate reputation identifiers is even greater under IPv6 than under IPv4, and domain names are considerably more stable than IP addresses, even in IPv4.
• DKIM and SPF provide the authenticated domain for accountability: the d= value of DKIM, and the envelope MAIL FROM domain of SPF (or the EHLO or HELO domain for bounces). Large providers had already deployed domain reputation alongside IP reputation.
• "M3AAWG therefore recommends moving toward rejecting email that does not contain a valid DKIM signature or that does not pass SPF checks", which enables consistent, reliable reputation based on the authenticated domain for delivery decisions.

What this means for senders: on IPv6, unauthenticated mail is not only penalized; the industry position is that it should be rejected. This is exactly what Gmail and other major providers adopted for IPv6 connections (see Gmail Sender Requirements: delivery over IPv6 requires a PTR record and a pass on SPF or DKIM). Never send over IPv6 from a stream whose SPF and DKIM are not fully in order. When you enable IPv6 on an MTA, verify authentication first, or expect hard bounces that the same stream would not get on IPv4.

Accountable domains

Accurate WHOIS information is "a critical component of a domain's reputation". Complete WHOIS records should be mandatory for domains that act as SMTP clients, with working abuse contacts. (The paper points to the WHOIS replacement from the IETF WEIRDS working group, which was delivered as RDAP.)

Practical summary for an ESP (the 2014 paper and current practice)

IPv6 leaves almost no tolerance for authentication mistakes, and dual-stack delivery makes failures intermittent (mail is sometimes routed over IPv6 and sometimes over IPv4). For these reasons, many ESPs still deliberately prefer IPv4 for outbound marketing mail, or enable IPv6 only on streams whose authentication is proven clean.

Related articles

• Sending Infrastructure Practices
• SPF
• DKIM