Look at the answer section a little more closely:
;; ANSWER SECTION:
444.333.222.111.in-addr.arpa. 86365 IN PTR main.funkeedomain.org.333.222.111.in-addr.arpa.
Specifically, the value of the PTR record:
Your ISP forgot to add the trailing dot to your FQDN. This is causing the DNS software to helpfully ...
Do the standards governing DNS operation require that all devices have a matching PTR record? No.
Do the standards for certain protocols require PTR records that agree with corresponding A or AAAA records? Yes.
Do some applications not governed by a RFC have the same requirements? Yes.
Can a PTR record point at a CNAME? Yes, but the CNAME ...
444.333.222.111.in-addr.arpa. 86365 IN PTR main.funkeedomain.org.333.222.111.in-addr.arpa.
Seems that in the reverse DNS zone data somebody forgot to add a trailing period . to your hostname to indicate that it is a fully qualified hostname. In DNS shorthand any simple hostname gets appended with $ORIGIN.
The correct zone data would be
Your hosting provider who owns the IP sets the PTR record for it. There is nothing to do in the DNS zone editor for your domain.
I have just done it. My hosting provider (digitalocean) automatically created PTR record when I named the host, it just needed to be the full name, ending with the domain. I added the IP in Godaddy's DNS editor. Now nslookup ...
Mail servers will cross-check your SMTP server's advertised HELO hostname against the PTR record for the connecting IP address, and then check that the returned name has an address record matching the connecting IP address. If any of these checks fail, then your outgoing mail may be rejected or marked as spam.
So, you need to set all three consistently: The ...
Before I get to my suggestion, I want to comment a bit on something your provider said to you:
Received: from mail.com ([220.127.116.11])
by smtp-27.iol.local with SMTP
id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
This does not indicate that the reverse DNS for 18.104.22.168 is (or was) mail.com. Rather, it indicates that the ...
The DNS system has many kinds of records. "A" records map names to IP addresses. "PTR" records map IP addresses to names. The mapping is not always transitive, and there can be multiple A records that map the the same IP address.
Strictly speaking, PTR records map special names to other names. The IP address 22.214.171.124 first must be translated to 144.81....
It's extremely common to block SMTP servers that don't have these basics:
Hostname in HELO forward resolves to IP connection originated from.
Connections origin IP reverses to the Hostname claimed in HELO.
If SPF, DKIM, or DMARC policies exist, verify.
Anyone griping about getting blocked because of one of these should be tarred and feathered.
People who ...
I have tried multiple approaches with the HELO/EHLO checking with a fairly decent sized customer base of between 100k-200k users and ended up going with a solution that does the following:
Check that the HELO/EHLO contains a domain name. -- This mostly boils down to does the name have a dot in it. Checking the DNS on the name led to MANY failed servers as ...
Nowadays the most frequent culprit is GSSAPI:
The other three culprits for Linux platform have been mentioned in other answer:
add to sshd a command line option -u0
set UseDNS no
don't use from=hostname inside authorized_keys files
Basically, will the reverse DNS pointing to a subdomain of the domain
the mail server reports be valid?
No. Just give your server a full name like myserver.mydomain.com. Make sure your reverse DNS also contains myserver.mydomain.com, and that the mailserver announced itself (with HELO) as myserver.domain.com as well.
Technically, you could have it be ...
I think there's slightly more complexity than mdpc suggests. The letter is true: only the person to whom the relevant chunk of PTR space has been delegated can manage the PTR records in that space.
In the second paragraph they have made the assumption that the current delegate is the person who is responsible for the PA IP address space. That is usually a ...
The in-addr.arpa zone is delegated in much the same way as other zones: by using delegation NS records.
Accordingly, suppose you were curious as to who had the authoritative DNS server for 192.0.2.0/24. This subnet mask is divisible by 8, and so you can do:
dig in ns 2.0.192.in-addr.arpa
Your answer will contain a list of nameservers serving the rDNS ...
From a technical perspective it doesn't matter where the forward DNS is hosted.
The reverse DNS is typically hosted by the provider of your IP-address, so in your case by Amazon. As long as the forward DNS matches your actual ip-address and the PTR-record you're requesting, Amazon allows you to set-up a reverse DNS record by contacting them.
Q: Can I ...
What security threat is there?
How could anyone fake a one-way DNS in some threatening way?
Any party with control of a DNS reverse zone can set their PTR records to whatever they want. It's conceivable that someone could set their PTR record to legithost.example.com, and then try to brute force their way into your environment.
If you have fat-fingered ...
ping is not a name resolution tool. It's an ICMP tool that has some DNS wonkery tacked on. When using ping as a name resolution troubleshooting tool on a Windows machine you're going to be batted around between responses from NetBIOS, potentially WINS, the hosts file, resolver cache, and (if you're lucky) a DNS server. Your mileage may vary, contents may ...
I fixed this by adding a new high-cost MX record for the domain at 126.96.36.199, which pointed to the mail server for 188.8.131.52. This ensures that the reverse DNS matches the forward DNS. This is basically a quick fix to get around the sendmail issue below.
I did find out some useful stuff about Hotmail and Outlook along the way, and what causes mails to be dumped....
You've got a PTR record mapping 184.108.40.206 to host2.sparkdojo.com, which is fine, But there's no A record for host2.sparkdojo.com, so the lookup the other way is not working. You need both of them to work.
I'm not sure about outright invalid but it's at least highly unconventional to have a bare domain name as the (fqdn) hostname for a host.
Normally one has a hostname, eg zeus and a domain name eg example.com forming a fqdn hostname zeus.example.com.
Other than strange choice of name, it looks like the reverse DNS is set up properly (properly forward-...
Google won't configure reverse DNS for you
If you had a carrier such as AT&T or an EC2 instance, they offer reverse DNS services. As of now, Google does not offer this as an attribute of their service.
It is rumored they will remediate this at some point but as of now the service is unavailable.
Response from MXToolBox Support:
Your PTR record is mail-hosting.dk which is a Domain name. The RFC
guidelines say that is must be a hostname such as
mail.mail-hosting.dk. Most systems won't care that it is a domain, but
since it's against the RFC guidelines, we show a warning.
In this day and age, trying to do your own mail server is, for the most part, a loosing battle and you are better off finding an affordable service. Having said that..
Look at your logs going to the provider that blocked you and see if you can find anything suspicious. It is possible, and happens often, that someone forgets they subscribed to your ...
You're right. It doesn't make sense for exactly the reason you stated. An MX record defines where email goes to, not where it comes from. Anyone using any kind of MX record check to validate incoming email is doing it wrong as far as I'm concerned.
An SPF record defines where email comes from.
First of all, you need an addressing plan. If you don't have one yet, get a /48 network allocated to you. Then pick one /64 as your current major network. You'll save the rest of the address space in the event, i sincerely wish you it will happen, that your business scales up a lot.
NOTE: You will NEVER need more than a /64, but if you get really big, it ...
The reverse DNS (which is a PTR record in the in-addr.arpa zone) is set by whoever owns the IP allocation. You need to ask whoever provided the IP to you (e.g. the ISP or hosting provider) to change the record.
DNS doesn't contain an automatic IP to hostname lookup mechanism. It does have PTR records, but these are configured manually and don't correspond with the A records in most cases. Sites like domaintools.com simply have a big database of all the forward mappings they've discovered and they query this when an IP is looked up. The results are not guaranteed to ...
The reverse lookup option is only present in the upcoming 3.1.0 release:
NEWS for rsync 3.1.0 (UNRELEASED)
Added the "reverse lookup" parameter to the rsync daemon config file to allow reverse-DNS lookups to be disabled.
You cannot set the reverse DNS yourself -- you have to ask your VPS provider to do that.
With an IP of 159.x.y.z the reverse DNS is basically a lookup of z.y.x.159.in-addr.arpa., as described in the Wikipedia article.
With a local BIND you might get a reverse DNS configuration on your own server, but nobody else would ask your server and see it. So it has ...
Is there any way to obtain an entire range of IPs from a reverse-DNS?
Not really, no; in extremely rare cases you might be able to do a DNS zone transfer query to get all the records in the zone (the whole /24, generally), but there's a very low chance that the name server you're querying will respond to this request. Expect one query per address for ...