Reverse DNS in IPv6 (RFC 8501) and Email

If you send mail over IPv6, each sending address needs reverse DNS that matches its forward DNS, yet the IPv4 habit of creating a PTR record for every address in advance becomes mathematically impossible. RFC 8501, Reverse DNS in IPv6 for Internet Service Providers (November 2018, Informational), analyzes how operators can populate ip6.arpa instead. Mail is its headline use case, because SMTP is where missing or mismatched reverse DNS actually blocks traffic.

Why per-address PTR breaks at IPv6 scale

• In IPv4, an Internet service provider (ISP) with a /24 writes 256 PTR records, often generated automatically, and moves on. Forward and reverse DNS match, which satisfies the expectation in RFC 1912 that "every Internet-reachable host should have a name" whose forward and reverse entries agree.
• A single IPv6 /64 (one LAN) contains 2^64 addresses, and a customer /48 contains 2^80. RFC 8501 does the arithmetic: at 1,000 zone-file entries written per second, populating one /48 "would still not be complete after 38 trillion years."
• Hosts also assign their own addresses, through stateless address autoconfiguration (SLAAC) and privacy addresses that rotate. The operator often does not know which addresses are in use, so even selective pre-population cannot keep up with reality.

An IPv6 operator must therefore choose a strategy other than static PTR records for every address. For an email service provider (ESP), this is also a question of sending infrastructure. Every IPv6 address you send mail from needs correct, matching reverse DNS (see what receivers expect, below), and the rest of your address space needs a deliberate policy.

The RFC 8501 option catalog

RFC 8501's conclusion: "When address assignment and name are under the same authority, or when a host has a static address and name, AAAA and PTR records should exist and match." For everything else, such as residential pools, the realistic choices are wildcards, negative responses (where nothing needs a PTR), or on-the-fly generation.

What mail receivers expect (FCrDNS)

• The RFC states it plainly: "most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match". This is forward-confirmed reverse DNS (FCrDNS): the PTR for the connecting address returns a name, and the AAAA (or A) record of that name includes the connecting address.
• Only options 3 (DDNS), 4 (on-the-fly) and 5 (delegation) can produce matching pairs. Wildcards and NXDOMAIN cannot. A mail source behind a wildcard or an empty reverse zone will be rejected or heavily penalized.
• Gmail is the model of enforcement on IPv6. Sending hosts must have a PTR whose forward lookup confirms the IP, and must also pass authentication, or mail is rejected with IPv6-specific 550 5.7.1 errors (listed in Gmail SMTP Troubleshooting, with the requirements in Gmail Sender Requirements). Receivers generally apply stricter rules on IPv6 than on IPv4, because reputation per IP is diluted across the huge address space. See IPv6 Sending for sending policy as a whole.
• PTR names that look generic or synthetic (for example, 2-2-2-2.pool6.example.net) signal "not a deliberate mail server," so receivers also use the naming of PTR records as a spam heuristic. Guidance from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), cited by NIST SP 800-177 (summary), says that reverse trees should identify the authoritative mail servers for a domain.

Security and privacy considerations (RFC 8501 §5)

• Matching records do not mean trust. An attacker who controls their own reverse zone can easily make forward and reverse DNS agree, and without DNSSEC the answers can be spoofed in transit. Treat FCrDNS as a minimum standard of hygiene, not as authentication. SPF, DKIM and DMARC provide authentication.
• DNSSEC interactions: records that are added dynamically or synthesized complicate signing (the cost of live signing, and key exposure on online signers). Unsigned reverse zones are increasingly read as a signal of reduced trust.
• Privacy: hostnames that encode a location or a subscriber's identity leak information (RFC 8117). Hostnames supplied by users risk offensive or abusive content.
• Denial-of-service surface: DDNS update channels need authentication and rate limits, and on-the-fly generators must limit their state and cache size.

Operational checklist for an ESP running IPv6 mail infrastructure

1. Every IPv6 address that sends SMTP gets a static, descriptive PTR that passes FCrDNS (mtaN.esp.example, with a matching AAAA record), provisioned like a production asset. Use the "static records" option, never wildcards.
2. Decide the policy for the rest of your allocations, the part that sends no mail. NXDOMAIN is clean and honest. Never let a wildcard cover address space that could originate SMTP.
3. Before the first send, confirm that your upstream provider or local Internet registry (LIR) delegates ip6.arpa for your prefix to your name servers (typically on nibble boundaries: /32, /36, ... /48, /56, /64).
4. Sign the reverse zone with DNSSEC if you can. This is consistent with the authentication posture in NIST SP 800-177, and receivers that care about security expect it.
5. Keep PTR names consistent with the forward branding you use in HELO and EHLO. Receivers compare the HELO, PTR and certificate names when they score a connection (see Sending Infrastructure Practices).
6. When you troubleshoot a sudden rejection such as 550 5.7.1 that cites an IPv6 address, check FCrDNS for that specific address first. The classic cause is an app server that started sending mail over IPv6 from rotating privacy addresses. Then check authentication alignment. The broader dual-stack strategy is covered in IPv6 Sending.