Reverse DNS & SPF: Fix Deliverability Issues

Why Does Reverse DNS Matter to Email Deliverability?

You send a message, all the authentication checks pass — SPF, DKIM, DMARC — and yet it lands in spam or vanishes without a trace. Why?

One silent culprit often overlooked is reverse DNS. When the hostname a server presents doesn’t match the domain in its rDNS record, SPF validation fails even if the records are set up correctly.

Receiving servers don’t just check your SPF record — they verify the hostname you claim to be using against what the IP actually resolves to. A mismatch triggers suspicion, and suspicion means rejection.

Key takeaways

Reverse DNS misalignment can break SPF validation even when records are technically correct.
Email receivers use rDNS to validate the HELO or MAIL FROM hostname during SPF checks.
Shared hosting, cloud providers, and dynamic IP pools often lack consistent rDNS, increasing deliverability risk.

What Happens When Reverse DNS Variability Breaks SPF Checks?

You send email from an IP address with inconsistent or missing reverse DNS (rDNS), and even a perfectly configured SPF record fails. SPF validation requires the sending IP, the domain in the HELO/EHLO command, and the rDNS host to match exactly. If any part is missing or mismatched—like a server claiming to be from mail.example.com while the rDNS is set to a different domain—SPF fails. Major providers like Gmail and Outlook now check rDNS as part of their SPF validation, so inconsistent rDNS leads to bounces, poor inbox placement, and damage to sender reputation, regardless of how strong your SPF, DKIM, or DMARC settings are.

How rDNS and SPF Are Linked in Modern Email Delivery

Let’s say your mail server uses IP 198.51.100.20, but the rDNS returns mail.provider.com. If your email says it’s sent from @example.com, SPF checks will look up the SPF record for mail.provider.com. If that record doesn’t explicitly list example.com as an allowed sender, SPF fails—even if your own SPF record for example.com is correct. This mismatch breaks the chain of trust required by modern email filters.

Many large ISPs now treat rDNS consistency as a gatekeeper. A recent report from Spamhaus notes that misconfigured or absent rDNS is among the top red flags in spam filtering systems. Without proper rDNS, even legitimate senders risk being flagged, especially if they’re sending at scale.

Why rDNS Issues Persist and How to Fix Them

rDNS variability often comes from shared hosting environments, proxy servers, or poorly managed infrastructure—where the same IP serves multiple domains, each with different rDNS settings. This creates a confusing identity for the receiving server trying to verify your sender. The result? A failed SPF check, inconsistent delivery, and long-term damage to your sending reputation.

Even if your SPF, DKIM, and DMARC are correctly set up, a broken rDNS chain means the email never reaches the first checkpoint. It’s like arriving at a secure building without a valid ID, even if you know the code to the building. The access control system rejects you before you get to the door.

Verifying your rDNS setup is essential. Use tools like MxToolbox to confirm that your IP addresses have correct forward and reverse DNS entries, and that they match your mail server’s claimed identity. You can test your entire email infrastructure—including rDNS, SPF, DKIM, and DMARC—using an inbox-testing service like MailTester’s inbox placement test. It simulates delivery across real inboxes, so you see exactly how email filters will treat your messages before you send them.

Common Sources of Reverse DNS Variability

Reverse DNS variability happens when the IP address-to-hostname mapping changes unexpectedly or incorrectly. This breaks SPF checks because SPF relies on consistent DNS lookup results. Cloud providers, resellers, and outdated systems often fail to maintain stable rDNS, leading to alignment failures and increased spam risk. Use MailTester’s inbox placement tests to see how rDNS issues impact real delivery.

Cloud and Shared IP Limitations

Cloud email services using shared IP pools may assign different rDNS entries per send, causing SPF validation to fail unpredictably.
These services rarely allow full control over rDNS, making alignment with SPF difficult when sending from multiple domains.
You can verify if rDNS is stable using tools like MxToolbox or DNSLeakTest to check historical consistency.

Reseller, VPS, and Development Misconfigurations

