OK, this issue seems to have magically resolved itself since I posted this.
I’ve not changed anything, though I did install some Ubuntu updates earlier on.
It was still showing as not correct following the updates though.
I’m a +1 here. Since setting up MIAB v0.12c in August, also on DigitalOcean, I’ve been receiving this alert regularly. I asked DigitalOcean to confirm on their end that the PTR was correct and they affirmed. I also see it set correctly when testing from my own network. Edit: This persists through to the latest version of MIAB.
I have noted that as of August DigitalOcean’s DNS panel refuses to create zones when a droplet’s FQDN is a second level domain (e.g. example.tld) and I wonder if there is some related bug in their PTR maintenance code…? This was of interest to me because I bought and am using a .com for the server itself. Is this the same for everyone else, or are you using subdomains?
All the reports here so far are also from DigitalOcean customers. @JoshData are you tracking this from users of any other provider?
I have one box in DO and another box at another VPS, and I also see this regularly and only on my DO box. But it could be a software issue. It’s possible that the locally running DNS server (bind) is getting restarted right before this check and that it’s not up yet when the reverse DNS check is run.
This looks like an old thread but I am currently experiencing this issue as well… The Status page says my reverse DNS isn’t working. Then while looking at an NDR it said “smtp; 554 fed1rmimpi310.cox.net cox 22.214.171.124 rejected - no rDNS” which indicates my reverse DNS isn’t configured.
I am running MIAB exactly as described in the main page video, using Gandi as the domain registrar and hosting on a Rackspace Cloud Server.
When I looked at /admin/dns/dump I didn’t see any reverse DNS zones, nor do I see any reverse zones in /etc/nsd/zones.conf…
I have rebooted the box and have also re-run mailinthebox to go through the configuration…
Sorry guys, I realized after posting this the ReverseDNS record has to be set at the VPN hosting company since they are the ones who own the IP address. I went into the Server Details page and found the option to set a Reverse (PTR) DNS record.
If it’s intermittent and you’re not seeing other problems, then it’s likely safe to ignore. This has been a long-standing issue that seems to be just about the status checks and no one has been able to track down yet what exactly is happening.
A year from the original post, I can confirm the issue is still open (MIAB latest version, DO).
Now something different…
I have a little PHP status monitor which regularly “pings” (not really ICMP packet) SMTP port of MIAB instance.
Very hacky way to make sure the service is up. The interesting piece is that whenever I get a message from MIAB about “reverse DNS not set properly”, same moment I get the message “service down” from the monitor.
The service wakes up the next tick, so nothing dangerous here, but I am wondering what would happen if someone sends me an email right the moment this “failure” happens?
Possibly unrelated, but I got this alert a couple day ago, also a one-off that solved itself by next day.
*****.org -- Previously:
✓ Nameservers are set correctly at registrar. [ns1.box.*****.org; ns2.box.*****.org]
*****.org -- Currently:
? The nameservers set on this domain at your domain name registrar should be ns1.box.*****.org; ns2.box.*****.org. They are currently NS2.BOX.*****.ORG; ns1.BOX.*****.ORG. If you are using External DNS, this may be OK.
Domain name was also in uppercase in "They are currently NS2.BOX.*****.ORG; ns1.BOX.*****.ORG. "
No idea what may have triggered this, domain name are in lowercase at registar.
There was no problem accessing the box, so it look like a status check problem.
Registar is joker.com
MIAB is hosted on a french OVH dedicated server (inside a VM).
VULTR hosting here and I see this too every now and then (like today) and it resolves itself apparently. Although the last time it happened I submitted a ticket and should have ask for more details as they indicated something may have been adjusted.
[…] – Previously: ============================== Your box’s reverse DNS is currently [Not Set], but it should be […]. Your ISP or cloud provider will have instructions on setting up reverse DNS for your box. […]-- Currently: ============================= ✓ Reverse DNS is set correctly at ISP. IP ↦ […]
MiaB status email on August 14 indicated no rDNS for my IPv6 address - I actually didn’t notice this part of the message when it arrived because it was buried under 21 new package updates available on the same day.
The next day, August 15, the IPv6 rDNS was set correctly. I hadn’t even logged into the Vultr dashboard for at least a week, so something completely on their end.
At this point, I don’t find it a serious concern as most email servers are still using IPv4 and I don’t know how long the issue persisted. A few hours of no rDNS every now and then isn’t really very serious.