An SMTP scanner may report that the server's banner does not match reverse DNS. That finding deserves interpretation, not an automatic conclusion that the server is spoofing mail. Identify which address was tested, which name the scanner expected and whether it observed an inbound service or the outbound route used for real messages.
Name the identities being compared
The server's initial SMTP greeting identifies the service reached by the client. The client's EHLO argument identifies the connecting client for that SMTP conversation. A PTR record maps an IP address to a reverse-DNS name. Forward DNS maps a name to addresses. These are separate observations and can involve different machines or administrative owners. RFC 5321 sections 4.1.1.1 and 4.2.
An inbound gateway's greeting does not necessarily describe the host used for outbound delivery. Load balancing, network address translation and separate sending pools complicate that comparison. Record the exact tested address and role before asking a DNS administrator to make a name match. Otherwise, a cosmetic fix can target a system unrelated to the original delivery complaint.
Check what the protocol actually requires
RFC 5321 describes the preferred domain-name identification in greetings and EHLO, and it allows address literals in specified situations. It also says a receiver must not refuse a message solely because verification of the EHLO parameter does not match the client IP address. That does not remove a receiver's other security or operational policy decisions, nor guarantee acceptance at every provider.
Do not turn a provider's documented DNS expectations into a universal protocol rule. Some receiving services apply explicit forward and reverse-DNS requirements to senders. A provider-specific rejection should be investigated against that provider's current first-party guidance and the actual connecting IP. This article does not assert that all receivers implement the same PTR checks.
Build the comparison record
Capture UTC time, connecting IP, recipient-facing MX or service role, raw greeting, EHLO value, PTR answer and the forward lookup for the PTR name. Keep missing answers, multiple names and resolver errors distinct. If an outbound address is supplied by a hosting provider, determine who controls its PTR delegation; editing an unrelated zone may not change reverse DNS.
Compare a real rejected transaction with an accepted controlled transaction when available. The complete rejection text matters more than a generic scanner warning. If mail already flows normally and the scanner offers no applicable rule, classify the finding as an identity-hygiene question rather than claim a proven delivery outage.
Map a hypothetical split mail architecture
Suppose a scanner connects to inbound.example and records its server greeting. A real outbound transaction, however, leaves through send.example with EHLO send.example. Its connecting address has a PTR pointing to send.example and a forward lookup returning that address. The scanner's inbound banner and the outbound client's name describe different systems, so their difference alone does not demonstrate a defect.
A signature with d=brand.example would be another independent identity. Its validity needs actual DKIM verification; PTR agreement cannot supply that result. Likewise, DMARC needs its own aligned authentication evidence. These are hypothetical values, not queried DNS, captured SMTP or executed cryptographic verification.
For an actual rejection, assemble one record for the real connecting IP and relevant provider requirement. If the provider complaint names reverse DNS, resolve the intended PTR with the address-space owner. Do not edit the inbound banner merely because it was the first name a scanner displayed.
Remediate under the correct ownership
Where a genuine configuration inconsistency exists, coordinate the service identity and forward and reverse DNS with their respective owners. Preserve the old values, TTLs and affected sending pools. After the approved change, query the actual address again and repeat the originally failing controlled transaction.
Keep SPF, DKIM and DMARC checks separate. A matching PTR name does not establish their pass results or alignment with the visible From domain. Close only the verified naming or delivery defect, and retain unresolved provider-policy questions rather than presenting a cosmetic banner match as comprehensive authentication.
Compare names with the correct role
- Server greeting: identify the inbound endpoint actually tested.
- Client EHLO and connecting IP: identify the outbound transaction in question.
- PTR and forward answers: preserve timestamps and the address-space owner.
- Provider refusal: obtain its exact diagnostic and current requirement.
- Closure: verify the affected naming or delivery issue without claiming DKIM or DMARC from PTR.