0
  • We are using a rented VPS as an email server.
  • Lets say the email domain is example.com.
  • The nameserver for example.com is a different server.
  • rDNS for the VPS can be set on the hosting side.

In order to reduce the chance of our email ending up in the spam folder, I have carried out settings as follows:

  • VPS hostname: server1.example.com
  • rDNS: server1.example.com
  • spf and DKIM are set on the nameserver for example.com

My question is this: Do I need to create a DNS record on the nameserver that points server1.example.com to the VPS's IP address ? There is already a DNS entry that points example.com to the email server's IP address, and email works with this.

I am not sure if this is relevant to email deliverability or just general best practice, but would appreciate confirmation from someone who knows.

This following article seems to imply it should be done (see last line): http://www.codero.com/knowledge-base/questions/358/How+to+set+Reverse+DNS+%28rDNS%29

but I wasn't able to find a clear answer one way or the other.

Jenny D
  • 27,358
  • 21
  • 74
  • 110
  • Forward and reverse DNS records need to match. Just having one and not the other is a misconfiguration – HBruijn Jul 26 '19 at 14:49

2 Answers2

2

If I understand the question you are concerned around email flow and making sure your emails aren't getting scored improperly as spam when sent to a 3rd party.

It sounds like you've done it right:

  • DNS A record for your mail server
  • DNS MX record for your mail server
  • SPF and DKIM for the mail domain using the mail server info

I would recommend a DMARC record as well if possible. Also, if possible set your SPF record to a hard fail, this will help remote hosts discard mail from you that definitely is not from you.

You should have a rDNS and A record that match for the mail server. So if you don't already have an rDNS entry for the IP associated with the mail server A record, you should have one. This is necessary because a lot of mail servers will do reverse lookups to make sure the sender's IP matches the hostname.

OnDmarc has a great KB that walks through a lot of this and can help solidify your understanding: http://knowledge.ondmarc.com/en You don't have to use their services, just read their KBs.

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • Thanks a lot everyone for your answers, they are incredibly useful ! @TheCleaner: You suggested setting spf to a hard fail; I had considered this but won't spf fail in cases where the recipient auto-forwards it ? For example see: https://serverfault.com/questions/841243/spf-broken-by-forwarding-on-the-recipient-side-what-do On a separate note, thanks for reminding about DMARC -in fact I already have this in place but forgot to mention it – Paul McCabe Jul 27 '19 at 09:04
  • An additional question if I may: Should the SSL certificate for the VPS (and therefore the email server) be server1.example.com or is just example.com OK ? (my understanding is that the SSL certificate is an issue between the VPS and the email client so does not affect email deliverability, but would appreciate thoughts on this just in case). – Paul McCabe Jul 27 '19 at 09:05
  • if the autoforwarder ARC-seals the emails it should mitigate failure, many autoforwarders are not configured to do so. Best practice regarding the SSL certificate is still a set of options, but in essence whether you are using a self-signed certificate or a trusted one it should ideally match the A record / PTR / smtp banner. In most cases a mismatch won't matter, and in most cases self-signed won't matter. – Allan Wallace Jul 27 '19 at 13:27
2

Do I need to create a DNS record on the nameserver that points server1.example.com to the VPS's IP address ?

Yes, you do. As @HBruijn commented, you need to have a PTR record (reverse DNS) so that when a remote host does a reverse look up of your IP number to get the name of your server, it will receive the PTR record server1.example.com. Likewise, when people have your server's name and try to look up your IP number, you need an A record so that they get the correct IP number for your server.

Assuming that your server is named server1.example.com and your IP number is 10.216.177.146, anyone with access to the public DNS needs to be able to:

$ host 10.216.177.146
146.177.216.10.in-addr.arpa domain name pointer server1.example.com.  

$ host server1.example.com
server1.example.com has address 10.216.177.146

The key element here is that the second lookup returns the same IP (10.216.177.146) that was used in the first lookup.

The logic behind it goes something like this:

1) when your server opens a TCP connection to deliver outbound mail, the only thing the receiving server knows is your IP number, 10.216.177.146, at least at first.

2) since all it has is an IP number, it does a reverse lookup, and obtains the PTR record for 10.216.177.146. That should return server1.example.com.

3) since PTR records can easily be forged (and set to a value to try to impersonate some other entity), the remote server then does a forward lookup on the PTR it received. That lookup of server1.example.com should return 10.216.177.146, and that sounds like the piece (the A record) that you're still missing.

It is this PTR record -> A record -> PTR record chain that establishes what is referred to as matching forward and reverse DNS and gives the remote server a modicum of confidence that your server is authorized to use the name server1.example.com. Other tests are done in addition to this (such as the SPF and DKIM tests refered to in the other answers and comments), but some servers won't even accept your mail if you don't have matching forward and reverse DNS.

Jim L.
  • 645
  • 4
  • 10