Resellers or VPS providers often misconfigure rDNS during IP allocation, leaving entries pointing to outdated or non-existent hosts.
Dynamic IPs used in test or dev environments rarely have rDNS records — or they point to placeholder names like "dynamic-host.example.com".
Legacy mail servers may return incorrect or non-existent hostnames during reverse lookup, breaking SPF's expected alignment.
Using multiple sending domains on shared infrastructure without consistent rDNS increases the risk of drift and deliverability issues.

Fixing and Testing Reverse DNS Problems

Ensure your sending IP’s rDNS resolves to a valid, stable hostname that matches your sending domain’s SPF record.
Check if your domain’s SPF includes a mechanism for all expected IPs and avoid including untrusted sources.
Use MailTester’s inbox placement tester to simulate real-world delivery with known bounces, including SPF failures due to rDNS drift.
For bulk lists, clean up invalid or inconsistent entries with our bulk email verification tool before sending.
Reverse DNS must be consistent across all systems handling email from the same IP — any mismatch introduces risk, even if SPF technically passes.
Follow RFC 1918 and RFC 5321 guidelines for proper IP and DNS configuration in mail transmission.
Regularly audit your infrastructure — especially when switching providers or using automated senders — to detect rDNS drift early.

Consistency in reverse DNS is not optional. It’s a foundation of email authentication.

How to Test Whether Your rDNS Alignment Causes SPF Failure

If your sending IP’s reverse DNS doesn’t match your domain or a permitted subdomain, SPF validation will fail—even if your SPF record is technically correct. This misalignment breaks alignment in the SMTP handshake, leading to deliverability issues. You can catch this before sending by testing rDNS, SPF, and the full connection behavior in real time.

Identify the IP address used to send mail — Check your SMTP logs or connection headers in an email trace to find the IP your mail server connects from. This is the starting point for testing.
Run a reverse DNS lookup — Use a command line tool like dig -x <IP> or a DNS lookup service to resolve the reverse DNS (PTR record) for that IP. This reveals the hostname assigned to the sending IP.
Check if the hostname includes your domain — The returned hostname should contain your domain (e.g., mail.yourcompany.com) or a known subdomain used for sending. If it doesn’t, you’re likely misaligned.
Verify SPF alignment — Compare the rDNS domain with your SPF record. If the rDNS domain is not your sending domain or a subdomain explicitly allowed in your SPF (e.g., using include:sendgrid.net), SPF will fail during authentication.
Assess the risk of failure — Missing, unrelated, or inconsistent rDNS is a red flag. Even if your SPF record passes standalone checks, the lack of rDNS alignment can still trigger rejection by receiving mail servers.
Simulate the real SMTP handshake — Use a tool that mimics a full SMTP session with real DNS checks, including rDNS and SPF, to see how your setup behaves in production conditions. This is the only way to confirm whether alignment flaws cause actual delivery failures.

The 6 steps described in “How to Test Whether Your rDNS Alignment Causes SPF Failure”, in order.

Why rDNS Alignment Matters in SPF Validation

SPF checks rely on the domain name in the MAIL FROM (envelope from) and the result of the rDNS lookup during the SMTP connection. If they don’t align—meaning the rDNS host doesn’t resolve to a domain you control or have granted permission to send on your behalf—SPF will fail. This is a common, often invisible cause of email delivery drops, especially with third-party services or shared hosting.

The issue isn’t just about syntax—it’s about trust. Receiving servers check the rDNS as part of the sender reputation evaluation. An off-brand or generic hostname like host123.asia.net raises suspicion, even if SPF itself passes. According to RFC 5321, servers are allowed to verify the origin of the connection via reverse DNS to reduce spam.

Testing in a Real-World Context

Running manual DNS checks is helpful—but insufficient. You need to test the full interaction. Tools that simulate real SMTP handshakes validate SPF, rDNS, and DNSBL checks under actual conditions. They show you what happens when an email hits a real mail server’s filters, not just a parser.

Use MailTester’s inbox placement test to send a test email from your IP and see if SPF passes and where it lands—inbox, spam, or rejected. This reveals misalignment issues you won’t catch in a static SPF validator.

Real-time email verification tools that simulate actual delivery can detect SPF failures caused by inconsistent reverse DNS (rDNS) records before you send. These mismatches often slip through static checks but break delivery in real mail servers. MailTester’s inbox-placement testing checks real-world conditions—including rDNS, SPF, DKIM, and DMARC—to catch these alignment issues early.

