The machine layer: reverse DNS, PTR records, HELO, and TLS

Before a mailbox provider evaluates your authentication, consults your reputation, or reads a word of your message, it inspects the machine that connected to deliver it. The connecting IP needs a reverse DNS entry, a PTR record, that resolves to a hostname. That hostname needs to resolve back to the same IP. The machine should introduce itself with a name that matches reality, and the connection should be encrypted. All of this happens in the opening seconds of the delivery conversation, and Gmail's sender guidelines have turned the first part into a hard requirement: no valid PTR record, no mail to Gmail.

How spam filters decide put acceptance at the SMTP door first in the layered decision, before any scoring and before any per-user placement. The machine layer is most of what that door examines. A receiver that distrusts the machine never gets as far as your carefully authenticated, well-written campaign; the message is refused, or quietly deprioritized, on the strength of the handshake alone.

DNS in reverse

Ordinary DNS answers the question "what IP address does this name point to". An A record maps mail.example.com to 203.0.113.41. A PTR record is the same lookup run backwards: it maps 203.0.113.41 to a hostname. The forward map lives in your domain's DNS zone, where you can edit it. The reverse map lives in a separate zone that belongs to whoever owns the IP address block (it sits under in-addr.arpa for IPv4 and ip6.arpa for IPv6, two of the internet's older and stranger corners), and only the IP's owner can write to it.

That ownership detail matters more than it sounds. You cannot fix a missing PTR record at your registrar, because it is not your zone; the hosting provider, ISP, or ESP that owns the address has to set it.

Receivers don't stop at the reverse lookup. The full test is called forward-confirmed reverse DNS, FCrDNS for short: look up the PTR for the connecting IP, get a hostname, then look up that hostname's A or AAAA record and check that it returns the original IP. A round trip. The reason for the round trip is trust. Anyone who controls a domain can point a hostname at any IP they like, but only the IP's owner can set the PTR, so when the loop closes, the domain side and the IP side are telling the same story, and that is hard to fake.

Gmail wrote it down

For years FCrDNS was a best practice that careful mail admins followed and everyone else ignored. Gmail's Email sender guidelines ended the ambiguity. The current wording: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname", and the same hostname "must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server." That is FCrDNS, spelled out as a requirement, and it sits in the section that applies to everyone sending to personal Gmail accounts, not just bulk senders.

The IPv6 mention is not decoration. A machine can hold a perfectly confirmed IPv4 PTR and still deliver a given message over IPv6, where no PTR exists at all, and the guidelines quote the resulting error themselves: "Message does not meet IPv6 sending guidelines regarding PTR records and authentication." Self-hosted senders trip on this one because the IPv4 side was set up years ago and nobody thought about the other protocol.

The name it announces

There is one more identity in play, and it comes from the machine's own mouth. An SMTP conversation opens with the sending server introducing itself: HELO (or EHLO, the modern extended form) followed by a hostname. That self-declared name gets recorded in the Received header of every message that passes through.

Receivers compare the introduction against everything else in view. A machine whose HELO name matches its FCrDNS hostname looks configured by someone who knew what they were doing. A machine that announces a bare internal name like web-01, or localhost, or a domain it has no relationship with, looks misconfigured at best and dishonest at worst. Inconsistency here is rarely a hard rejection by itself; it is a hygiene signal that adds weight to the wrong side of the scale. Our health check reads it the same way: the message hygiene check compares the HELO name against the machine's actual hostname and flags disagreement.

Encryption on the wire

SMTP is old enough that conversations start unencrypted. STARTTLS is the upgrade step: partway into the handshake, the two servers agree to switch the channel to TLS, the same encryption behind the padlock in your browser. When the upgrade happens, the receiving server notes it in the Received header it stamps on the message, which is why a healthy hop reads with ESMTPS and often names the TLS version, while an unencrypted one reads plain with SMTP.

Unencrypted delivery used to be normal, and mail still technically flows without TLS. But the same Gmail guidelines quoted above list "Use a TLS connection for transmitting email" among the requirements for all senders. Our transport security check walks the Received chain of a real email hop by hop and reports which legs were encrypted, because your machine only controls its own leg and the rest of the path is worth knowing about.

You rent this layer, mostly

