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 (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 (a subdomain we used for test mail server setup)

Check FQDN by running following command on server:

hostname -f


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, then at DNS create an “A” record for subdomain “mail” poiting to your server’s IP address.

You can use 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:


You will see lines like below: has address mail is handled by 10

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

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


Outputs: domain name pointer

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 the end:

dig +short ptr

You will output like:

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:


You will see lines like below: has address mail is handled by 10

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

If you are using Google Apps, you will see outcome like: mail is handled by 30 mail is handled by 10 mail is handled by 20 mail is handled by 50 mail is handled by 40

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!