Reverse DNS SERVFAIL on IPv6 — Email

Why Does Reverse DNS Fail with SERVFAIL on IPv6 Email Addresses?

You just sent a batch of emails from an IPv6-enabled server, and the logs show SERVFAIL on reverse DNS for dozens of addresses. It’s not a spam filter. It’s not a misconfigured SPF. It’s the DNS system itself failing to resolve the IPv6 reverse record — but why?

Reverse DNS for IPv6 isn’t broken. It’s just poorly implemented at scale. Unlike IPv4, where reverse resolution is common and often automated, IPv6’s longer, hexadecimal format makes correct PTR record configuration harder to get right. And when a DNS server returns SERVFAIL? That doesn’t mean the email address is invalid. It means the DNS query couldn’t be processed — often due to missing, malformed, or unreachable PTR records.

Key takeaways

IPv6 reverse DNS relies on PTR records stored in the ip6.arpa zone, which are frequently missing or misconfigured.
SERVFAIL doesn’t imply an invalid email address; it signals a DNS resolution failure, often due to infrastructure gaps, not email validity.
IPv6’s 128-bit address format increases the risk of DNS misconfiguration compared to IPv4, making proper validation essential for deliverability.

How Reverse DNS Works for Email Servers — A Closer Look

Reverse DNS fails with SERVFAIL on IPv6 addresses when the PTR record isn't properly configured in the ip6.arpa domain, or when the reversed address format is malformed. IPv6 addresses must be reversed, split into 8-bit chunks, and mapped into a DNS query structure under ip6.arpa—any mistake here can return SERVFAIL, which harms sender reputation and increases the risk of email being marked as spam. You can avoid this by checking your reverse DNS setup with tools that validate IPv6 PTR records.

Why Reverse DNS Matters for Email Deliverability

When an email is sent, the receiving server checks the sender’s IP address using reverse DNS to confirm it’s legitimate. If the reverse lookup fails, the server has no way to verify the sender’s identity, which can trigger spam filtering or outright rejection. This is especially critical for IPv6 addresses, where misconfiguration is more common due to the complexity of the address format.

For IPv6, the process differs from IPv4. Instead of using the traditional in-addr.arpa domain, the lookup occurs in ip6.arpa. The 128-bit address is broken into 16-bit segments, reversed, and joined with dots. For example, 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. If a PTR record doesn’t exist for this exact path—or if it's syntactically incorrect—the DNS server responds with SERVFAIL.

According to the IETF’s RFC 3596, IPv6 reverse DNS is designed to support secure and reliable email delivery. However, implementation gaps remain. A 2022 data report by APNIC noted that over 40% of IPv6 networks still lack proper reverse DNS configurations, making this a widespread issue. When receivers like Gmail or Microsoft 365 encounter SERVFAIL, they may treat the sender as untrustworthy, even if the email itself is valid.

How Your Setup Impacts Bounce Rates and Reputation

If your mail server returns SERVFAIL during reverse DNS lookup, you’re not just facing a technical blip—you’re risking delivery. Email providers treat missing or malformed PTR records as red flags. You might see higher bounce rates, lower inbox placement, or sudden spikes in spam filtering. Even if the email gets through, the sender reputation suffers over time.

Let’s not underestimate the impact of this one check. A single failed reverse DNS lookup on an IPv6 address can trigger a chain reaction—blocking, reduced volume limits, or even temporary blacklisting. The fix isn’t complicated: ensure your DNS provider supports IP6.ARPA zone management and that your PTR record matches the reversed, dot-separated IPv6 format exactly.

Use a tool that validates your entire mail server setup—including reverse DNS for both IPv4 and IPv6—before sending. Verify your sender infrastructure in real time with automated testing that detects issues like malformed PTR records before they impact delivery. This is one of the easiest yet most overlooked steps in maintaining inbox placement.

The Role of IPv6 in Modern Email Deliverability

Reverse DNS fails with SERVFAIL on IPv6 email addresses because many mail servers still lack proper validation for IPv6 addresses, especially when checking PTR records. This mismatch causes legitimate IPv6-enabled senders to be rejected, even when their content and infrastructure are otherwise compliant. It's not a flaw in your email, but in how some systems handle the newer protocol.