If you send through Mailchimp, Brevo, Klaviyo, or any mainstream ESP, everything in this lesson was configured by someone else. The sending machines are the ESP's, the PTR records live in the ESP's reverse zones, the HELO names are theirs, and the TLS support is theirs. This is part of what your monthly fee buys, and the major ESPs get it right.

Which is exactly why this layer fails silently when it fails. You never set it up, so nothing in your world references it: no record in your DNS zone, no setting in your dashboard, no checklist item you once completed and could re-check.

That cuts both ways for us too, so here is the honest version: our domain-only checks cannot see this layer at all. There is nothing published on your domain that names your sending IPs, let alone their PTR status. The machine checks in our catalog (reverse DNS with forward confirmation, TLS hop analysis, HELO consistency) run only when the checker receives a real email from you, because the sending IP is discovered from the Received headers of an actual delivery. A health report without a test email is silent on the machine layer, not passing it.

It changes under you

The decay mechanism here is ownership. This layer belongs to whoever runs the server, and that is almost never you, so it can change without any action of yours. Your ESP migrates you to new sending infrastructure and the new pool's reverse DNS isn't wired the way the old one was. Your company's IT re-images the office relay that sends the invoices, keeps the IP, and the PTR entry an old admin once requested from the ISP quietly stops matching. A hosting provider recycles addresses. In every version, your DNS is untouched, your dashboard is green, and the first symptom is Gmail refusing mail with an error nobody at the company has seen before.

Blocklists work on the same raw material, the sending IP, and they are the next stop: who runs them, how an address ends up listed, and what getting off one takes. That ground belongs to blocklists explained.

Terms from this lesson

• PTR record - the reverse DNS entry mapping an IP address to a hostname; it lives in the IP owner's zone, not in your domain's DNS.
• reverse DNS (rDNS) - the IP-to-name half of DNS, the mirror of the usual name-to-IP lookup.
• forward-confirmed reverse DNS (FCrDNS) - the round trip: IP to PTR hostname, hostname back to the same IP; the test Gmail's guidelines require.
• HELO/EHLO - the opening of an SMTP conversation, where the sending machine announces its own hostname.
• STARTTLS - the mid-conversation upgrade that switches an SMTP connection from plain text to TLS encryption.

Check yourself

1. What makes reverse DNS "forward-confirmed"?

The PTR record has existed for more than a yearThe PTR's hostname resolves back to the same IP the connection came fromThe sending domain's SPF record includes the IPThe hostname in the PTR belongs to a well-known ESP

2. A Received header in a bounced message reads: Received: from unknown (HELO mail-01) (203.0.113.87) by mx.recipient.example with SMTP; 19 Jul 2026 09:14:02 -0000. What does it tell you about the sending machine?

Its IP has no PTR record, it announced a bare internal name, and the connection was not encryptedIts SPF record failed alignmentThe IP 203.0.113.87 is listed on a blocklistThe message body triggered a content filter

3. Your sending IP has no PTR record. Who can fix that?

You, by adding a TXT record at your registrarYou, by editing your domain's MX recordsWhoever owns the IP address: the hosting provider, ISP, or ESP that controls the reverse zoneGmail support, on request

Scenario

A small accounting firm sends invoices from a mail server their IT contractor runs in the office. Last week, invoices to Gmail addresses started bouncing with an error mentioning IPv6 sending guidelines and PTR records. The contractor insists nothing changed on the server, and he is probably right.

What do you do first?

Have them rewrite the invoices to look less promotionalLook up PTR records for the server's public IPv4 and IPv6 addresses, test the forward confirmation on each, and have the ISP or host fix whichever side failsMove the firm onto an ESP todayAsk the contractor to resend the failed invoices

Try it on your own mail

Open a message you sent from your own domain (a newsletter, or a test email to a personal mailbox you control) and view its raw source; most providers have a "show original" or "view source" option on the message menu. Find the Received line where the message entered your mailbox provider's network, and note the IP address in brackets.

Now run the round trip by hand with any online dig tool (search for one; every DNS lookup site offers PTR queries). First, a PTR lookup on the IP: a hostname should come back, and it should look like it belongs to your ESP. Second, an A or AAAA lookup on that hostname: it should return the IP you started with. If both hold, you have verified FCrDNS yourself, the same test our path checks run automatically on every email the health check receives. No sending domain of your own yet? Any newsletter in your inbox works: trace its Received chain instead and grade a stranger's machine layer.