What this analysis does
Enter a public sending IP and optional HELO hostname. Mailybox resolves the PTR, checks whether the resulting hostname maps back to the same address, compares the HELO identity and explains why a hosted ESP can legitimately use a different organizational domain from the visible From address.
For a domain sending from its own IP address, the identity presented at the network layer is checked before any message content is considered. Reverse DNS, forward-confirmed resolution and the HELO name are the three elements receivers evaluate, and they must agree.
Forward-confirmed reverse DNS is the actual requirement
A PTR record alone is not sufficient. Receivers verify that the IP resolves to a hostname and that the hostname resolves back to the same IP. That round trip is forward-confirmed reverse DNS, and it is what prevents an operator from claiming an arbitrary name for an address they control.
The PTR record is published by whoever controls the address block, which is normally the hosting provider rather than the domain owner. Arranging it is a request to that provider, and it is a step frequently discovered late because it cannot be completed in the domain’s own DNS.
- A PTR record must resolve forward to the same address.
- PTR is controlled by the address-block operator, not the domain owner.
- Generic provider hostnames are treated as unconfigured by many receivers.
HELO must be a real, resolvable name
RFC 5321 requires the HELO or EHLO argument to be a fully qualified domain name that resolves to the connecting address. Sending an internal hostname, a bare label or an address literal is a common misconfiguration that receivers treat as a negative signal.
Consistency across the three identities is what receivers reward. The HELO name, the PTR target and the forward resolution should describe the same host. Divergence among them is the pattern associated with poorly maintained or compromised infrastructure.
Default provider hostnames are a liability
Cloud providers assign generic PTR names derived from the address itself. Those names technically satisfy forward-confirmed resolution while signalling clearly that no deliberate mail configuration was performed, and several major receivers treat them as an indicator of unconfigured infrastructure.
Replacing a generic name with a hostname under your own domain is a small change with disproportionate effect, because it moves the sending IP from anonymous infrastructure to identifiable infrastructure with an accountable owner.
Example: HELO that does not match the address
Evidence supplied
A sending IP whose PTR resolves correctly, presenting an internal hostname at HELO.
How to read the result
The audit confirms forward-confirmed reverse DNS and reports the HELO identity as inconsistent, because the presented name does not resolve to the connecting address as RFC 5321 requires.
Known limits
- The analysis reads DNS and does not open an SMTP connection to observe the live HELO exchange.
- PTR changes must be made by the address-block operator and can take time to appear.
- Correct IP-layer identity is necessary but not sufficient for good deliverability.
Common questions
Does this matter when sending through a platform?
No. The platform owns the sending IP and its identity. This applies to organizations sending from their own addresses.
Who publishes the PTR record?
The operator of the IP address block, normally your hosting or transit provider. It cannot be set in your own domain zone.
Is a generic provider hostname acceptable?
It resolves, but several receivers treat it as unconfigured infrastructure. A hostname under your own domain is a meaningful improvement.