How Real Delivery Simulation Finds Hidden SPF Problems

Many SPF checks fail not because of a broken policy, but because the sending server’s rDNS hostname doesn’t match the domain in the SPF record. If your IP’s reverse DNS points to a different domain than the one in your SPF, the receiving server rejects the email—even if the SPF syntax is correct. Static validation tools rarely check this alignment, but real-time verification does.

MailTester’s inbox-placement tester connects to actual email providers and runs a complete send simulation. It checks whether the sending domain appears in the rDNS hostname and whether that record aligns with the SPF policy. If there’s a mismatch, it flags the result as risky or invalid, often pointing to an underlying rDNS issue.

Why 'Risky' or 'Invalid' Verdicts Often Mean rDNS Misalignment

When MailTester returns a 'risky' or 'invalid' verdict, it’s not just guessing—it’s evaluating behavior in real email environments. A recurring cause of such results is a mismatch between the sending domain in SPF and the rDNS hostname of the sending server. This is a common misstep in shared hosting, poor infrastructure setup, or when using unbranded SMTP services.

Let’s say your SPF record says include:_spf.example.com, but the server’s rDNS points to mail.vendor.com. Even if the SPF policy is valid, the mail server may still reject the message. Real-time testing exposes this flaw before you send to thousands of users.

Using tools like MailTester’s inbox placement tester lets you catch these issues before they hurt deliverability. You’re not just verifying syntax—you’re validating whether the email will actually land in the inbox, not the spam folder. This reduces bounce rates, minimizes sender reputation damage, and helps maintain long-term deliverability performance.

For teams handling large lists, the bulk verification tool can pre-screen entire databases, identifying SPF-related rDNS issues across hundreds or thousands of addresses. The results are actionable: fix the rDNS, verify again, and send with confidence.

It’s not just about technical accuracy—it’s about behavior. rDNS variability impacts SPF validation. Real-time verification exposes this before it hits your inbox. And that’s the difference between good deliverability and consistent failure.

Can You Fix Reverse DNS Variability After It's Already Causing Bounces?

If you control the IP address and DNS setup, yes — you can fix reverse DNS variability after it starts causing bounces. Contact your hosting provider or cloud service to set the correct rDNS record that matches your sending domain. Ensure the hostname in rDNS is consistent across all IPs in your sending pool to prevent SPF mismatches. Avoid generic hostnames like 'server123.domain.com' in public-facing mail systems, as they look suspicious to receiving servers. After updating rDNS, allow 24–48 hours for DNS propagation and track deliverability metrics to confirm the fix.

Why rDNS Matters for SPF and Deliverability

SPF checks don't just validate your sending domain — they also rely on the reverse DNS (rDNS) record to confirm the IP address belongs to the domain it claims. When rDNS is inconsistent or set to a generic hostname, receiving servers may flag the IP as potentially malicious or misconfigured. This mismatch often leads to authentication failures, even if your SPF record is technically correct.

Many email providers and security services, including those used by major inbox providers, perform these checks automatically. If the rDNS hostname doesn't resolve to a known, authoritative domain tied to your sending infrastructure, it increases your risk of being filtered or rejected.

How to Fix It in Practice

Let’s say you send transactional emails via a cloud provider. You notice increased bounce rates and low inbox placement. You run a reverse lookup on your sending IP and find it resolves to 'mail-local' or 'server-123.example.net'. That’s a red flag. You need to contact your provider and request an rDNS record that uses a hostname aligned with your sending domain, like 'smtp.yourcompany.com'.

Once set, this record must match exactly in both directions: the forward DNS for smtp.yourcompany.com must resolve to your sending IP, and the reverse DNS for that IP must return smtp.yourcompany.com. Using a hostname like 'mail.local' or 'host123.example.com' won’t help — it’s not tied to your domain and may be flagged by spam filters.

After making the change, let 24–48 hours pass for global DNS propagation. Monitor your bounce reports, feedback loops, and inbox placement metrics. Tools like inbox placement testing can help you check real-world delivery across major providers after the fix.

