Sending Email over IPv6

Source: M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts (M3AAWG084, September 2014). Note the age: this is a 2014 position/requirements paper, written as "an initial list of requirements for future services," not an operational how-to. Its core predictions have held — major receivers (notably Gmail) do require valid PTR and passing authentication on IPv6 connections — but treat specific institutional references (e.g., the IETF WEIRDS working group, since completed as RDAP) as historical.

The core problem: IP reputation does not scale to IPv6

• IPv4 anti-abuse relies on per-address (/32) reputation: rate limiting, blocklisting, reputation assessment. Less stable and reliable than one would prefer, but workable — and "most anti-spam systems will be unable to function if the effectiveness of these mechanisms are degraded."
• IPv6's /128 address space breaks this: tracking every /128 is impractical at scale, and a sender able to emit each individual email from a unique /128 renders per-address mechanisms ineffective.
• The advent of IPv6 therefore makes domain-based reputation (with or without an associated IP) essential, along with improved address-aggregation mechanisms.

M3AAWG's three goals for IPv6 mail: aggregate the address space into trackable assignments; require operators to identify hosts intended to act as outbound MTAs; require a valid domain-authentication-based identifier for reputation assessment.

Recommendation 1 — track and action aggregate assignments, not /128s

• IP-based mechanisms (connection rate limiting, blocklisting) must aggregate a sufficiently large IPv6 range into a single entity to remain effective; too large a range causes false positives by lumping unrelated actors' MTAs together.
• Ideally ISPs would publish their aggregation sizes via a standard open service that anti-spam mechanisms could query; absent that, conventions on common aggregation boundaries suffice.
• Initial heuristic: use /64 as the minimum default assignment size (per RFC 4291, the first 64 bits identify routing prefix and subnet, the second 64 the interface; a single interface is unlikely to contain MTAs of multiple significant-volume actors). Operators may act on larger or smaller ranges where appropriate; anti-spam vendors are expected to collect assignment-size data as part of their services.

Sender implication: the whole /64 (or larger block) shares fate. Reputation damage from one host, or one ESP customer, can blocklist the entire aggregate. Segment IPv6 sending by allocating distinct /64s per stream/customer class, mirroring IP-allocation practice.

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

• Botnets emit abuse from compromised hosts whose owners never intended them to be MTAs; limiting acceptance to explicitly authorized sources greatly devalues compromised hosts. Outbound port-25 management (MAAWG Port 25 recommendation) helps but is not universally implemented, and IoT will dramatically grow the population of vulnerable devices.
• No standard existed for operators to declare 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, automatically queryable, IP-keyed method (nothing broadly adopted since).
• Interim mechanism: reverse DNS. Many operators already reject or treat as highly suspicious IPv4 connections without PTR records; under IPv6 this is an even more effective high-pass filter, because operators will not publish PTR for the vast majority of their IPv6 space (little benefit, cumbersome at that scale) while the small set of dedicated relay hosts can feasibly have PTR maintained.
• "In the absence of a more appropriate mechanism … M3AAWG recommends rejecting email from host IPv6 addresses without reverse DNS records" — to be deprecated once a better standard exists (none has displaced it).

Sender implication: every IPv6 sending address must have a PTR record, and (per general receiver practice) matching forward confirmation. Missing PTR on IPv6 is grounds for outright rejection, not just suspicion.

Recommendation 3 — reject mail without valid domain authentication

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

Sender implication: on IPv6, unauthenticated mail is not merely penalized — the industry position is that it should be rejected. This is exactly the behavior Gmail and other majors adopted for IPv6 connections (see Gmail Sender Requirements: IPv6 delivery requires PTR and SPF-or-DKIM pass). Never send over IPv6 from a stream whose SPF/DKIM is not fully in order; when enabling IPv6 on an MTA, verify authentication first or expect hard bounces that the same stream would not see on IPv4.

Accountable domains

WHOIS accuracy is "a critical component of a domain's reputation"; complete WHOIS for domains acting as SMTP clients should be mandatory, with working abuse contacts. (The paper points to the IETF WEIRDS working group's WHOIS replacement — delivered as RDAP.)

Practical summary for an ESP (2014 doc, current practice)

2014 recommendation	Current operational reality
Aggregate reputation at /64 minimum	Receivers and DNSBLs list IPv6 at /64 granularity; plan allocations accordingly
Reject IPv6 mail without PTR	Enforced by major receivers; PTR + forward-confirm mandatory
Reject IPv6 mail failing SPF and lacking valid DKIM	Enforced by Gmail on IPv6 since mid-2010s; assume everywhere
Domain reputation over IP reputation	The general direction of all modern filtering

Because IPv6 tolerance for authentication mistakes is near zero and dual-stack delivery makes failures intermittent (mail sometimes routed v6, sometimes v4), many ESPs still deliberately prefer IPv4 for outbound marketing mail, or enable IPv6 only on streams with proven-clean authentication. Related: Sending Infrastructure Practices · SPF · DKIM.