Mail server without reverse DNS

A legitimately operated mail server is part of an address block someone administers deliberately, and a reverse record is evidence of that administration.

Compromised machines sending mail from consumer connections typically have no reverse record, or a generic one assigned by the provider.

The check is cheap — one DNS query — and it filters a meaningful share of unwanted mail before any content is examined.

Some receivers go further and require the forward and reverse names to agree, which is a stricter policy applied inconsistently.

None of this is standardised as a requirement, which is why the consequence varies from a small penalty to an outright refusal.

Reverse DNS is delegated by address block, so the record is published by whoever was allocated the addresses — usually the hosting provider.

Which means it is not in your DNS zone and not editable in your DNS provider's interface.

Most providers expose it as a setting on the server or the address, and some require a support request.

On a managed mail platform the provider handles it, and it is one of the reasons using one removes a category of problems.

On a self-hosted server on a cloud address, it is a configuration step that is easy to miss because nothing fails immediately.

Each sending address has a reverse record naming a hostname you control.

That hostname resolves forward to the same address, which satisfies the receivers applying the stricter check.

The name is specific rather than generic — a provider's default naming pattern is technically a record and carries little of the signal.

The same name is used in the SMTP greeting, which is a third consistency some receivers check.

For addresses that only receive, the record matters far less: the check is applied to the connecting server, which is the sender.

It is independent of SPF, DKIM and DMARC, and it is checked earlier — at connection time rather than after the message arrives.

So a domain with perfect authentication can still have mail refused by a receiver that rejects on missing reverse DNS.

It is also address-based rather than domain-based, which means it follows the sending infrastructure rather than the domain.

Moving to a new server or a new address re-raises the question, and it is a common cause of delivery problems immediately after a migration.

`dig +short MX example.com` to list the exchangers, then resolve each to an address.

`dig +short -x <address>` returns the reverse record; an empty answer is the defect.

Resolve the returned name forward and confirm it comes back to the same address, which is the stricter check.

Check the addresses that send, which on many setups are not the same as the ones that receive.

Read the authentication and connection details in the raw headers of a message you sent, which show what the receiver observed.

`email.mx.ptr` reports whether the addresses of the published exchangers have a reverse DNS name.

`dns.ptr` reports reverse records for the site's own addresses, which is the same mechanism applied to the web infrastructure.

`email.mx.present` and `email.mx.resolution` establish the exchangers whose addresses are then checked.

`email.spf.ptr` is separate and unrelated: it reports the deprecated reverse-lookup mechanism inside an SPF record, which is a different thing with a similar name.

A sending server identifies itself by name at the start of the SMTP transaction, before any message is transmitted.

Receivers that check reverse DNS frequently compare that name against it, so three things are expected to agree: the greeting, the reverse record and the forward resolution.

A default greeting left at the machine's internal hostname is a common mismatch, and it is a server configuration rather than a DNS one.

An address-literal greeting, or one naming a hostname that does not resolve, is penalised by the same receivers for the same reason.

None of this is visible in the message headers a recipient sees, which is why it is diagnosed from the receiving server's logs rather than from the mail itself.