Keep in mind: if you're using shared IP addresses or a shared hosting environment, you may not have control over rDNS at all. In those cases, the provider’s configuration is fixed — and variability will remain. If you're serious about deliverability, owning your own IP and managing DNS settings is a must. This is why tools like bulk list verification help catch invalid or high-risk addresses before they hurt your sender reputation.

Ultimately, reverse DNS is a technical detail, but it plays a crucial role in reputation. A misconfigured record can cause failures even with solid SPF, DKIM, and DMARC. Fixing it isn’t glamorous, but it’s necessary.

Why Bulk Verification Alone Isn't Enough (And What to Do Instead)

You can verify 10,000 email addresses as valid, but if the sender’s reverse DNS doesn’t align with their SPF records, those emails will still fail delivery. Bulk verification catches invalid or malformed addresses, but it doesn’t assess infrastructure-level issues like rDNS drift—common causes of SPF failures even when the address is technically correct. Let’s dig into why deeper testing is critical.

Why SPF Still Breaks Despite a "Valid" Address

Just because an email address passes basic syntax and existence checks doesn’t mean it will reach the inbox. SPF relies on DNS records at the domain and server level, and reverse DNS (rDNS) must match the sending server’s IP address. If rDNS is inconsistent—say, a server’s hostname points to an IP that has a different reverse entry—SPF validation will fail. This happens even if the recipient address is perfectly valid.

Infrastructure drift is common: IPs change, DNS records are misconfigured, or hosting environments shift without updating rDNS. A bulk verification tool sees the address as active but can’t detect these server-level mismatches. That’s why even highly accurate services often miss delivery failures stemming from technical setup issues.

Real-World Simulation Beats Static Checks

MailTester’s inbox-placement testing doesn’t just check if an address is valid—it simulates actual send conditions. By sending test messages to hundreds of real, diverse inboxes across major providers, it captures what happens in production: deliverability, spam filtering, inbox placement, and SPF validation results.

This process uncovers SPF failures caused by rDNS variability before you send. For instance, if your sender’s IP has a mismatched or missing rDNS entry, the test will surface the failure. You can fix the configuration—align the rDNS record with your SPF setup—before your campaign ever launches.

Compare that to static validation. A tool that only checks syntax and response codes can’t simulate the actual email path from sending server to inbox. As the SPF specification makes clear, SPF relies on stable, verifiable DNS records. Without testing against real-world delivery systems, you’re flying blind.

For full coverage: run bulk verification first—use MailTester’s bulk list verification to purge invalid addresses. Then, use inbox-placement testing to assess delivery health. This two-step process protects your sender reputation, reduces bounces, and improves real inbox placement.

How to Use MailTester’s API to Spot SPF Failures at Scale

You can use MailTester’s Real-Time Verification API to test high-volume senders against actual delivery behavior, catching SPF failures caused by reverse DNS variability before they harm your sender reputation. By sending test messages from your domain and IP, you observe how receivers handle them in real time, with the API returning detailed results including SPF status, rDNS match, and inbox placement outcome—enabling you to block or flag risky sends at scale.

Step-by-step process to catch SPF issues early

Integrate the MailTester API into your send queue. Use the Real-Time Verification API to check every email address just before sending. This acts as a gatekeeper, filtering out addresses where SPF fails due to misconfigured or inconsistent reverse DNS records, especially when the sending IP lacks a matching PTR record.
Send test messages from your actual sending IP. Let the API simulate real-world delivery by using your domain and IP to send a test message to a curated list of valid email addresses. This reveals how receiving servers treat your setup, particularly whether they reject or flag messages when reverse DNS doesn’t match SPF’s expected domain.
Analyze the API response for SPF and rDNS results. Each verification returns explicit indicators: SPF status (pass/fail), whether the rDNS (PTR) record matches the sending domain, and whether the message reached the inbox. Failures here often point to inconsistent rDNS configuration—common when IPs are shared or dynamically assigned, which many spam filters flag as risky.
Block or flag deliveries based on results. Set up automated rules in your system to skip or tag messages if the API returns a “SPF Fail” or “rDNS Mismatch.” This prevents volume-based reputation damage from sending to domains where your IP’s reverse DNS doesn't align with SPF’s mechanisms.
Use the in-app AI assistant to interpret and fix issues. When you see recurring SPF or rDNS failures, the AI assistant helps decode the root cause—whether it’s a missing PTR record, a mismatched domain in SPF, or a shared IP environment. It provides targeted suggestions, such as updating your rDNS or revising your SPF record with include mechanisms.

