adding PTR records on default

DutchProgrammer

Verified User
Joined
Oct 14, 2012
Messages
15
Hello,

Could there be a possibility so PTR records will be adding automaticly when adding a new domain because more spam filters are looking for this record ?

Thanks,
Danny
 
I never used PTR records in DA and don't have any spam filter issues.
Normally the ptr record of an ip address is set at config panel of the owner of the ip address... mostly the datacenter or host you are renting the server from. You can often adjust this yourself.
If you set that to the FDQN hostname of server your mail is send from, you should not have any spam filter issues.
 
I never used PTR records in DA and don't have any spam filter issues.
Normally the ptr record of an ip address is set at config panel of the owner of the ip address... mostly the datacenter or host you are renting the server from. You can often adjust this yourself.
If you set that to the FDQN hostname of server your mail is send from, you should not have any spam filter issues.

I know you can set it up but it's alot of work to do it for every domain on the servers.

See http://www.checktls.com/perl/TestReceiver.pl you definitely need the PTR, if you dont have the PTR you dont get ' OK, E-mail address proofed '

Gmail is checking for PTR as well these days if you dont have it, the receiver gets an question mark in the circle before their name, when clicking on it google is telling that the mail couldn't be verified that the domain owner has sended the mail or by a spammer
 
I know you can set it up but it's alot of work to do it for every domain on the servers.
Not it's little work because it's not needed for every domain on the servers. You only need 1 PTR record per server and that is to the hostname your server is sending email from. Not for every domain.

Suppose your hostname is server3.provider.com with ip 82.82.44.44 and your domain is dutchprogrammer.nl then mail is send from server3.provider.com for you because dutchprogrammer.nl is hosted on that server and not sending out mail itself.
So the helo will also be helo server3.provider.com everywhere.
In the datacenter (or the control panel of the provider who provides ip 82.82.44.44 for you), put in the PTR record like this:
RDNS 82.82.44.44 -> server3.provider.com
and you're done for all domains on the server.

I checked your link on my email addres.
As said in DA itself we don't use any PTR records and my domain is als hosted on a server with another domain name as the name of my company. The only issue the test is giving me is:
"Cert NOT VALIDATED: self signed certificate" The rest is 100%.
And I also got " Recipient OK, E-mail address proofed.
So you don't need a ptr for every domain name. And we never have issues delivering mail to hotmail or gmail on any server.

To be sure I tested again by sending a mail from an email adres to my gmail account which does not have any accounts whitelisted. I don't get any question mark.

Even stronger. If you are going to use PTR records for multiple domains on the same server, then you will get issues. Because in that case, you will declare that ip 82.82.44.44 is pointing to xx different domains on a server, which is suspecious to spamfilters because mail is still being send from "server3.provider.com" and not from mail.dutchprogrammer.nl or any other domain on the server.

Believe me, PTR records are to identify the hostname that is associated with the ip address sending the helo/ehlo, NOT any domain name not sending the ehlo.
 
Last edited:
Hello,

PTR records or rDNS, as Richard already mentioned are set per IP, not domain. They usually can be changed only through a control panel of your server provider or through a ticket request. In your case you should change PTR/rDNS records on TransIP's site: https://www.transip.nl/cp/

related: https://www.transip.nl/vragen/46-hoe-mijn-reverse-dns-instellen/

Every single IP if you have multiple IPs can have its own name set as PTR (reverse DNS) record.

You can change PTR/rDNS for IPs in Directamin only if you own or rent a subnet and it's properly delegated to your NameServers.
 
Back
Top