Ask two different DNS questions
An MX check asks where mail addressed to a domain should be delivered. A reverse-DNS check asks which hostname is associated with an IP address, followed by whether that hostname resolves back to the relevant address. Neither question measures the sender's reputation or proves message authentication. Keeping them separate prevents a common error: inspecting a domain's inbound gateway and assuming it is also the server that sends its application mail.
This is an interpretation guide with a deliberately fictional DNS fixture, not a working checker or a live domain report. No lookup or SMTP connection was executed. An implemented checker would need explicit inputs, recorded observations, expected-result tests and explanations for incomplete answers before its output could support an operational decision.
Interpret the receiving route through MX
An MX resource record contains a preference value and an exchange hostname. Lower preference values are tried before higher ones; they are not percentages or a guarantee that a particular server will accept a message. RFC 1035 defines the record, and RFC 5321 explains SMTP target selection. Preserve every relevant MX record and the address-resolution results for its targets.
Distinguish a usable receiving route from a mere answer. An MX target needs appropriate address records; a target presented as a CNAME is not a valid substitute under the SMTP target-resolution rules. An unreachable address, temporary DNS failure or unavailable SMTP service requires a different explanation from a malformed MX. Do not infer transport availability from DNS alone.
No MX answer does not always mean a domain cannot receive mail. SMTP can use an implicit MX under the conditions in RFC 5321, whereas RFC 7505 defines an explicit null MX: preference zero with the root name as exchange. A null MX announces no receiving service and must not coexist with other MX records. Keep that intentional state distinct from missing data and from a broken receiving configuration.
Start reverse DNS from the actual sending address
Identify the public IP that connected to the receiver for the message under investigation. A company's website address, inbound MX address and outbound service address may all differ. With an outsourced platform, the relevant reverse-DNS owner may be the service or IP-space operator rather than the organization that controls the visible From domain.
Inspect the PTR answer for that address and then resolve its hostname in the corresponding address family. For personal Gmail delivery, Google's sender guidance requires the sending server's public IP to have matching reverse and forward DNS. That is receiver-specific published guidance, not a guarantee of acceptance by Gmail or every other provider. Record the checked IP and hostname so another operator can reproduce the relationship.
A PTR hostname does not have to be interpreted as the visible From domain, a DKIM signer or proof that the organization authorized the message. These identities serve different purposes. SPF evaluates its specified envelope identity and source, while DMARC depends on aligned authenticated identifiers. A successful forward-and-reverse match cannot replace either evaluation.
Read a minimal fictional fixture
Suppose the invented domain inbound.example has an MX record with preference 10 pointing to mx.inbound.example, whose A record is 192.0.2.10. The expected answer to the proposed MX query identifies that exchange; the expected A answer supplies its receiving address. These documentation names and addresses are an authored fixture, not captured output. The dependency illustrated is inbound SMTP routing for recipients at inbound.example.
Separately, suppose an invented outbound server uses 192.0.2.25. The expected PTR answer for 25.2.0.192.in-addr.arpa points to outbound.example, and the expected A answer for outbound.example includes 192.0.2.25. This illustrates a forward-confirmed reverse-DNS relationship for that sending address. It does not establish an MX relationship, a positive reputation or successful delivery.
An implementation should also test a PTR pointing to a hostname whose forward answer omits the original address, a null MX, an implicit-MX case and a temporary resolver failure. Specify the intended result before running each fixture. Do not change a real PTR or MX merely to make a diagnostic display look green.
Preserve errors rather than manufacturing certainty
Store the exact query name, type, server or resolver, observation time, response status and relevant sections. An empty answer can accompany an alias, referral or negative response; RFC 2308 explains distinctions that a checker must retain. A timeout or SERVFAIL cannot be relabeled as proof that no record exists. Cached and authoritative answers can differ without either being a transcript of what a previous receiver saw.
Report routing findings, reverse-DNS consistency, authentication and reputation as separate dimensions. If a provider rejects a message, retain its complete diagnostic, timestamp and route alongside the DNS evidence. A blocklist result, an SPF failure and an MX misconfiguration require different owners and remedies. DNS conformity can remove one obstacle while complaints, content, compromised accounts or receiver policy continue to affect delivery.
Define the useful result and the remaining gate
A trustworthy output names the dependency tested, the observation supporting it and the next approved verification step. For an inbound-route issue, that might mean confirming the intended exchange with the mail operator. For reverse DNS, it may mean asking the address-space owner to review the observed mismatch. Neither step authorizes publishing changes or sending test mail automatically.
The exact original-evidence requirement remains open: A minimal DNS example with expected query response and the specific mail dependency it supports. The fictional fixture supplies an illustrative design, not an executed acceptance result. The separate intake also requires implementation and testing of the promised function. Until actual observations and working-checker evidence exist, retain the page's guide label and do not represent it as a diagnostic service.