Reverse DNS and your sending server

Module 5: Reputation and the major providers · Reading time: 9 minutes

Learning objective: After this lesson, you can explain why the IP address of the server that sends your mail needs a proper reverse DNS, work out which server that is for you, and check that forward and reverse DNS match.

Key concepts: sending server, PTR record, forward-confirmed reverse DNS (FCrDNS), HELO/EHLO name, generic name, shared hosting, own server (VPS), owner of the IP block

Which server actually sends your mail?

Module 4 was about your domain: SPF, DKIM and DMARC live in the DNS of example.com. In this module we look at something different: the server that delivers your mail to the recipient. That server has an IP address, and recipients judge that address separately from your domain.

Which server that is depends on how you send mail:

You can find the IP address of the sending server in the headers of a mail you sent to yourself or to another address (lesson 1.5). Look at the top Received: line added by the receiving server. It looks something like:

Received: from smtp.hosting.example (smtp.hosting.example [192.0.2.25])
        by mx.example.net with ESMTPS id 4f2a...

The address between the square brackets, 192.0.2.25, is the IP address the sending server connected from. The name in front of it (smtp.hosting.example) is the name the recipient found for that address via reverse DNS.

Reverse DNS in brief

Reverse DNS links an IP address back to a name, using a PTR record. You learnt the basics in the DNS course (lesson 4.6): the record doesn't live in your domain's zone but in the reverse zone of the IP address, which belongs to whoever manages that IP block.

For email, three things matter:

1. There is a PTR. An IP address without reverse DNS looks like a random machine on the internet. Gmail rejects such mail with the message 550 5.7.25 ... the sending IP address doesn't have a PTR record.
2. The name points back to the same address. IP address 192.0.2.25 has PTR smtp.hosting.example, and smtp.hosting.example has A record 192.0.2.25. This is called forward-confirmed reverse DNS (FCrDNS). Gmail, Yahoo and T-Online explicitly mention this in their requirements.
3. The name looks like a mail server. A name like 192-0-2-25.dsl.provider.example or host25.dynamic.provider.example gives away a home or customer connection. Spam filters penalise this, or reject the connection straight away.

Everything applies again for IPv6. If a server sends over IPv6, the IPv6 address also needs a PTR, pointing back with an AAAA record. A server that's set up correctly for IPv4 but not for IPv6 runs into trouble especially with Gmail: Google lists a missing IPv6 PTR as a cause of an "IPv6 authorization error".

The HELO name

When a server connects, it introduces itself with EHLO (or the older HELO) and a name (lesson 1.2). RFC 5321 says this should be the server's full name. In practice, recipients check whether that name:

• is a real, existing name (not localhost, not a bare IP address, not a name that isn't in the DNS);
• matches the reverse DNS, or at least belongs to the same domain.

With a hosting package or mail service, the administrator takes care of this. If you run your own mail server, you set the HELO name in your mail software (in Postfix this is called myhostname) and make sure that name, the PTR and the A record all match.

Shared hosting: the PTR doesn't have to be your domain

A frequently asked question: "Shouldn't the reverse DNS be mail.example.com, since that's my domain?" No. With shared hosting and with large mail services, one server sends mail for hundreds or thousands of domains. An IP address can only have one PTR, so it contains the name of the server itself, for example server12.hosting.example.

That's exactly as it should be. Recipients check whether the PTR exists, points back correctly, and isn't generic. They don't check whether your own domain name appears in it. You create the link between your domain and the server with SPF (the server is listed in your SPF) and DKIM (the server signs on behalf of your domain).

At WebOké, for example, this is arranged as follows: the servers of a hosting package have a reverse DNS with the name of the server itself, under webawere.nl, which in turn points back correctly. Other hosting providers and mail services work the same way, with their own server names.

Your own server: what do you need to arrange?

If you send mail directly from your own server, for example a VPS with a webshop or your own mail server, you're the sender yourself and need to arrange more:

1. Choose a name, for example mail.example.com.
2. Create the A record (and AAAA record) for that name, pointing to the server's IP address, in your domain's DNS.
3. Request the PTR from the server's provider. Usually there's a field called "Reverse DNS" or "rDNS" in the customer panel. Enter the same name there.
4. Set the HELO name of your mail software to that same name.
5. Add the IP address to your SPF record (ip4: and ip6:) and enable DKIM in your mail software.
6. Check whether outgoing port 25 is open. Many providers close it by default to prevent abuse; in that case you'll need to have it opened, or send via a relay from your provider or a sending service.

A mail server on an ordinary home or office internet connection is almost always a bad idea. Those addresses are often listed as "end-user addresses" (such as the Policy Block List from Spamhaus, lesson 5.2), you usually can't choose your own PTR, and T-Online explicitly requires that such systems send via a relay from a suitable provider.

Checking it yourself

Using a command window (DNS course lesson 8.2):

dig -x 192.0.2.25 +short
smtp.hosting.example.

dig A smtp.hosting.example +short
192.0.2.25

If the second query returns the same address, FCrDNS is correct. For IPv6, do the same with dig -x 2001:db8::25 and dig AAAA.

You can also see how a recipient saw it. In the headers, the receiving server puts the name it found in brackets after from. If it says unknown, it didn't find a PTR. Some servers also add their own check, such as iprev=pass in the Authentication-Results: line (RFC 8601).

Summary

• The sending server is the server that delivers your mail to the recipient. Recipients judge its IP address separately from your domain.
• That IP address needs a PTR that points back to the same address (FCrDNS), for both IPv4 and IPv6, with a name that isn't generic.
• The HELO name should be an existing name that matches the PTR.
• With shared hosting and mail services, the PTR contains the server's name, not your domain. That's correct.
• With your own server, you arrange the name, A/AAAA, PTR (via your provider), HELO, SPF and DKIM yourself.

Quiz

Exercise

Exercise Z5.1: The sending server for your own domain. Send a mail from your own address to another address of yours (for example a Gmail or Outlook.com address) and open the headers. Find the IP address of the server that delivered the mail, the PTR name of that address, and note whether the name points back to the same address (yes/no). If you don't have your own domain, use the IP address of the mail server mx00.t-online.de. The program looks up the PTR and the A/AAAA record live and compares them.

Further reading

The steps in these articles apply to WebOké's panels; with other providers it works in a similar way.

• Sending mail from your VPS and setting up reverse DNS
• Free DNS course 4.6: Reverse DNS (PTR): from number back to name
• How sending email works / SMTP
• RFC 5321 (SMTP), section 4.1.1.1 on the EHLO name; RFC 8601 on the Authentication-Results header