IPv6 and PTR

I'm not able to email a Google gmail address. The bounce says I don't have a PTR. A closer look and its related to my IPv6 address.
I'm in charge of hosting the domain sending and it has a full set of DMARC, DKIM and SPF records. I don't remember ever setting a PTR and the closest thing seems to be on my Zen Internet control centre, but that only relates to my IPv4 addresses.

So do I need to create a new DNS record for PTR with the IPv6 address? I have full access to the DNS Zone using cPanel.

Thanks

Hi

I've had the same with ipv6 on my A&A and Zen connections, had to setup reverse dns for the ipv6 address my email server had before google would accept email from it. I used to be with Zen and had to email the ipv6 team to get the PTR setup.

Regards

Andrew

In reply to a post by andew:

I've had the same with ipv6 on my A&A and Zen connections...

Thanks Andrew, I've already emailed Zen support.
What I don't understand is how this rDNS record works. How is Google accessing it when my DNS Zone for this domain is 'elsewhere'. The NS record points to a host where the cPanel is. Nothing there points to Zen. I clearly don't understand (despite googling!) how this record works, if its different from the others.

Meanwhile I was able to send an email to gmail but looking at the headers it went via IPv4. The previous bounces specifically quoted my IPv6.

And/or... do I need an AAAA record?

Thanks

PTR records are set on your IP address, they're nothing to do with your domain.

For your IPv6 record your best bet is to ask Zen to delegate your allocation to a set of name servers that you control.

In reply to a post by jpm:

PTR records are set on your IP address, they're nothing to do with your domain.

OK, thanks. So a lookup for my domain gets sent to the namesever I've chosen. But a lookup for an IP gets sent to the owner of that address, in this case Zen?

Penny slowly making its way...

Technically a lookup for your domain goes to the root servers and then Nominet (for a .uk domain) and then they hold the record of which name server should answer the request.

Similarly a lookup on your IP goes to the root servers, then IANA, then RIPE, then your ISP and then to you if you have a delegation set up.

PTR lookups are done using special domains, which are delegated via the registries to the owners of the IP address space.

For IPv4, a PTR lookup for IP address 1.2.3.4 looks up the following name in the DNS:

4.3.2.1.in-addr.arpa.

For IPv6, a PTR lookup is under the domain "ip6.arpa". This is the address broken into hex nybbles and reversed. For example, a lookup for address 2001:db8::1 actually looks for

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Google's mail acceptance policies are mad. Google seem to think that setting these ridiculous bars will reduce the amount of spam, when in fact spammers are experts in mail delivery and are better at jumping through these hoops than most people.

It's typically better to configure your mail server to use only IPv4 for outgoing connections (even thought that means it's going through your NAT)

In reply to a post by candlerb:

Google's mail acceptance policies are mad.

Fully agree, and they also apply to companies using Google Workspace accounts, as well as free GMail accounts. Unfortunately Google’s email service a) works, and b) consumers like it, so they think they can get the rest of us to jump through their hoops!

In reply to a post by Woolwich:

I'm not able to email a Google gmail address. The bounce says I don't have a PTR. A closer look and its related to my IPv6 address.
I'm in charge of hosting the domain sending and it has a full set of DMARC, DKIM and SPF records. I don't remember ever setting a PTR and the closest thing seems to be on my Zen Internet control centre, but that only relates to my IPv4 addresses.

So do I need to create a new DNS record for PTR with the IPv6 address? I have full access to the DNS Zone using cPanel.

Thanks

Just talk to your ISP and get rDNS (Reverse DNS) set up for the IPv6 address your mail server is sending from. It's the exact same requirement that a sensible mail server requires from IPv4.

I set mine up several years ago and my ISP (IDNet) did it within an hour in response to my support request.

In reply to a post by jchamier:

In reply to a post by candlerb:

Google's mail acceptance policies are mad.

Fully agree, and they also apply to companies using Google Workspace accounts, as well as free GMail accounts. Unfortunately Google’s email service a) works, and b) consumers like it, so they think they can get the rest of us to jump through their hoops!

There's nothing mad about them. They are standard practice:

* MX records need to exist for sending(*) and receiving IP addresses.
* rDNS needs to be configured for outgoing IP addresses.
* SPF record needs to list all servers.