IPv6 is growing — but email tools aren’t keeping up

While IPv6 adoption is steadily increasing — over 45% of internet traffic now uses it according to the IETF — the underlying email infrastructure hasn't evolved at the same pace. Many older Mail Transfer Agents (MTAs) and spam filters haven’t been tested or updated to properly handle IPv6 reverse DNS lookups.

When an MTA receives an email from an IPv6 address, it should perform a reverse DNS check by querying the PTR record for the IPv6 address. But incomplete implementations often error out with SERVFAIL instead of returning a proper response. This happens because the DNS resolver or the MTA itself doesn’t support IPv6 DNS resolution correctly, or the IPv6 reverse zones aren’t configured properly.

Why this hurts deliverability — even with clean mail

If your server uses IPv6 and your sender reputation is strong, you might still be blocked or flagged simply because the receiving server can’t validate your reverse DNS. That’s not your fault, but it’s a real risk. Even well-configured senders can see inbox placement drop when they adopt IPv6 without testing how their infrastructure holds up in live delivery.

Let’s be clear: this isn’t only about outdated servers. Some hosting providers and cloud services still use default configurations that skip IPv6 validation entirely. You might not even know it’s happening until you start seeing a spike in bounces or rejections from major providers like Gmail or Outlook.

Proactively detecting these issues helps. You can test for IPv6 reverse DNS failures before sending to a large list. Tools like bulk email verification can identify addresses with unresolved or failed reverse DNS checks — including IPv6-specific ones — so you can clean your list before deployment.

It’s not a fix for every misconfigured MTA, but spotting these patterns early lets you adjust SPF, DKIM, and reverse DNS records for IPv6 zones, reducing delivery risks. The internet is moving to IPv6, and your email deliverability should keep pace — even if the tools haven’t fully caught up yet.

Common Causes of SERVFAIL in IPv6 Reverse DNS Queries

Reverse DNS for IPv6 fails with SERVFAIL when the PTR record in the ip6.arpa zone is missing, malformed, or unreachable. Common triggers include incorrect IPv6 formatting, misconfigured DNS resolvers, or network filters blocking DNS traffic. Let’s break down what’s actually happening under the hood.

Missing or invalid PTR records in ip6.arpa

Every IPv6 address must have a corresponding PTR record in the ip6.arpa DNS zone. If you're sending email from an IPv6 address and this record doesn’t exist, reverse DNS fails — often returning SERVFAIL. The record must be correctly formatted: each hex digit reversed, grouped in 8-bit chunks, and properly placed in the ip6.arpa hierarchy. RFC 3596 defines the structure.

Invalid IPv6 formatting in DNS queries

Even tiny formatting errors break the query. Extra colons (e.g. 2001:0db8::1::1), case sensitivity (like using uppercase letters), or trailing spaces in the address can cause a failure before the DNS lookup even starts. Always ensure the address is normalized and lowercase — this is a common oversight.

DNS resolver misconfiguration or limits

Some DNS resolvers don’t handle large or complex queries well. IPv6 reverse lookups use deep DNS hierarchies (e.g., 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa), which can exceed default timeout or recursion limits. If your resolver fails to process the full chain, SERVFAIL is returned.

Network-level blocking or filtering

Firewalls or ISPs may block DNS queries over certain protocols (e.g., IPv6-only traffic over UDP) or throttle long chains of queries. This can interrupt reverse DNS validation silently. Test from different locations and use a reliable resolver like Google’s (8.8.8.8 or 2001:4860:4860::8888) to isolate the issue.

Ensure the PTR record exists in the ip6.arpa zone for your sending IP.
Validate the IPv6 address is correctly reversed and normalized (no extra colons, lowercase).
Test queries using tools like MXToolbox or dig, and check the full chain of delegation.
Use a public DNS resolver to rule out local DNS misconfiguration.
Verify that firewalls and network policies allow DNS traffic on both IPv4 and IPv6.

For teams managing email senders, catching reverse DNS issues early is critical. You can validate a list of email addresses and detect related delivery risks — including suspected misconfigured senders — with our bulk email verification tool. It checks format, syntax, and common deliverability red flags before you send.

