PTR, reverse DNS and HELO: requirements for your own mail server

If you send mail through an external platform, you rarely have to worry about the server's identity: the provider takes care of it. If you run your own mail server, for a company, an application or a personal project, you have to look after a few details that receivers check before they even look at SPF, DKIM or content. They are old, simple checks, and for that very reason almost everyone applies them.

The PTR record and reverse DNS

Ordinary DNS translates a name into an address: mail.example.com becomes 198.51.100.20. Reverse DNS does the opposite: given the address, it returns a name. That mapping is a PTR record, and what makes it special is that it is managed not by the domain owner but by whoever owns the IP block: the connectivity provider, the host or the cloud.

You check it like this:

dig +short -x 198.51.100.20
mail.example.com.

A server that sends mail without a PTR, or with a generic one like those providers assign automatically, containing the IP itself and words such as «dynamic» or «pool», is treated with suspicion. Many receivers reject the connection outright, and some large providers list a valid PTR among the requirements for all senders.

Forward and reverse match

It isn't enough for the PTR to exist. The name it returns must in turn resolve to the same address:

When both directions match, we speak of forward-confirmed reverse DNS, often abbreviated FCrDNS. This is the check filters actually apply. The same principle holds for IPv6: every IPv6 address the server sends from needs a matching PTR and AAAA record. A server sending over IPv6 without this configuration is a frequent cause of sudden rejections, because providers tend to be stricter precisely on IPv6.

The HELO or EHLO name

At the start of every SMTP session the sending server introduces itself with the EHLO command, followed by a name. That name should:

1. be a fully qualified domain name, not an internal name like localhost or server01;
2. resolve to the IP the connection comes from;
3. ideally match the IP's PTR.

The cleanest setup is one where PTR, HELO name and A record tell the same story: one IP, one name, in both directions. The chosen name doesn't have to match the From domain. A server can send for many different domains; what matters is that its technical identity is consistent.

Other basic checks

Outbound TLS

Receivers record whether the connection is encrypted, and some sender dashboards show the share of traffic received over TLS. The server should offer STARTTLS on outbound connections too, with a valid certificate for the server's name. It is a configuration everyone now expects.

The type of IP

Addresses from home connections and many consumer services are unsuitable for direct sending. They are often included in lists flagging residential IPs, and many providers block outbound port 25. In these cases the correct solution is to send through an authenticated relay, a service that receives mail from your server and delivers it from IPs with their own reputation.

In public clouds, too, outbound port 25 is often blocked by default and must be explicitly requested; some providers don't allow it at all.

Postmaster and abuse

It is good practice for the server's domain to have working, monitored postmaster and abuse mailboxes. These are the addresses other administrators write to when something goes wrong, and some tools also use them to verify who is responsible for an IP.

A checklist

Before putting your own mail server into production, check:

• PTR set by the provider to a meaningful name, for IPv4 and IPv6;
• A and AAAA records for that name pointing to the same addresses;
• HELO name equal to the PTR;
• STARTTLS enabled with a valid certificate;
• outbound port 25 available, or a relay configured;
• IPs absent from the main blocklists;
• SPF, DKIM and DMARC configured for every domain served;
• postmaster and abuse mailboxes active.

In my work I often find servers carefully configured on the software side but with the PTR left at the provider's default. It is the quickest fix and one of the most effective.

In short

• The PTR is managed by whoever owns the IP and must point to a meaningful name.
• The PTR name must resolve to the same IP: that is forward-confirmed reverse DNS.
• The HELO name must be a fully qualified name consistent with the PTR and A record.
• IPv6 needs the same configuration, which is often forgotten.
• From residential IPs or without port 25, send through an authenticated relay.