Checking FQDN, Reverse-DNS/PTR, MX record

Before you start a mail server, you must verify your server’s FQDN, reverse PTR, MX records.

FQDN

FQDN (fully qualified domain name) is a name assigned to an individual machine. Its purpose is to uniquely identify a single machine across internet. It is name of your server.

Checking Hostname (FQDN)

Following commands show outcome for test.rtcamp.com (a subdomain we used for test mail server setup)

Check FQDN by running following command on server:

hostname -f

Outputs:

test.rtcamp.com

Changing Hostname (FQDN)

If its incorrect, or need a change you can do so by running:

hostname myhost.mydomain.mytld

As you can see, we can give any name to your server, you may be wondering how uniqueness works! That’s where reverse PTR come into picture.

Important – Set “A” Record for Host in FQDN

If you set your machine’s FQDN, for example mail.example.com, then at example.com DNS create an “A” record for subdomain “mail” poiting to your server’s IP address.

You can use example.com as your hostname also which most likely pointing to your server’s IP address already. It’s not FQDN technically, but I see it working mostly. Still, I will never use or recommend non-FQDN hostname.

Reverse DNS/PTR Record

Like “A” record help global internet find IP-address for a domain, pointer record (PTR) helps you find domain (FQDN) for an IP. As this is reverse to what commonly DNS is used for, this process is often referred as Reverse-DNS lookup  also.

Having your FQDN (domain-name) resolve to IP and reverse-lookup for IP back to domain name can improve mail-delivery. This is also called Forward-confirmed reverse DNS.

Check IP address of your server using following command:

host test.rtcamp.com

You will see lines like below:

test.rtcamp.com has address 192.241.254.103
test.rtcamp.com mail is handled by 10 test.rtcamp.com.

If your server has multiple A records, you will see multiple lines for IP-addresses listed one-per-line. For real example run host google.com

Please note IP address for now. Check reverse PTR for IP address is correct:

host 192.241.254.103

Outputs:

103.254.241.192.in-addr.arpa domain name pointer test.rtcamp.com.

As you can see, reverse DNS lookup for IP shows same hostname (FQDN) in above example.

If you see incorrect hostname, you may contact your hosting company/ISP to get it fixed. Wrong Reverse PTR can lead to emails being rejected from your server. Please do not contact your domain registrar, if your domain-registrar and web/mail-hosting companies are differnt.

dig command for reverse-DNS/PTR lookup

You can also use dig tool also. Just write IP address in octet-reverse and append in-addr.arpa in the end:

dig +short ptr 103.254.241.192.in-addr.arpa

You will output like:

test.rtcamp.com.

MX Records

MX record tells Internet which machine will receive mails for a particular domain/subdomain.

Easiest way to check if who is handling mails for your domain is to run again:

host test.rtcamp.com

You will see lines like below:

test.rtcamp.com has address 192.241.254.103
test.rtcamp.com mail is handled by 10 test.rtcamp.com.

As you can see mails for test.rtcamp.com is handled by test.rtcamp.com only (same server).

If you are using Google Apps, you will see outcome like:

rtcamp.com mail is handled by 30 alt2.aspmx.l.google.com.
rtcamp.com mail is handled by 10 aspmx.l.google.com.
rtcamp.com mail is handled by 20 alt1.aspmx.l.google.com.
rtcamp.com mail is handled by 50 aspmx3.googlemail.com.
rtcamp.com mail is handled by 40 aspmx2.googlemail.com.

If you do not see “mail is handled” line, that means your domain do not have a MX record.

This is also fine as long as your do not want to handle incoming emails for a particular domain. You do NOT need MX records to send domain from a particular emails.

How multiple domains works then!

First question I was asked when we were writing this series was – if reverse-PTR to IP and IP to FQDN is must, how multiple domains works. Specially under shared-hosting scenario.

A short answer is – on shared hosting, even you send mail FROM your domain, in mail headers, FQDN (machine’s unique names) gets appended for which reverse-PTR is correctly mostly. As long as FQDN & Reverse-PTR are perfect, mails will work most likely. This is like first-check, not the only check!