Hi! If I our mailserver sends mails to gmail, the delivering fails. This is the bounce of gMail Code: The mail system <[email protected]>: host gmail-smtp-in.l.google.com[2a00:1450:4025:402::1a] said: 550-5.7.1 [2a01:4f8:212:f65::2] Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information 550 5.7.1 . w13-20020a05640234cd00b0043bd6cf51d1si5536605edc.530 - gsmtp (in reply to end of DATA command) Reporting-MTA: dns; tesoro2.products4more.at X-Postfix-Queue-ID: D8ECA4A21450 X-Postfix-Sender: rfc822; [email protected] Arrival-Date: Sun, 14 Aug 2022 02:16:05 +0200 (CEST) Final-Recipient: rfc822; [email protected] Original-Recipient: rfc822;[email protected] Action: failed Status: 5.7.1 Remote-MTA: dns; gmail-smtp-in.l.google.com Diagnostic-Code: smtp; 550-5.7.1 [2a01:4f8:212:f65::2] Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information 550 5.7.1 . w13-20020a05640234cd00b0043bd6cf51d1si5536605edc.530 - gsmtp If I check the PTR-Record of our system (https://network-tools.webwiz.net/reverse-dns.htm) all seems fine. There is a PTR-Record to 2a01:4f8:212:f65:: which we set on the admin-panel of our server-provider. Take a look on this screenshot. https://ibb.co/myKGZrg [/IMG] Now lets have a look to Code: [email protected] # ifconfig enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 136.243.47.106 netmask 255.255.255.192 broadcast 136.243.47.127 inet6 fe80::921b:eff:fedb:519 prefixlen 64 scopeid 0x20<link> inet6 2a01:4f8:212:f65::2 prefixlen 64 scopeid 0x0<global> Any ideas what is to do, to make the delivering to gmail possible? Thanks in advance, Martin
Thank you - I read this before your post, but I thought in the meanwhile there are some new insights for this google-phenomen. I did as you described, works well! Thanks again!
Hm - the posted solution works for mail pointing directly to gmail but not for domains which are hosted at googleservices. So, if we send mails to [email protected] there comes the following bounce Code: Betreff: Undelivered Mail Returned to Sender Datum: Fri, XX XXXX 2022 14:32:08 +0200 (CEST) Von: Mail Delivery System <[email protected]> An: [email protected] This is the mail system at host tesoro2.products4more.at. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <[email protected]>: host ASPMX.L.GOOGLE.COM[2a00:1450:4025:402::1a] said: 550-5.7.1 [2a01:4f8:212:f65::2] Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information 550 5.7.1 . cr13-20020a170906d54d00b00730632d2a0fsi1725389ejc.452 - gsmtp (in reply to end of DATA command) We got 4 such bounces in the last days for different domains, so fixing that with transportmaps is rather cumbersome. Any other ideas how to fix that ip4/ip6-problem? TIA, Martin
Yes till, you are right - but I did a IPv6-setup as mentioned in my initial post. Here is another small piece of the puzzle to confirm the correctness of the setup Code: #ip -6 addr show scope global 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a01:4f8:212:f65::2/64 scope global valid_lft forever preferred_lft forever and the proof of ptr-check-service https://ibb.co/BnCMQrg
Add a PTR record for the exact IPv6 IP, not the subnet. Add a PTR for 2a01:4f8:212:f65::2 that you are using for sending. It might be that you have to remove the one for the subnet. I received the same error on some of my servers and they are gone after adding a PTR for the exact IPv6 address.