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...