2

I send emails for test@example.com with my own server. When using dig -x xxx.xxx.xxx.xxx with the IP of my server, I get:

;; QUESTION SECTION:
;xxx.xxx.xxx.xxx.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
xxx.xxx.xxx.xxx.in-addr.arpa. 86399 IN     PTR     ns328xxxx.ip-xxx-xxx-xxx.eu.

How to know if this answer is correct for email purposes?

Should example.com appear in the answer instead? Or is ns328xxxx.ip-xxx-xxx-xxx.eu correct? (x are replaced by numbers).

Note: this question is different to this one, thus the two questions.

Basj
  • 709
  • 3
  • 11
  • 29

3 Answers3

4

It doesn't actually really matter what the name in reverse DNS is, as long as the use of names is consistent.

Arguably, as long as there is "forward confirmation" (there exist A/AAAA records that agree with the reverse DNS PTR), the reverse DNS in itself is "correctly set up".

Then there's the matter of what the hostname / "mailname" of the mail server host is set to. Ie, the name that a mailserver uses to refer to itself in the SMTP dialog.
This is expected to match the declared hostname according to reverse DNS, and some, but not all, services out there will care if these differ.

What does not matter is if the hostname of your mailserver has any relation to the domain names it handles mail for.
It's a fairly widespread misconception that these names should match, but them matching would actually be very strange for several reasons:

  • Many mail servers handle mail for several domains, but they can just have one hostname, so they can't possibly match all.
  • A hostname is expected to be something like zeus.example.com while the domain name it handles mail for, even with just a single domain name, would almost certainly be something like example.com. Certainly no match there either, even if there is sometimes a relation between the names for smaller-scale deployments.

There are of course many other aspects regarding what will cause other mail services out there to accept/reject your email, but these are the basics specific to reverse DNS.

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
2

Having a PTR record isn't an official part of the email spec, but it is a common practice for senders to increase the chance of deliverability.

Its importance may be a little overstated - it's relatively uncommon for mail servers to outright reject mail based on this check in the absense of other problems. But some do, and even in some that don't it may still contribute to their mail filtering algorithm. It is still worth complying as a sender.

There are in my mind four levels of checking for PTR records:

  1. No check at all

  2. Check that a PTR record for the client exists, but it can be any value.

    No requirement that the value given maps back to the IP address. The idea is that consumer internet connections often don't have PTR records, and even if compromised would have no access to set one up.

  3. Check that a PTR record for the client exists, and that an A or AAAA record for that name resolves back to the original IP address.

    This is called Forward-Confirmed Reverse DNS (FCrDNS). It still doesn't matter what name the PTR resolves to, as long as a forward resolution gets back to the original IP address.

    This provides negligible benefit over just checking that a PTR exists, but it does at least show that there is agreement between the IP ownership and the domain owner that these should match.

  4. Check that a PTR record for the client exists, and that an A or AAAA record for that name resolves back to the original IP address, and that the name matches the name the sender identified as (with HELO/EHLO).

    Nobody really checks this. The only reason I included it is that it's what a lot of people assume they need.

For sending, you should ensure that you satisfy up to number 3, though if you have access to set any value you want as PTR, then you may as well do number 4 as well (match it to your HELO hostname).

For receiving, I don't think you can use any of these (except number 1 - don't check at all). There are legitimate servers from household-name companies which send from addresses that wouldn't even pass number 2 - I know this because I had to stop checking PTR records on my mail server for this reason.

You can, if you like, use a FCrDNS check as a positive signal in your mail filtering solution.

thomasrutter
  • 2,527
  • 1
  • 25
  • 34
0

There are lots of services that will check for you, e.g.

Some ask you to type the domain in a web form, some have you send them email.

ptman
  • 28,394
  • 2
  • 30
  • 45