Hi, I had that problem already and solved it - so I thought - by adding the appropriate domain name in the PTR server setup for the IPv6-address, and it seems it worked. But now I get again the message: "The IP address sending this message does not 550-5.7.25 have a PTR record setup, or the corresponding forward DNS entry does 550-5.7.25 not point to the sending IP. As a policy, Gmail does not accept 550-5.7.25 messages from IPs with missing PTR records." I understand there are some AAAA records to be set, but I don't know where and how. I checked the MXToolbox, it says that DNS entry exists, but DMARC record isn't found and DMARC policy is not enabled. Could this cause gmail to now reject mails from that domain? I wonder if I should setup a DNS myself, but I fear that would interfere with the DNS entries at the ISP's side, where the virtual server is. The server in the PTR record is not the domain name of the sender, but that of the virtual server. The IP addresses point to that virtual server.
The message says that the mail server that sends this message does not have a PTR Record set up, which means that your servers PTR record is not correct. You have to add the correct PTR Records. In case you a renting a server, you should be able to set this within the customer control panel. It is not necessary for DMARC to be active, although that makes your mails more "legit" for spam filters. It is useless in this case to set up a DNS Server yourself, as i assume you are not the owner of this IP Range and therefore not able to provide DNS for it, so it won't help this situation at all. TL;DR: Set up the correct rDNS Records at your providers control panel.
That's what I did several weeks ago, and after that it worked. The entry is still there, but now google complains again and I have no idea, why.
Google has a postmaster tools page to help diagnose such sending problems: https://www.gmail.com/postmaster/ Also, take care to create a PTR record for your IPv4 address but also a second one for your IPv6 address. It is not enough to have one for IPv4 for Google when your system has also an IPv6 address.
The PTR record is set for both, IPv4 and IPv6. That's what I don't understand. Several weeks ago, I and other users got those rejecting messages from google, I set the PTR straight and it worked for a while. Since then nothing has changed, only that now Google starts to complain again.
Hi, I'm back again with the same problem. Code: gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1b] said: 550-5.7.25 [xxxx:xxxx:x:xxx::xx] The IP address sending this message does not 550-5.7.25 have a PTR record setup, or the corresponding forward DNS entry does 550-5.7.25 not point to the sending IP. As a policy, Gmail does not accept 550-5.7.25 messages from IPs with missing PTR records. Please visit 550-5.7.25 https://support.google.com/mail/answer/81126#ip-practices for more 550 5.7.25 information. [xxxx:xxxx:x:xxx::xx] is actually the IP-v6-address. I have read through the ip-practices doc provided by google, but there is no reference to the error 5.7.25. The PTR should be fine (see posts above, I checked again, IP v4 and IP v6 are there). However I wonder if the fact that my own domain is not the same domain given in the PTR (it's the server's domain name like vmgrxxxx.v.reverse-ip.de) causes the problem, but this domain should be in the PTR. I wrote to Google with no response. I have no access to the DNS, which is handled by the ISP of the vserver. I am stuck and quite frustrated, because this happens only with mails to gmail.
That's not causing an issue and is always the case on mail systems anyway. Just take care that system hostname and PTR match. so if system hostname is server123.somedomain.tld, then PTR should point back to server123.somedomain.tld. Maybe you have multiple IPv6 addresses assigned and not all of them have a PTR. One thing that you can do is to restrict Postfix to use IPv4 only, it's not ideal but I guess there are no 'real' mail systems yet that do not have an IPv4 address.
Thanks. I'm reluctant to restrict postfix to use only IPv4 addresses. Currently, I am in contact with my ISP, maybe they find out what is wrong. GMail also mentions DKIM, and I actually have it set up in IPSConfig, but I guess the DNS record is not set, because that is managed by my ISP. I tried to copy the DNS-Record shown in ISPConfig, but I cannot copy it - ISPConfig seems to prohibit it. At least as soon as the mouse cursor gets into the space where the DNS-record is written, it changes to the "no access" sign, and I cannot highlight it. Copying it by hand is prone to errors, givwen the length of the record. When I look at an email sent from the domain, I don't see a matching DKIM-key, even though a DKIM-signature field is there which contains a key (it seems).
On my system the mouse cursor also changes to a "traffic sign", but I can still paint the text and copy it. Indeed, ISPConfig automatically copies the DKIM to DNS, but only if DNS is run on the same ISPConfig system. If DNS is somewhere else, it must be copied manually.
Copying the DKIM record works finee at my system, just mrk (highlight) the text and press ctrl + c or right-click and chose copy.
Arwe we looking at the same page? I chose Email/Domain, then select the relevant domain, click on the Button "Domainkeys Identified Mail (DKIM)", then it opens more info, and options: Enable DKIM (which is checked) DKIM-Selector (default) DKIM Private-key (the field is filled with the private key) A button "Generate DKIM Private-key" DNS-Record (the field is filled with text (about 4 lines), but I cannot copy the text Is that the page where you have been trying? If so, why doesn't it work for me? I just upgraded ISPConfig to the latest version (3.2.10p1).
Yes, exactly there. Copying works fine, tested in Chrome and Firefox. There is the forbidden icon displayed, just ignore it, mark the text and copy it. See screenshots.