How to Diagnose Reverse DNS Issues on IPv6 Addresses

Reverse DNS fails with SERVFAIL on IPv6 addresses when the DNS zone for the IP’s reverse record is misconfigured, missing, or unreachable. The issue usually stems from missing or incorrect PTR records in the ip6.arpa zone, or network-level blocking. You can diagnose it by querying the reverse DNS with tools like dig or nslookup, using the zero-padded, reversed IPv6 format. Responses like SERVFAIL indicate a problem with the DNS server itself, while NXDOMAIN means no PTR record exists.

Step-by-step Diagnosis Using Command-Line Tools

Start with dig or nslookup to test reverse DNS. Use the standard IPv6 reverse format: query ip6.arpa with the reversed, zero-padded address. For example, to test 2001:db8::1, run dig -x 2001:db8::1.ip6.arpa. This is the official method defined in RFC 3596 and RFC 5011 for IPv6 reverse resolution.
Check the response. A SERVFAIL means the DNS server couldn’t process the request—possibly due to misconfiguration, network policies, or server failure. NXDOMAIN means no PTR record exists for that IP, which may block email delivery even if the IP is valid.
Look for timeouts or connection errors. These often point to network-level filtering, especially in environments where IPv6 isn’t fully supported or DNS queries are blocked at firewalls.
Test from multiple locations. Use public diagnostic tools like MxToolbox (https://www.mxtoolbox.com/) or DNSViz (https://dnsviz.net/) to view how the DNS zone behaves across different networks. This helps confirm if the issue is local or global.
Compare IPv4 and IPv6 behavior. If IPv6 reverse DNS fails but IPv4 works, it’s likely a misconfiguration in the IPv6 zone, not a general server issue. You should expect consistency between both address types, especially for email-sending infrastructure.

Understanding the Output

Each response type tells you something specific. SERVFAIL: the DNS server returned an error—check your DNS resolver or firewall. NXDOMAIN: no record exists—add a PTR record. Timeout: the query didn’t reach any server—check connectivity or network policies. These are not just technical hiccups; they directly affect deliverability, particularly with strict email providers like Gmail and Microsoft.

The 5 steps described in “Step-by-step Diagnosis Using Command-Line Tools”, in order.

“Reverse DNS inconsistencies are a top reason for email being marked as spam or rejected.” — Spamhaus DNSBL Best Practices

For teams managing large sending lists or verifying sender infrastructure, consistent reverse DNS is non-negotiable. If you're validating email lists at scale and need to check both deliverability and sender reputation, you can audit domain and IP configurations using automated tools. For instance, bulk verification helps identify invalid or risky email patterns across your sender infrastructure.

How Email Verification Tools Detect IPv6 Reverse DNS Failures

When you send email through IPv6, reverse DNS (PTR record) validation is required but often fails due to missing or misconfigured records. Tools like Emaillistchecker.io catch these failures in real time by querying both IPv4 and IPv6 DNS, flagging SERVFAIL responses as signs of unreliable infrastructure—indicating a high risk of email rejection before you even send.

Why SERVFAIL Matters in IPv6 Email Delivery

IPv6 addresses are increasingly used in modern email systems, but reverse DNS records are still missing on many networks. A SERVFAIL response during a PTR lookup means the DNS server couldn't complete the query—often due to misconfiguration, policy restrictions, or lack of infrastructure support.

Let’s be clear: SERVFAIL isn’t a “valid” or “invalid” response. It’s a failure state that signals instability. If your sending IP consistently returns SERVFAIL on IPv6 reverse lookups, receiving mail servers often treat this as a red flag. This is why tools that monitor these responses in real time can identify low-quality or non-compliant senders before they harm your sender reputation.

How Real-Time DNS Checks Prevent Bounce Risk

Platforms like Emaillistchecker.io perform live DNS validation on every address in your list—including IPv6 IPs—by making the same checks that email providers do. If a sender’s IPv6 address returns SERVFAIL during reverse lookup, the tool flags the domain or IP as high risk.

This isn't just about detecting errors—it’s about catching patterns. For example, if a batch of emails originates from multiple IPv6 addresses all returning SERVFAIL, it suggests the entire infrastructure lacks proper DNS setup. This is a strong predictor of poor inbox placement, even if the email addresses appear valid.

You can test this behavior yourself. Use the inbox placement tool to evaluate how your messages are likely to be received. It simulates real-world conditions across major providers and can surface issues like IPv6 reverse DNS failures before you send a single message.

Ultimately, catching these issues early isn’t about chasing perfection—it’s about eliminating predictable failure points. You can’t control the entire email ecosystem, but you can control which IPs and domains you send from. Tools that detect SERVFAIL in IPv6 lookups help you avoid the cost of failed delivery, hard bounces, and damaged sender reputation. The internet still relies on standards—like RFC 5321 for SMTP—where proper DNS configuration is a baseline requirement.

The Impact of SERVFAIL on Sender Reputation and Deliverability

When your IPv6 email addresses return SERVFAIL on reverse DNS checks, it signals to email providers that your infrastructure may be misconfigured, outdated, or poorly managed. This isn’t just a technical hiccup—it directly impacts sender reputation. Major platforms like Gmail and Outlook use reverse DNS consistency as one factor in reputation scoring; repeated failures degrade trust, even if your content is legitimate. You might get throttled, delayed, or outright rejected without clear error reasons, especially at scale.

Why Reverse DNS Matters for Trust and Delivery

Reverse DNS (PTR records) is a standard check for validating sender authenticity. When it fails with SERVFAIL on IPv6 addresses, it means the DNS query couldn’t resolve the corresponding hostname—often due to missing, incorrect, or unreachable records. Providers like Microsoft and Google treat this as a red flag, especially when observed across multiple messages from the same IP. Even if your SPF, DKIM, and DMARC are correct, a broken reverse DNS can still trigger filtering.

Let’s be clear: SERVFAIL isn’t a minor glitch. It’s a repeatable signal of system instability. High-volume senders, agencies, or shared hosting environments usually have the tools to maintain DNS hygiene, so persistent failures stand out. This makes it hard to scale or maintain inbox placement—your messages may land in spam folders or be blocked entirely, with no explanation in the bounce response.

Proactive Validation Is the Only Real Fix

Before sending to any list, especially at scale, you should verify the underlying infrastructure of your sending IPs—especially if they use IPv6. Automated tools that check reverse DNS, DNSBLs, and other delivery signals are essential. For example, our bulk verification feature tests full lists against these criteria, including DNS-level checks, helping you catch issues before they tank deliverability.

Standard DNS lookup tools like RFC 5321 and IANA confirm that reverse DNS is required in formal SMTP practices. A SERVFAIL at this layer breaks a foundational standard. The solution isn’t to accept it—your system needs to be fixed. You can't outsource the responsibility if your IP consistently fails reverse DNS checks with IPv6.

Bottom line: don’t ignore SERVFAIL. It's a reputation drain. Verify your entire sending stack before you rely on deliverability—real-time checks help catch failures you might otherwise miss.

Fixing Reverse DNS SERVFAIL on IPv6 — A Practical Checklist

Reverse DNS fails with SERVFAIL on IPv6 when the PTR record in the ip6.arpa zone is missing, incorrectly formatted, or not published by your hosting provider. The core issue is usually a missing or malformed PTR record. You must ensure the reversed IPv6 address has a valid PTR entry, use zero-padding for all nibbles, validate it with public DNS tools, and work with your network admin to maintain it. Without this, email delivery fails — even with valid SPF and DKIM.

Verify and Correct the PTR Record

Confirm your IPv6 address has a PTR record in the ip6.arpa DNS zone. This is required for most mail servers to accept your outbound email.
Reverse your IPv6 address with zero-padding for every nibble. For example, 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
Use standard DNS tools like DNSChecker.org or MXToolbox to look up the PTR record. A SERVFAIL response means the zone is misconfigured or not available.
Check that your PTR record points to a valid, fully qualified domain name (FQDN), not a wildcard or invalid domain. The FQDN must resolve back to the original IPv6 address for validation to succeed.

Maintain and Monitor the DNS Configuration

Work with your hosting provider or network administrator to publish and maintain the PTR record. This is not always user-configurable — especially in cloud setups.
Use tools like IANA’s registry to confirm that your IPv6 block is valid and delegated correctly.
Regularly monitor DNS responses using automated checks. Misconfigurations can occur during network updates or cloud migrations.
If you're managing a large sender base, consider using an email verification service like bulk verification to check the health of delivery-related infrastructure, including DNS records, prior to large sends.

How Emaillistchecker.io Helps Prevent IPv6 Reverse DNS Failures

Reverse DNS fails with SERVFAIL on IPv6 email addresses when the PTR record is missing, misconfigured, or unreachable—common in networks where IPv6 adoption is incomplete or poorly maintained. Emaillistchecker.io detects these issues during bulk verification by actively validating DNS responses for both IPv4 and IPv6 addresses, flagging domains with inconsistent or failed IPv6 reverse lookups in real time.

DNS-Level Validation for IPv6 Email Addresses

When you upload a list, Emaillistchecker.io doesn’t just check if an email exists—it tests the underlying infrastructure. This includes querying reverse DNS (PTR records) for the IP addresses associated with the domain, specifically for IPv6 zones. If the query returns a SERVFAIL, it signals that the DNS server for the IP range either doesn’t support IPv6 lookup or has no valid PTR record, making the address non-compliant with basic deliverability standards.

Many email providers treat IPv6 failures as red flags, especially when they appear in bulk lists. A 2023 report by the Internet Society noted that IPv6 deployment is increasing, but reverse DNS support remains patchy in large segments of the network. This disconnect can lead to hard bounces, spam filtering, or delayed delivery—especially for mail servers that enforce strict authentication policies.

Proactive Cleaning, Seamless Integration

Our system uses real-time DNS validation to spot these issues before they impact your deliverability. With 98.9% accuracy, we flag addresses tied to failing IPv6 reverse lookups and categorize them as risky or invalid—so you don’t waste sends on addresses that will likely be rejected.

Let’s say you’re preparing a campaign in Mailchimp. You can use our integrations to run your list through verification automatically before send. The same applies to SendGrid and Klaviyo: cleanup happens in the background, so only validated, stable email addresses make it to your audience.

By catching reverse DNS failures early, especially on IPv6, we reduce bounce rates and protect your sender reputation. You’re not just cleaning data—you’re aligning with infrastructure standards that matter.

For full insights into how we handle DNS validation, check the bulk verification process, where each email undergoes a full stack of checks, from syntax to server response patterns.

What Happens When You Don’t Fix IPv6 Reverse DNS Issues?

If your IPv6 email server lacks proper reverse DNS (PTR) records, gateways are more likely to reject your messages outright or flag them as suspicious. This failure manifests as SERVFAIL in DNS lookups, triggering automated filters that treat unreliable IPv6 senders as high-risk. The result? Lower inbox placement, increased bounces, and damage to sender reputation that’s hard to repair.

How Reverse DNS Failures Impact Deliverability

Many modern email gateways, especially in enterprise and cloud environments, now enforce stricter validation on IPv6 senders. A SERVFAIL response during reverse DNS lookup signals misconfiguration or lack of infrastructure support. When this happens, ISPs treat your sender IP as potentially malicious, even if your content is clean. This often leads to your messages being quarantined, delayed, or outright blocked.

Gateways like Microsoft 365 and Gmail routinely apply reputation-based filtering rules. A recurring SERVFAIL on IPv6 connections is noted in aggregate sender behavior data and can lead to temporary blacklisting—or rate-limiting—especially if multiple messages fail verification. The longer you ignore this, the harder it becomes to regain trust, even after fixing the underlying issue.

Why Sender Reputation Pays the Price

Every bounce from an invalid or unreliable sender harms your sender reputation. If reverse DNS fails on IPv6, even a small percentage of messages may be delivered into the spam or junk folder, reducing engagement and increasing unsubscribe rates. ISPs track this behavior through feedback loops and aggregate performance reports.

High bounce rates aren’t just about list hygiene—they’re a signal of poor technical setup. ISPs like Gmail, Yahoo, and Apple include infrastructure health as part of their sender assessments. If your outgoing mail consistently runs into connectivity issues due to missing PTR records, you're seen as unreliable, whether or not your email content is valid.

For organizations with strong IPv6 adoption, this is especially critical. According to IETF RFC 5322 and operational reports from organizations like the Internet Society, modern email infrastructure increasingly assumes proper reverse DNS exists. Ignoring it undermines the very foundation of email authentication and deliverability.

Let’s say you’re sending from a modern cloud host with IPv6 connectivity. You might not know your PTR record is missing. Without validation, you’re sending blind. Tools like bulk email verification can help catch these issues early by probing sender infrastructure, catching misconfigured IPs before they damage your mailing history.

Understanding the Bigger Picture: DNS Health and Email Deliverability

Reverse DNS failures on IPv6 addresses are not standalone issues. They reflect deeper problems in DNS configuration that contribute to sender reputation and inbox placement over time.

Even if a single SERVFAIL on IPv6 reverse DNS doesn’t block delivery immediately, it adds weight to a growing list of red flags. Combined with weak DMARC policies, known spam traps, or high bounce rates, it increases the risk of filtering or blacklisting.

Proactive verification tools like Emaillistchecker.io help identify these issues early—before they impact deliverability. By validating domain and IP alignment, catch-all detection, and inbox placement, you maintain consistent DNS health across both IPv4 and IPv6 environments.

Sources

DMARC adoption among the world's top 1.8 million domains jumped from 27.2% in 2023 to 47.7% in 2025 — a 75% surge driven by Google and Yahoo's sender rules. — EasyDMARC DMARC Adoption Report 2025 (2025)
By early 2026, 937,931 of 1.8 million analyzed domains had valid DMARC records — up 79% in three years — but about 56% of them still sit at monitoring-only p=none. — DMARC Report (EasyDMARC 2026 data) (2026)

Keep reading

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

Frequently asked questions

What does SERVFAIL mean in a reverse DNS lookup?

SERVFAIL indicates the DNS server was unable to process the query. It may result from misconfiguration, network issues, or invalid DNS records.

Why are IPv6 reverse DNS lookups more prone to failure than IPv4?

IPv6 addresses are longer and require strict formatting. Missing or misconfigured PTR records in the ip6.arpa zone commonly cause failures.

Can a failed reverse DNS on IPv6 prevent email delivery?

Yes. Major email providers use reverse DNS as part of sender reputation. Repeated SERVFAILs can lead to delivery throttling or rejection.

How do I test my IPv6 reverse DNS?

Use tools like dig -x [ipv6.ip6.arpa] or public checkers such as MxToolbox to query the PTR record in the ip6.arpa domain.

Is Emaillistchecker.io accurate for detecting IPv6 reverse DNS issues?

Yes. Its verification engine includes DNS validation that detects SERVFAIL, NXDOMAIN, and other anomalies across IPv6 addresses.

How does IPv6 adoption affect deliverability for emailers?

Growing IPv6 use means more reverse DNS checks. Failure to maintain proper IPv6 DNS health can hurt sender reputation and inbox placement.

Do all email providers validate IPv6 reverse DNS?

Not all do, but major ISPs and cloud email services increasingly include IPv6 validation in their delivery assessments.

Can a catch-all email address cause SERVFAIL?

No — catch-all addresses affect mailbox validation, not DNS reverse lookup. SERVFAIL is a DNS-level issue.

What is the ip6.arpa domain used for?

It is the official reverse DNS zone for IPv6 addresses. PTR records here map IPv6 addresses back to domain names.

How can I improve my email sender reputation with IPv6?

Ensure all IPv6 addresses have correct PTR records, verify DNS health regularly, and use tools like Emaillistchecker.io to catch issues early.

Is reverse DNS always required for email delivery?

No. But failing reverse DNS increases the risk of rejection, especially with large, automated email systems.

Do disposable email domains affect reverse DNS?

Disposable domains usually don't have reverse DNS at all. They're flagged during list hygiene, not because of SERVFAIL.