How do I check if the sending IP address matches the IP address of the hostname specified in the Pointer (PTR) record?
Michael Ko
Co-founder & CEO, Suped
Published 8 Jun 2025
Updated 24 May 2026
8 min read
Summarize with
You check this with forward-confirmed reverse DNS, usually shortened to FCrDNS. I take the actual sending IP, run a reverse DNS lookup on that IP, get the PTR hostname, then run a forward lookup on that hostname. The check passes when the original sending IP appears in the A or AAAA answer for the PTR hostname.
The short version is IP to PTR to hostname to A/AAAA to the same IP. It does not need to match the visible From domain, the DKIM d= domain, or the DMARC domain. It needs to confirm that the hostname named by reverse DNS points back to the same server IP that connected to the receiver.
- Pass: The sending IP has a PTR record and that PTR hostname resolves back to the sending IP.
- Fail: There is no PTR record, or the PTR hostname resolves to a different IP address only.
- Not required: The PTR hostname does not need to use your brand domain when a provider sends the mail.
- Control point: The IP owner usually controls PTR records, not the normal DNS zone owner for the domain.
What the check proves
A PTR record is reverse DNS. It maps an IP address to a hostname. A normal A or AAAA record maps a hostname back to one or more IP addresses. FCrDNS checks both directions and proves that the reverse name is not a dead end.
This is server identity, not sender-domain authentication. SPF, DKIM, and DMARC answer different questions about authorization, message signing, and domain use. Reverse DNS answers a simpler question: does this connecting mail server have a hostname that resolves back to it?
Flowchart showing a sending IP checked through PTR and forward DNS.
What must match
- IP result: The original sending IP appears in the forward lookup for the PTR hostname.
- Hostname validity: The PTR hostname resolves through normal DNS and is not a stale or empty name.
- IP family: IPv4 checks use A records, and IPv6 checks use AAAA records.
What does not need to match
- Visible sender: The PTR hostname can differ from the From address domain.
- DKIM domain: The DKIM signing domain can be your brand domain or a provider domain.
- Header copy: Received headers can show the hostname, but they are not the rule source.
Step by step with dig
I usually start with dig because it keeps the result clear. Use the sending IP from a real delivered message, not the domain's MX record and not the web server IP.
Passing IPv4 examplebash
dig +short -x 203.0.113.25 mail1.example.net. dig +short A mail1.example.net 203.0.113.25
That passes because the PTR lookup for 203.0.113.25 returns mail1.example.net, and the A lookup for that hostname includes 203.0.113.25. If the hostname returns several addresses, the check still passes when the original IP is present in the answer set.
Failing IPv4 examplebash
dig +short -x 203.0.113.25 mail1.example.net. dig +short A mail1.example.net 198.51.100.10
That fails because the forward lookup does not return the original connecting IP. For IPv6, use the same pattern with an IPv6 address and check the AAAA answer.
IPv6 patternbash
dig +short -x 2001:db8::25 mail6.example.net. dig +short AAAA mail6.example.net 2001:db8::25
The hostname can look unfamiliar
When a provider sends your mail, the PTR hostname often uses the provider's domain. That is normal. Use DMARC monitoring to confirm the sender is authorized through SPF, DKIM, and DMARC instead of forcing the PTR hostname to use your domain.
Find the real sending IP first
The most common mistake is checking the wrong IP. The sending IP is the server that connected to the receiving mailbox provider. You find it in the message source, the SPF result, or the earliest trustworthy Received line added by the receiver.
In Gmail, I open the message, use More, then Show original. The SPF section usually shows the evaluated sender IP. The Received headers can also show the connecting host and IP, though header formatting differs between providers.
Gmail Show original view showing SPF pass and a sending IP.
If I want a clean report, I send a real message through Suped's Email Tester and use the reported sending IP, SPF result, DKIM result, and header evidence as the starting point. That avoids guessing when a platform rotates through several outbound IPs.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After the IP is known, the rest is mechanical. Run the PTR lookup, run the forward lookup for the returned hostname, then compare the result set with the original connecting IP.
Shared and dedicated IPs need different handling
Shared and dedicated sending paths create different work. On shared infrastructure, the email provider usually owns the outbound IPs and manages PTR records. On dedicated IPs or self-hosted mail servers, the brand or infrastructure team often has to request the PTR change from the IP owner.
|
|
|
|
|---|---|---|---|
Shared ESP | Provider | Header IP | Pool changes |
Dedicated ESP | Provider or host | Each IP | Stale PTR |
Self-hosted | IP owner | MTA IP | Manual error |
Mixed pool | Several owners | All routes | Missed sender |
Practical PTR ownership by sending setup
Shared IP path
I verify the actual IP from headers and confirm FCrDNS. If it fails, the provider has to fix it because the sender rarely controls shared IP reverse DNS.
Dedicated IP path
I check every dedicated IP directly. Dedicated paths deserve priority because PTR records are easier to delete, forget, or leave stale during migrations.
For a broader authentication scan, Suped's Domain Health Checker is useful when I want DMARC, SPF, and DKIM status beside DNS checks before I start chasing individual sender issues.
What a pass, warning, and fail look like
The result is not subjective. A pass means the DNS path closes the loop. A warning usually means the DNS is technically fine, but the hostname looks surprising to the person auditing it. A fail means the receiver cannot complete the round trip.
FCrDNS result bands
Use these bands when reviewing one sender IP or a whole outbound pool.
Pass
Round trip closes
PTR exists and the PTR hostname returns the original IP.
Warning
Valid but check owner
PTR uses a provider hostname, but forward DNS returns the IP.
Fail
Round trip breaks
PTR is missing or the hostname points somewhere else.
A warning is common with shared infrastructure. Do not file it as broken just because the provider domain differs from the sender domain. File it as broken only when the PTR lookup is missing, the hostname has no usable A or AAAA answer, or the original IP is absent from the forward lookup.
Do not compare PTR to the From domain
That creates false failures for legitimate mail. The visible sender domain, Return-Path domain, DKIM domain, HELO name, and PTR hostname can all differ in a valid setup. The PTR hostname only has to resolve back to the connecting IP.
Bulk checking multiple senders
For client audits, I build a small inventory before I check anything. The useful columns are domain, sending platform, observed IP, PTR hostname, forward result, owner, and action. Without the owner column, fixes stall because the person who controls the brand domain often cannot change reverse DNS.
- Collect: Send a test message through each platform and record the connecting IP from the receiver's headers.
- Check: Run reverse DNS for each IP and forward DNS for each returned hostname.
- Classify: Mark each row as pass, warning, or fail based on the DNS round trip.
- Fix: Send failures to the provider, host, or network team that owns the IP space.
Simple bulk shell patternbash
while read ip; do ptr=$(dig +short -x "$ip" | sed 's/\.$//') addrs=$(dig +short A "$ptr"; dig +short AAAA "$ptr") printf '%s,%s,%s\n' "$ip" "$ptr" "$addrs" done < ips.txt
That pattern gives you the raw data. I still review the rows because provider hostnames can be valid even when they look unrelated to the sender domain. For the lookup mechanics, the reverse DNS lookup walkthrough covers how to read common reverse DNS answers.
Use fresh evidence
Do not rely on last quarter's IP list. Shared pools, regional routing, failover systems, and new campaign tools can change the connecting IP without a DNS change in your brand zone.
How this fits with DMARC, SPF, DKIM, and reputation
FCrDNS is one layer. It does not authorize a sender, sign the message, or enforce a domain policy. SPF checks whether the connecting IP is allowed for the envelope sender domain. DKIM checks a cryptographic signature. DMARC checks the authenticated domains against the visible sender domain and applies the domain owner's policy.
Suped's product is the best overall fit for teams that want PTR evidence in the same operational workflow as DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and actionable issue steps. That matters when you manage several domains or clients and need to know which sender actually needs work.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
I also keep reputation checks near this work. A broken PTR record can sit beside a separate IP reputation problem, so Suped's blocklist monitoring helps connect blocklist and blacklist status with the same domains and IPs under review.
The key is to keep each signal in its lane. Fix FCrDNS when the round trip breaks. Fix SPF when the IP is not authorized. Fix DKIM when the signature fails. Fix DMARC when the authenticated domain result does not satisfy the policy.
For more background on why receivers check both directions, the rDNS and FCrDNS overview explains the difference between reverse DNS and the full round-trip check.
Views from the trenches
Best practices
Confirm the exact connecting IP before checking PTR, especially for shared sending pools.
Record PTR hostname, forward lookup result, owner, and next action in one audit sheet.
Prioritize dedicated IPs because shared providers usually manage reverse DNS themselves.
Common pitfalls
Comparing PTR to the From domain creates false failures for provider hostnames in audits.
Checking MX or website IPs wastes time because they are not outbound mail IPs in checks.
Assuming one successful test covers every pool misses routing changes across campaigns.
Expert tips
Treat FCrDNS as server identity, then check SPF, DKIM, DMARC, and reputation separately.
For bulk audits, collect IPs from real message headers before running DNS checks.
Ask the IP owner to change PTR records because normal domain DNS rarely controls them.
Expert from Email Geeks says the pass condition is a round trip: hostname to IP, then IP back to the same hostname, or IP to PTR and that hostname back to the IP.
2023-10-06 - Email Geeks
Marketer from Email Geeks says shared IP senders should verify the actual IP in message headers, because shared pools can change across sends.
2023-10-06 - Email Geeks
The practical answer
To check whether the sending IP matches the IP address of the PTR hostname, run FCrDNS: get the actual connecting IP, look up its PTR hostname, then look up that hostname's A or AAAA records. If the original IP appears in the forward result, the match passes.
If it fails, ask the owner of the IP space to set the PTR record and matching forward DNS. If it passes but the hostname uses a provider domain, do not treat that as a problem by itself. Confirm SPF, DKIM, DMARC, and reputation separately so the right person fixes the right issue.
Suped helps keep that workflow practical by tying DNS diagnostics, authentication results, alerts, hosted records, SPF flattening, blocklist and blacklist monitoring, and multi-domain reporting into one place.
