I know that you automatically create a PTR record for the internal IP address but I also need one for the public address. I am running a mail server on my droplet and have mail.s4software.com as the Postfix hostname with it pointing to public address. To avoid mail delivery problems, that IP should point back to my hostname
Greetings!
Thank you for posting this here so that others can benefit from the answer as well. To set a PTR record on your droplet, you just need to change the droplet name to a fully qualified domain name. So if your droplet is named "mail.s4software.com" then that will be your PTR record as well. You might give it an hour or two before checking it, just to make sure DNS caches drop.
To clarify, this is the naming in our cloud panel, not just the hostname inside of the droplet.
Jarland
I'm not sure that this answered my question. I know that a PTR record will be created from the system's internal IP address to the droplet FQDN. What I need is a PTR record from my floating IP address.
The reason this matters is that I have a CentOS7/Postfix mail server running and the outgoing mail is getting the internal IP address which some recipients reject because it comes from an IP address which is in a dynamic block, hence wanting to use the floating IP.
This brings up a related question, the droplet only seems to know about its internal IP, how do I get postfix to use the floating IP address? I can add 'smtpbindaddress' into the Postfix main.cf but then I get a 'cannot assign requested address' error. (note: this system seems to mess up the underscores in smtp etc.)
We do not allow mailing over our floating IPs, and currently do not support PTR records for them. The droplet's base IP is not dynamic and is static, those services are mistaken and may listen to reason if you are able to speak to them. They also may not, they are not all reasonable and not all of them will speak with anyone.
Convincing services to accept emails from anyone that isn't a big named email provider is a much more complex task than it used to be. I'm happy to offer any advice on that as this is something that I do a lot of personally, but just be aware that there is very good reason that email is a continually growing business - most people don't intend to sign up for what that task has become in recent years. Getting all major services to accept your email is either very hard work or a very lucky landing of a dice roll. I've not, for quite some time, had a single IP address accepted universally by AT&T, Verizon, Yahoo, Google, and Microsoft. Since late 2013 I've had to maintain a complex system of relays (or use MailChannels) to reach all of them at once.
It is listed as dynamic in the sorbs.net:
The RBL monitor found some of your IP addresses blocked by some blacklists. Here are the details:
Blocked by dul.dnsbl.sorbs.net: 178.128.64.125
Blocked by dnsbl.sorbs.net: 178.128.64.125
Sorbs Duhl Reports Dynamic Ip Addresses
Dynamic-based Blacklists will list many DHCP ranges of IP Addresses from Internet Service Providers. You could be listed if your IP Address was previously dynamically assigned, or if your ISP gave you a static assignment and did not assign a distinguished PTR-Record, aka a "Reverse DNS Entry."
Aye, that's definitely not correct, but sorbs is unlikely to delist. However, not many people use them for filtering these days. They would only be relevant if you are receiving a bounce error stating that the recipient service blocked your email for being listed there.
P.S. I have run my own internal mail server and am quite familiar with the issues but did not have this type of problem until moving to a droplet. Your floating IP mail exclusion may be reason for me to not use your service.
Well let's talk about it. Why do you need a floating IP to send mail? They're all IPv4 addresses. If some third party service thinks something differently about your droplet IP than your floating IP, this is merely luck of a dice roll (they literally have no way of knowing the difference), and as I noted above is not even likely to be relevant to the issue that led you to the conclusion. Feel free to email me at jdonnell@digitalocean.com if you'd like to chat more. Try to walk it back to the original problem that led you to check sorbs.
I agree. I am (or was) looking for alternatives to move from bluehost VPS, in part because of email deliverability and their issue with DKIM records. Now that I have SPF, DKIM and even DMARC set up on a droplet (and tested the authority), gmail still spams the server outbound emails because of the rDNS issue with floating IPs. Pretty much every server I run sends out email, and some are web stores. Makes little sense to move if the server mail doesn't get to the users. A large reason for this was not to force my clients to use some other mail alternative for simple server messages.
If there is a way around this I'd love to know, it's down to this one detail. Floating IP's mean Digitalocean droplet scalability and staging. rDNS (along with SPF, DKIM and DMARC) means the emails don't get spammed.
Basically what this seems to say is that you can't really have scalability features of floating IP's and still expect outbound server mail to get to anyone's inbox.