Contents
Why IPv6 sending is a deliberate decision
Sending email over IPv6 is not a default and not an upgrade an operator should make casually. IPv6 sending works, the major receivers accept mail over IPv6, but it comes with stricter requirements than IPv4, and an operator should send over IPv6 only if they have a reason to and are prepared to meet those requirements fully.
This guide exists to lay out exactly what IPv6 sending requires, so an operator can make the decision informed and, if they proceed, configure it correctly. The structure of this guide: why IPv6 sending is a deliberate decision, the stricter authentication scrutiny IPv6 senders face, the absolute PTR and forward-confirmed reverse DNS requirement, why SPF must authorize the IPv6 addresses, the IPv6 privacy extensions issue that must be addressed, configuring the IPv6 VMTA in PowerMTA, IPv6 reputation and warming, and the diagnostic workflow when IPv6 mail is rejected.
The key framing: there is no obligation to send over IPv6. The major receivers fully support IPv4, and continuing to send over IPv4 is a perfectly reasonable choice. IPv6 sending is for operators who have a specific reason for it and are ready to do the extra configuration thoroughly. An operator not ready to meet the IPv6 requirements should not switch to it.
The stricter scrutiny IPv6 senders face
The defining fact about IPv6 email sending is that the major receivers apply stricter scrutiny to mail arriving over IPv6 than to mail over IPv4.
The reasoning is partly historical and partly practical. IPv6's address space is vast, far larger than IPv4's, and that abundance made it easy for spammers to use fresh IPv6 addresses with no reputation history, a near-unlimited supply of clean-looking addresses. Receivers responded by requiring IPv6 senders to clearly and verifiably demonstrate legitimacy, through authentication and DNS configuration, before their mail is accepted.
| Requirement | IPv4 | IPv6 |
|---|---|---|
| PTR / FCrDNS | Strongly recommended | Effectively mandatory |
| SPF or DKIM | Required | Required, strictly checked |
| DMARC (bulk) | Required | Required |
| Tolerance for partial setup | Some | Very little |
The practical consequence is that the requirements for IPv6 sending are not simply IPv4's requirements with a different address format. They are IPv4's requirements applied more strictly, plus IPv6-specific configuration. An IPv6 sender must have valid PTR and forward-confirmed reverse DNS, must authenticate, and bulk senders need DMARC, and these are checked with less tolerance than for IPv4.
So an operator considering IPv6 sending should understand: it is not a like-for-like substitution. The bar is higher, and the configuration must be more thorough and more correct than an IPv4 setup might get away with.
The absolute PTR and FCrDNS requirement
The single most important IPv6 sending requirement is the PTR and forward-confirmed reverse DNS, because for IPv6 the major receivers treat its absence as an absolute disqualifier.
For any sending IP, receivers prefer to see a PTR record, the reverse DNS entry mapping the IP to a hostname, and forward-confirmed reverse DNS, where that hostname has a forward DNS record pointing back to the same IP. For IPv4 this is strongly recommended. For IPv6 sending to Gmail and the other major receivers, it is effectively mandatory.
Gmail's IPv6 sending guidelines are explicit:
- The sending IPv6 address must have a valid PTR record.
- The PTR hostname must have a forward DNS record, an AAAA record, pointing back to the sending IPv6 address.
Mail from an IPv6 address that does not meet this is rejected. Gmail returns a specific error referencing the IPv6 PTR requirement, the rejection text states the message does not meet IPv6 sending guidelines regarding PTR records, and the SMTP code seen for this is in the 550 5.7.x range.
For IPv6 sending, the PTR and FCrDNS setup is not a best-practice nicety, it is a precondition for the mail being accepted at all. An IPv6 sending address without a valid PTR record, or without the AAAA record completing the forward-confirmed reverse DNS, will have its mail to the major receivers rejected outright. Before sending any production mail over IPv6, the operator must arrange, with the IPv6 address provider, for each sending IPv6 address to have a PTR record pointing to a hostname, and must ensure that hostname has an AAAA record resolving back to the IPv6 address. The PTR record is set with the provider; the AAAA record is in the operator's DNS. Both halves must be in place and must agree. IPv6 sending without complete FCrDNS does not partially work, it fails at the door.
This is the first thing to set up for IPv6 sending and the first thing to verify, with a reverse lookup confirming the PTR, and a forward lookup confirming the AAAA record points back.
SPF must authorize the IPv6 addresses
SPF, which authorizes sending IPs for a domain, must explicitly authorize the IPv6 sending addresses, and this is done with IPv6-specific SPF mechanisms.
An SPF record authorizes IPv4 addresses with the ip4 mechanism. IPv6 addresses are authorized with the ip6 mechanism. An SPF record that lists only ip4 addresses does not authorize any IPv6 address, so mail sent from an IPv6 address would fail SPF.
# An SPF record concept covering both IPv4 and IPv6 senders
# v=spf1 ip4:203.0.113.0/24 ip6:2001:db8:abcd::/48 -allSo an operator switching some or all of their sending to IPv6 must update the SPF record to include the IPv6 sending addresses or ranges with ip6 mechanisms. The principle is the same as for IPv4, every sending address must be authorized by SPF, but the IPv6 addresses need ip6 entries.
The bulk sender requirement is that mail authenticates with SPF or DKIM, and for IPv6 with the strict scrutiny, the authentication must be solidly in place. The recommendation remains, as for IPv4, to ensure DKIM alignment as the robust path to DMARC, but SPF must also be correct, and for IPv6 that specifically means the ip6 mechanisms covering the IPv6 sending addresses. An IPv6 sending address missing from the SPF record is an authentication gap, and IPv6's strict scrutiny makes such a gap more likely to cause rejection.
The privacy extensions issue
There is an IPv6-specific operating-system issue that an operator setting up IPv6 sending must address: IPv6 privacy extensions.
IPv6 privacy extensions are an operating system feature that causes a host to generate temporary, changing IPv6 addresses for outbound connections. They were designed for client devices: to protect a device's privacy, the OS periodically generates new temporary IPv6 addresses, so the device is not trackable by a single persistent address. For a personal laptop or phone, that is a sensible privacy feature.
For a mail server, privacy extensions are the opposite of what is needed. A mail server's sending address must be stable, because the sending IP is:
- What carries the server's sending reputation.
- What the PTR record is configured for.
- What the SPF record authorizes.
- What the receivers recognize.
If a PowerMTA server had IPv6 privacy extensions enabled, it could send from a temporary address that has no PTR record, is not in the SPF record, and has no reputation, all of which would cause the mail to be rejected.
So on a PowerMTA server intended to send over IPv6, the operating system's IPv6 privacy extensions must be disabled. With privacy extensions disabled, the server uses only its stable, configured IPv6 addresses, the ones with PTR records, authorized in SPF, carrying the reputation. Disabling privacy extensions is an operating-system-level task, done in the OS network configuration, and it is an essential preparation step for IPv6 sending.
An operator who overlooks the privacy extensions can find IPv6 mail going out from unexpected, unconfigured temporary addresses and being rejected, and the cause is hard to spot because the sending address keeps changing. Disabling privacy extensions before sending any IPv6 mail avoids this entirely.
Configuring the IPv6 VMTA in PowerMTA
With the prerequisites in place, PTR and FCrDNS configured, SPF updated with ip6, privacy extensions disabled, the PowerMTA-side configuration for IPv6 sending is the VMTA.
An IPv6 sending address is configured in a virtual-mta block the same way an IPv4 address is, with the smtp-source-host directive, but the directive specifies the IPv6 address:
<virtual-mta mta-ipv6-1>
smtp-source-host 2001:db8:abcd::10 mail-v6.example.com
domain-key sel1,example.com,/etc/pmta/keys/dkim.pem
</virtual-mta>The smtp-source-host directive's first value is the IPv6 source address, and the second is the HELO hostname, which must match the IPv6 address's PTR record, the forward-confirmed reverse DNS hostname. The domain-key directive configures DKIM signing as for any VMTA.
The points that matter for the IPv6 VMTA:
- The IPv6 address must be configured on the server at the OS level. As with IPv4, PowerMTA can only use a source address the operating system actually has on an interface. The IPv6 address must be allocated by the provider and configured on the server.
- The HELO hostname must match the PTR. The smtp-source-host HELO must be the hostname the IPv6 address's PTR points to, the same FCrDNS consistency required for IPv4 but, for IPv6, strictly enforced.
- DKIM signing applies as normal. The IPv6 VMTA signs with DKIM the same way an IPv4 VMTA does, with the domain-key directive, signing with the sender's own domain for alignment.
Beyond using an IPv6 address in smtp-source-host, the IPv6 VMTA is configured like any other. The IPv6-specific work is the prerequisites, the FCrDNS, the SPF ip6 entries, the privacy extensions, not the VMTA block itself, which is conventional.
IPv6 reputation and warming
IPv6 sending addresses have their own reputation, separate from any IPv4 reputation, and this has implications for warming.
Sending reputation is built per sending IP, and an IPv6 address is a distinct IP from an IPv4 address. An operator who has built good reputation on their IPv4 sending addresses does not carry that reputation over to a new IPv6 address. A new IPv6 sending address starts with no reputation, just as a new IPv4 address would.
This means an IPv6 sending address needs warming. The same warming discipline that applies to a new IPv4 IP applies to a new IPv6 address: start with a low volume, increase it gradually over a period of weeks, build the reputation progressively, watch the receivers' responses, and do not jump to full volume on a cold IPv6 address.
This is an important practical point for the decision to send over IPv6. Switching to IPv6 sending is not just a configuration change, it introduces new sending addresses that must be warmed, with the time and care that warming requires. An operator switching to IPv6 should plan for the warming period, and should not expect a new IPv6 address to immediately carry the volume their established IPv4 addresses handled.
There is also IPv6-specific reputation monitoring to consider: the receivers' reputation tools, Gmail's Postmaster Tools, Microsoft's SNDS, cover IPv6 addresses, and there are IPv6-specific blocklists. An operator sending over IPv6 monitors their IPv6 addresses' reputation the same way they monitor IPv4, through the receivers' tools and blocklist checks, just with the IPv6 addresses as the subject.
When IPv6 mail is rejected
When IPv6 mail is being rejected, the diagnostic workflow:
Step 1: read the rejection. Check the accounting log for the rejection text and code. Gmail's IPv6 rejections often state explicitly that the message does not meet IPv6 sending guidelines, frequently referencing the PTR record, which points straight at the cause.
Step 2: verify the PTR record. Do a reverse lookup on the sending IPv6 address. Confirm it has a PTR record pointing to a hostname. A missing PTR is the most common IPv6 rejection cause.
Step 3: verify the forward-confirmed reverse DNS. Take the hostname from the PTR and do a forward lookup, confirm it has an AAAA record pointing back to the sending IPv6 address. A PTR without the matching AAAA is an incomplete FCrDNS and causes rejection.
Step 4: check SPF for the IPv6 address. Confirm the SPF record includes the IPv6 sending address via an ip6 mechanism. An IPv6 address missing from SPF fails authentication.
Step 5: check for privacy extensions. Confirm IPv6 privacy extensions are disabled on the server, and that the mail is actually going out from the configured, stable IPv6 address, not a temporary one. If the sending address in the accounting log is not the configured address, privacy extensions are the likely cause.
Step 6: verify the HELO matches the PTR. Confirm the VMTA's HELO hostname matches the IPv6 address's PTR hostname. A mismatch is a legitimacy-signal failure.
Step 7: check DKIM and DMARC. Confirm DKIM is signing and aligning. IPv6's strict scrutiny means authentication must be fully correct.
Step 8: consider reputation and warming. If the configuration is all correct but the IPv6 mail is still being throttled or filtered, the IPv6 address may simply be cold, a new IPv6 address without reputation, and needs warming.
An operator we worked with decided to move some of their sending to IPv6. They did a fair amount of the setup correctly: they got IPv6 addresses from their provider, configured them on the server, set up the IPv6 VMTAs in PowerMTA with smtp-source-host pointing at the IPv6 addresses, and updated their SPF record with ip6 mechanisms for the new addresses. They also arranged PTR records for the IPv6 addresses with their provider. Then they started sending over IPv6, and the mail to Gmail was rejected, essentially all of it. The accounting log showed Gmail rejecting the IPv6 mail with a message stating it did not meet Gmail's IPv6 sending guidelines regarding PTR records. The operator was confused, because they had set up PTR records, they had specifically asked their provider to configure reverse DNS for the IPv6 addresses, and the provider had done so. We checked, and the PTR records were indeed there, a reverse lookup on the IPv6 addresses returned hostnames. But the forward-confirmed reverse DNS was incomplete. Gmail's IPv6 requirement is not just that the IPv6 address has a PTR record, it is that the PTR hostname has an AAAA record pointing back to the sending IPv6 address, the full forward-confirmed reverse DNS loop. The operator had set up the PTR, the reverse half, but had not created the AAAA records, the forward half, for the hostnames the PTRs pointed to. So the reverse lookup worked but the forward confirmation failed: the hostname did not resolve back to the IPv6 address. For IPv4, some receivers might have tolerated this; for IPv6, Gmail did not, and rejected the mail. The fix was to add AAAA records in their DNS for the PTR hostnames, each AAAA record pointing back to the corresponding sending IPv6 address, completing the forward-confirmed reverse DNS. Once the AAAA records were in place and propagated, a forward lookup on the PTR hostnames resolved back to the IPv6 addresses, the FCrDNS was complete, and Gmail accepted the IPv6 mail. The lesson is that IPv6 sending has a strict, complete requirement: PTR and forward-confirmed reverse DNS, both halves. Setting up the PTR record is only half of it; the PTR hostname must also have an AAAA record resolving back to the IPv6 address. IPv6's strict scrutiny means an incomplete FCrDNS, which IPv4 might forgive, causes outright rejection. An operator switching to IPv6 must verify the full loop, reverse lookup gives the hostname, forward lookup on that hostname gives back the IPv6 address, before sending production mail, because IPv6 sending with a half-configured FCrDNS fails at the door.
Sending email over IPv6 is a deliberate decision, not a default, because IPv6 carries stricter requirements than IPv4 and should be undertaken only by an operator prepared to meet them fully. The major receivers apply stricter scrutiny to IPv6 mail, a response to the abundance of IPv6 addresses available to spammers, so IPv6's requirements are IPv4's applied more strictly plus IPv6-specific work. The absolute requirement is complete PTR and forward-confirmed reverse DNS: every IPv6 sending address must have a PTR record, and the PTR hostname must have an AAAA record resolving back, or the mail is rejected at the door. SPF must authorize the IPv6 addresses with ip6 mechanisms, the operating system's IPv6 privacy extensions must be disabled so the server sends only from stable configured addresses, and the PowerMTA IPv6 VMTA, conventional apart from using an IPv6 address in smtp-source-host, must use a HELO matching the PTR. New IPv6 addresses carry no reputation and need warming like any new IP. Operators who do the full IPv6 preparation, complete FCrDNS, ip6 SPF entries, disabled privacy extensions, and warming, can send over IPv6 successfully; operators who treat IPv6 as a like-for-like swap for IPv4, as the case shows, find IPv6's strict scrutiny rejecting mail that a half-configured setup would have gotten away with on IPv4. And an operator not ready for that work can simply continue on IPv4, which the receivers fully support.