The last one might be optional (I can't remember) but it's something all mail senders should have anyway. If GMail is enforcing SPF records then hurrah!

(*)Not technically needed but any sensible mail host would reject mail from a server without a corresponding MX record.

Edited by Andrue (Mon 24-Jun-24 19:53:30)

In reply to a post by jpm:

PTR records are set on your IP address, they're nothing to do with your domain.

For your IPv6 record your best bet is to ask Zen to delegate your allocation to a set of name servers that you control.

I'm with IDNet and I just asked them to set up rDNS for the IPv6 address my mail server uses.

In my experience (and it's been a while since I last looked at this), Google were setting higher bars for SMTP received over IPv6 than over IPv4.

As a fan of IPv6, the PTR format is the only thing I initially found off-putting.
I had assumed that they would group them by 4 hex digits (16 bits) as per the address format.

Then I looked again at how IPv4 PTR format works, and the mess that can be if your network numbering or subnetting happens not to be on 8-bit boundaries.

Also remembered it resembles E.164.

After that the per-nibble thing made more sense as a design choice.

In reply to a post by candlerb:

In my experience (and it's been a while since I last looked at this), Google were setting higher bars for SMTP received over IPv6 than over IPv4.

Odd. I didn't notice anything like that. I just did the same things I did for IPv4 and it worked. Has done for several years now.

I do have a vague recollection of something 'back in the day' that applied to GMail but I don't remember it and as far as I know it's now the same.

In reply to a post by prlzx:

As a fan of IPv6, the PTR format is the only thing I initially found off-putting.
I had assumed that they would group them by 4 hex digits (16 bits) as per the address format.

If they did that then certain delegations would be very painful: for example, to delegate a /56 would need 256 sets of NS records (i.e. the boundary would be either /48 or /64)

So, still not working...

I set up an AAAA record for my IPv6. I had Zen add a PTR for my IPv6. I still get bounce backs from Google. I suspect I'm using the wrong IPv6 address, which should it be?

According to my FritzBox I have
"IPv6 address: 2a02:8011:snipped:1/64"
and
"IPv6 prefix: 2a02:8012:snipped:/48"

Zen have added the PTR to the 2a02:8012 address. I've added the AAAA to the 2a02:8011 address. So that's wrong then? I should change the AAAA to the 2a02:8012 address?

The server running the mail reports its IPv6 as being
2a02:8012snipped/64
and
fe80::211:32ff:snipped/64

So again, that points to me setting the wrong AAAA?

The latest Google bounce was

Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.25 [2a02:8012:snipped] The IP
address sending this 550-5.7.25 message does not have a PTR record setup,
or the corresponding 550-5.7.25 forward DNS entry does not match the
sending IP. As a policy, Gmail 550-5.7.25 does not accept messages from IPs
with missing PTR records.

So we know I do have a PTR for that address but not an AAAA. Is that "forward DNS entry does not match the
sending IP"?

Thanks!

In reply to a post by Woolwich:

Zen have added the PTR to the 2a02:8012 address. I've added the AAAA to the 2a02:8011 address. So that's wrong then? I should change the AAAA to the 2a02:8012 address?

OK, changed the AAAA and that seems to have done the trick.

But.... according to the headers of the email as received by Google

Received-SPF: pass (google.com: domain of [email protected] designates 2a02:8012:snip:snip as permitted sender) client-ip=2a02:8012:snip:snip

I haven't added that IP to my SPF record, how/why does Google accept the IPv6 as a permitted sender?

server.mydomain.tld. 14400 TXT v=spf1 a mx ip4:my.ip.four.address ~all

One day the IPv6 penny will drop....

Thanks!

Don't know about the SPF such as whether it trusts you based on AAAA/PTR of the IP,

but yes you never set the router itself as the target or source for anything in IPv6 connecting remote side to or from a local service, unless the service you are connecting to / from is actually running built-in on the router.

For Frtiz built-ins can include their integral VPN and telephony things if using them.

Edited by prlzx (Wed 24-Jul-24 12:21:52)

Hi

Is the AAAA entry that was added the same server name as specified by your MX record(s)? If it was the MX part of the spf record would allow it.

Regards

Andrew

Perplexity has explained this for me...

In the context of SPF (Sender Policy Framework), an AAAA record plays a crucial role in specifying which IPv6 addresses are authorized to send emails on behalf of a domain.

### SPF and AAAA Records

SPF records are defined in DNS TXT records and include various mechanisms to specify which servers are allowed to send emails for a domain. One of these mechanisms is the `a` mechanism, which performs a lookup of either the A (IPv4) or AAAA (IPv6) record for the specified hostname, depending on the type of the source IP address.

#### How AAAA Records Work in SPF

1. **Mechanism Lookup**:
- When an SPF record includes an `a` mechanism (e.g., `a:example.com`), it will perform a DNS lookup to resolve the hostname to its corresponding IP address.
- If the source IP address of the email is an IPv6 address, the SPF check will perform an AAAA record lookup to get the IPv6 address of the specified hostname[1][2].

2. **Authorization Check**:
- Once the AAAA record is resolved, the SPF mechanism checks if the source IPv6 address matches the one returned by the AAAA record lookup.
- If there is a match, the SPF check passes, indicating that the email is authorized to be sent from that IPv6 address[1].

### Example

Consider the following SPF record:
```
v=spf1 a:mail.example.com -all
```
- If an email is sent from an IPv6 address, the SPF check will look up the AAAA record for `mail.example.com`.
- Suppose the AAAA record for `mail.example.com` is `2001:0db8:85a3:0000:0000:8a2e:0370:7334`.
- If the source IPv6 address of the email matches `2001:0db8:85a3:0000:0000:8a2e:0370:7334`, the SPF check will pass.

### Importance of AAAA Records in SPF

- **IPv6 Compatibility**: As the internet continues to adopt IPv6, having AAAA records ensures that domains can specify authorized IPv6 addresses for sending emails.
- **Preventing Spoofing**: By including AAAA records in SPF mechanisms, domain owners can prevent unauthorized use of their domain from both IPv4 and IPv6 addresses, enhancing email security[2][4].

In summary, AAAA records in SPF are used to authorize IPv6 addresses for sending emails, ensuring compatibility with the IPv6 protocol and enhancing email security by preventing spoofing from unauthorized IPv6 addresses.

Citations:
[1] https://www.reddit.com/r/DMARC/comments/1884e8w/a_re...
[2] https://www.cloudflare.com/learning/dns/dns-records/...
[3] https://serverfault.com/questions/1015629/why-do-i-n...
[4] https://www.mailersend.com/blog/dns-records
[5] https://kb.leaseweb.com/kb/domain-name/hosting-domai...