IPv6 reverse DNS for mail servers: PTR setup and HELO matching

A mail server's IPv6 address needs a working PTR record that resolves to a hostname, and that hostname needs to resolve forward back to the same address. This is forward-confirmed reverse DNS (FCrDNS), and on IPv6 it is more often missing than on IPv4 because the delegation path is less familiar and many hosting providers do not expose it by default.

Why this specifically breaks on IPv6

On IPv4, your hosting or cloud provider typically owns the reverse zone and lets you set a PTR through a control panel with one field. On IPv6, the reverse zone is ip6.arpa, addressed as a nibble-reversed hex string, and many providers either do not delegate it at all for smaller allocations or require a support ticket instead of a self-service panel. If you add an AAAA record to your mail server and start sending without confirming the provider has actually delegated the matching ip6.arpa zone, you will get silent rejections or heavy spam-folder placement with no obvious misconfiguration in your own DNS.

Checking what you have today

Start by reversing the address into its nibble form and querying the PTR record directly.

$ dig -x 2001:db8:a:b::25 +short
mail.example.com.

$ dig AAAA mail.example.com +short
2001:db8:a:b::25

$ dig PTR $(python3 -c "import ipaddress; a=ipaddress.IPv6Address('2001:db8:a:b::25'); print('.'.join(reversed(a.exploded.replace(':','')))+'.ip6.arpa')") +short

If the first dig -x returns nothing, the provider has not delegated your reverse zone, and no amount of forward DNS work will fix it - you need to open a ticket with whoever allocated the IPv6 block.

Matching the HELO banner

Gmail, Outlook and most receivers cross-check three things on connection: the PTR hostname, the HELO/EHLO string your MTA announces, and the forward A/AAAA record for that hostname. They do not need to be identical, but the HELO hostname should resolve to the connecting IP, and ideally match or closely relate to the PTR hostname. A mismatch - HELO announcing mta3.internal.corp while the PTR says mail.example.com - is a common and avoidable trigger for suspicion scoring, even though it is not technically a hard SMTP violation.

$ telnet mail.example.com 25
220 mail.example.com ESMTP ready
EHLO mta3.internal.corp
250-mail.example.com Hello mta3.internal.corp
...

Here the PTR and the forward record both say mail.example.com, but HELO announces an unrelated internal name. Fix this in the MTA configuration (Postfix: smtp_helo_name; Exim: primary_hostname) so the announced name matches the PTR.

A working checklist before you enable IPv6 sending

Run this for every IPv6 address or range you intend to send from, not just the first one you provisioned - it is common for a /64 allocation to have PTR delegation working for one test address and silently missing for the rest of the range if delegation was set up manually rather than as a wildcard.

A wildcard PTR covering the whole delegated range is the more reliable setup for any sender that rotates or scales across multiple addresses within the same prefix, since it removes the risk of a newly provisioned address going live with no reverse record at all. Ask the provider specifically whether they support wildcard delegation for the block before committing to a manual, per-address setup that someone has to remember to repeat every time a new address is added.

What not to do

Do not rely on a provider's claim that "IPv6 is supported" without testing the actual PTR chain yourself; "supported" sometimes means the network routes IPv6 traffic, not that reverse DNS delegation was configured. Do not use a generic or shared PTR hostname across multiple unrelated sending domains on the same /64 - mailbox providers increasingly treat the PTR hostname as a reputation anchor, and a shared one pools your reputation with whatever else is on that prefix. And do not skip SPF: a passing PTR/HELO check does not substitute for SPF alignment, which many filters weight more heavily for the actual accept/reject decision.

Where MailPilot fits

MailPilot checks SPF, DKIM and DMARC on the domains you connect, so a missing ip6: mechanism in your SPF record gets flagged before it starts failing alignment on IPv6 traffic. Mailboxes are warmed gradually with per-mailbox reputation tracked daily, which is the signal that tells you whether a new IPv6 PTR and HELO configuration is actually landing in the inbox rather than just passing a syntax check.