Why real-time simulation beats static checks

Static tools can miss SPF failures caused by reverse DNS variability because they don’t test actual delivery behavior. MailTester’s approach mimics what real mailbox providers do: they inspect the full chain—from the IP’s reverse DNS to the alignment between SPF and the sending domain. According to the SPF specification (RFC 7208), SPF validation requires the sender’s IP to be listed in the domain’s SPF record *and* for the reverse DNS to resolve correctly. Violating either condition triggers rejection or filtering. Testing in production-like conditions is the only way to catch these failures at scale. This is especially critical for senders using shared or dynamic IPs where rDNS changes frequently.

With the API, you’re not just checking syntax—you’re simulating delivery. This means you catch issues that static validators miss, such as SPF failures that only occur when rDNS doesn’t match, even if your SPF record is technically correct. The result? Fewer bounces, fewer deliveries to spam, and a stronger sender reputation over time.

The Hidden Risk of Using Third-Party Email Services Without rDNS Control

You’re using a third-party email service like SendGrid or Mailgun, but your emails bounce or land in spam because the reverse DNS (rDNS) setup on their infrastructure doesn’t align with your sending domain. Even if SPF is technically correct, mismatched rDNS can still cause rejection—because many receivers validate both SPF and the originating server’s hostname. You can’t assume their infrastructure is a black box that just works.

Why Sending Through Third Parties Isn’t Risk-Free

Third-party services manage rDNS on their own servers. That’s fine—until your sending domain isn’t properly authorized in their SPF records. Then, even if your MAIL FROM address is valid, the receiving server sees a mismatch: the IP’s rDNS hostname doesn’t match the domain claiming to send the email. SPF checks don’t fail immediately, but the inconsistency can trigger red flags.

Let’s say your domain sends via SendGrid, but your SPF policy only includes your in-house mail servers. The rDNS of the SendGrid IP resolves to a hostname like mail-external-192-168-1-100.sendgrid.net. If the receiving server checks the mailfrom domain against that hostname and finds no alignment, it may reject the message—even if the SPF pass is technically correct.

Validate the Full Delivery Path, Not Just the Basics

SPF, DKIM, and DMARC are essential, but they don’t cover every layer of verification. rDNS alignment is checked by many major providers, including Gmail and Microsoft, as part of their anti-spoofing systems. The RFC 5321 and RFC 5322 specifications require consistent sender identification across all layers, including the envelope sender and the originating server’s reverse lookup.

To catch this early, test the full path of your email delivery. Use MailTester’s inbox placement tester to simulate real-world delivery across major providers and see whether rDNS mismatches impact deliverability. This isn’t just about validating the recipient email—it’s about validating how your sending infrastructure is seen in the wild. Use our inbox placement tester to validate the full delivery path before sending at scale.

Treat third-party services like external servers you don’t fully control. Just as you audit your own mail servers, audit theirs. Don’t assume their rDNS setup matches your sending behavior. The risk isn’t in the service itself—it’s in the lack of visibility into how it behaves in real email environments. Validate, verify, and adjust before your campaigns fail.

Preventing rDNS-Induced Deliverability Issues from the Start

You can avoid SPF failures caused by reverse DNS mismatches by assigning static IPs ahead of time, ensuring your sending domain appears in the rDNS hostname, and never sharing IPs across unrelated domains. Verify consistency quarterly using tools that test both SPF and rDNS alignment before major sends. This prevents bounces and inbox placement drops before they happen.

Build Your Infrastructure with rDNS at the Core

Assign static IP addresses to your sending infrastructure before launching any campaigns. Dynamic or shared IPs increase the risk of rDNS drift and inconsistent reputation signals.
Configure reverse DNS (rDNS) to match your sending domain. For example, if your IP resolves to mail.yourcompany.com, that domain should appear in your SPF record and be used for all outbound mail.
Send only from domains that are explicitly listed in your rDNS hostname. Mixing domains (e.g., sending from news.yourcompany.com but rDNS pointing to support.anothercompany.com) triggers SPF failures at the receiving end.
Do not mix unrelated domains on a single sending IP. Each domain pair (IP + domain) forms a unique reputation unit. Shared IPs with mismatched domains confuse receivers and undermine trust.

