A reverse lookup returns a claimed hostname for an IP address. Forward-confirmed reverse DNS then checks whether that hostname resolves back to the original address. The second step catches a common inconsistency, but a match does not establish that the sender is trustworthy or authorized to use a message's From domain.
Define the comparison
References: RFC 1912 §2.1, RFC 3596 §2.1, RFC 4291 §2.2.
Take the observed SMTP source address as the starting value. Query its PTR record. For each returned hostname, query the appropriate forward address type: A for an IPv4 source and AAAA for an IPv6 source. Compare the address values, using an IP parser for IPv6 so equivalent textual forms are treated alike.
For this guide's diagnostic, confirmation means that at least one returned hostname's forward address set contains the original IP. Preserve per-host results as well as that summary. This is an explicitly defined diagnostic rule, not a promise that every receiver implements the same selection policy or checks every PTR result.
Keep failures distinct
References: RFC 1035 §4.1.1, RFC 2181 §10.2.
No PTR answer, a hostname with no matching address, a DNS timeout and a validation failure are different findings. A timeout cannot prove the record is absent. An IPv4 A match does not establish confirmation for an IPv6 source. Retain response codes and timing rather than collapsing all outcomes into a single red badge.
Do not stop at the first address returned for a hostname. A host can have several addresses, and the original address may be later in the set. Nor should a dashboard silently discard multiple PTR names. The underlying results are needed to explain exactly what matched.
Calculate a synthetic test set
Case A starts at 192.0.2.25. PTR returns smtp.example.com; that name's A set is 192.0.2.24, 192.0.2.25. Expected result is confirmed, because the original address is a member of the set. Equality with the entire set is not required.
Case B uses the same PTR but the A set contains only 192.0.2.24. Expected result is mismatch. Case C receives a timeout on the forward lookup. Expected result is unresolved, not mismatch. Case D starts at 2001:db8::25 and the target's AAAA answer is 2001:0db8:0000:0000:0000:0000:0000:0025. Expected result is confirmed after normalizing both as IPv6 addresses.
Reproduce these cases with a fixture resolver or isolated zones. For each case, store source IP, PTR response, forward response, query type and the computed membership result. A simple implementation parses each address and evaluates whether the source is in the returned set, while handling DNS errors before that membership step. These expected results do not claim that any production receiver has been tested.
Repair the owner’s side of the mismatch
References: RFC 1035 §3.5, RFC 8767 §4.
If the PTR is wrong, work with the reverse-zone operator. If the forward address is wrong, work with the hostname's authoritative DNS operator. If both are correct at authority but not at a resolver, investigate caching or differing views. Keep evidence for both directions at the same time so a sequential change is not misdiagnosed as a persistent inconsistency.
Finally, test the actual SMTP route and retain any receiver response. Forward confirmation is a consistency property of DNS data. Attackers can operate matching forward and reverse records, and a legitimate provider can still have a broken configuration. Use the finding alongside, not in place of, authentication and abuse controls.
Keep the evidence scope explicit
The four synthetic cases can be checked by address membership and normalization alone: confirmed, mismatch, unresolved and confirmed. The local calculation does not perform PTR or forward lookups, exercise a receiver or measure reputation.