Stay Ahead with Regular Audits and Pre-Send Validation

Audit your sending infrastructure every quarter. rDNS can drift due to infrastructure changes, migrations, or third-party services. A check ensures your setup still aligns with SPF and policy records.
Use real-time validation tools like MailTester’s bulk verification or API to test SPF and rDNS consistency across your list before high-volume sends.
Test inbox placement with inbox tester to observe how your messages fare across Gmail, Outlook, and other major providers — including how rDNS and SPF alignment affect delivery.
Consider industry guidance: the SMTP RFC requires sending hosts to be correctly identifiable through rDNS, and receivers often reject messages when this fails.

Many mail providers use automated checks during receipt. If your rDNS hostname doesn’t match your sending domain, SPF validation may fail even if the record is technically correct. This isn’t a flaw in your SPF — it's a mismatch in trust signals. Prevent it.

Final Take: rDNS Is Not Just a Configuration Detail—It's a Deliverability Gate

Reverse DNS variability disrupts SPF checks at scale, even when alignment and DNS records appear correct. A mismatch between the sending IP’s rDNS and the sending domain’s DNS can trigger authentication failures, leading to bounces or spam filtering.

This issue often goes undetected during list validation because most tools focus on syntax and domain-level checks, not infrastructure-level consistency. The real impact surfaces only in production sends, where delivery rates drop and sender reputation erodes over time.

Real-time inbox-placement testing reveals these hidden risks by simulating actual inbound mail flow. Tools like MailTester catch SPF failures tied to rDNS mismatches before they affect campaigns, uncovering infrastructure weaknesses that bulk verification alone cannot detect.

Deliverability isn’t just about clean lists—it's about verifying that your entire email infrastructure aligns consistently across DNS layers. Prioritize infrastructure integrity alongside list hygiene to maintain reliable inbox placement.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can rDNS affect SPF even if the SPF record is correct?

Yes. SPF checks include the reverse DNS lookup. If the rDNS hostname doesn’t match the sending domain or its authorized host, SPF fails regardless of the record’s correctness.

How long does it take for rDNS changes to affect deliverability?

DNS propagation takes 24–48 hours. After that, receivers with updated caches will start processing messages based on the new rDNS alignment.

Can using a shared IP pool cause rDNS issues?

Yes. Shared IP pools often have generic or inconsistent rDNS records. If multiple domains send from the same IP without proper alignment, SPF fails for some senders.

What does 'risky' mean in MailTester's verdicts?

A 'risky' rating indicates a potential deliverability issue, often due to SPF misalignment or rDNS inconsistency, even if the address is technically valid.

Does MailTester test rDNS during verification?

Yes. MailTester’s inbox-placement tests include real-time checks for rDNS compatibility, SPF alignment, and other delivery indicators.

Can I fix rDNS issues without access to server control?

No. Only the entity managing the IP address can change rDNS. Contact your hosting provider or cloud service to update the record.

Why do some emails get rejected even with DKIM and DMARC set?

SPF checks are independent. If rDNS is misaligned, SPF fails, which can cause rejection even with valid DKIM and DMARC results.

Is reverse DNS required by all email providers?

Most major providers (Gmail, Outlook, Yahoo) use rDNS as part of SPF validation. While not all require it, ignoring it increases risk of blacklisting or spam filtering.

Can rDNS issues only happen with external services?

No. Internal mail servers, resellers, or legacy systems without proper DNS management can also have misconfigured rDNS.

How often should I test for rDNS and SPF alignment?

At least quarterly for ongoing sends, and before every major campaign or sender migration.

Can disposable email domains cause rDNS issues?

Not directly. Disposable domains usually fail at the address level. But they may be hosted on services with poorly configured rDNS, affecting reputation if used in bulk.

What's the best way to audit my send infrastructure for rDNS problems?

Use MailTester’s inbox-placement testing to simulate real delivery and analyze SPF and rDNS behavior across multiple receivers.