What Causes SERVFAIL on IPv6 PTR Lookups in Email Servers?

You send an email from an IPv6 address, and the receiving server replies with a SERVFAIL on the PTR lookup—no clear reason, no logs, just a silent rejection. You’re not alone. This happens more often than you’d expect, especially when IPv6 reverse DNS isn’t aligned with the zone structure required by email infrastructure.

Reverse DNS for IPv6 uses a distinct format: ip6.arpa zones, not in-addr.arpa, and the address must be written in reverse, with each nibble (4 bits) separated by dots. A misconfigured or missing record here breaks the lookup chain. When resolvers get SERVFAIL, they often treat it as an indication of poor email hosting hygiene—potentially marking your domain as untrustworthy, even if your server is otherwise sound.

This isn’t just a technical nuance. Email systems that rely on reputation scoring interpret SERVFAILs as red flags. Even if your content is clean, the server fails, and your messages get filtered or rejected.

Key takeaways

  • IPv6 reverse DNS uses the ip6.arpa zone, not in-addr.arpa, and must be structured with each nibble separated by dots.
  • Missing, malformed, or unreachable PTR records for IPv6 addresses result in SERVFAIL responses from DNS resolvers.
  • SERVFAIL on IPv6 PTR lookups can harm sender reputation and reduce inbox placement, even if the sending server is fully functional.

How SERVFAIL on PTR Affects Email Deliverability

When your IPv6 email server returns SERVFAIL on PTR record lookup, it signals to receiving mail servers that your reverse DNS configuration is broken or unreachable. This often triggers spam filters, leading to rejection or inbox placement in low tiers—even if your message content is clean. Many ISPs and mailbox providers treat a failed IPv6 PTR lookup as a red flag, especially in automated systems where validation is assumed but not properly enforced.

Why Reverse DNS Matters for Email

Mail systems use reverse DNS (PTR) to confirm the sender's IP address belongs to a legitimate, well-configured server. A successful PTR match adds credibility; a failure—especially one reported as SERVFAIL—suggests the infrastructure might be misconfigured, temporary, or part of a botnet.

IPv6 environments are more prone to this issue because not all providers or networks fully support or validate IPv6 DNS records. When a receiving server queries a PTR record and gets SERVFAIL instead of a valid response, it may interpret that as intentional obfuscation or instability. This is particularly common when the reverse zone isn’t properly delegated or lacks authoritative nameservers.

Impact on Deliverability and Reputation

Even a single SERVFAIL on IPv6 PTR can hurt your sender reputation. Some mailbox providers like Microsoft and Google apply reputation penalties when DNS anomalies persist, especially across IPv6 connections. A history of such failures correlates with higher bounce rates and increased risk of being labeled as suspicious.

Automated systems without proper diagnostics often pass on these failures unexamined, compounding the problem. If you’re sending to large platforms, even one SERVFAIL on IPv6 can mean your emails end up in junk folders or are silently dropped.

Let’s be clear: SERVFAIL isn’t just a technical quirk. It’s a deliverability signal. If your outbound emails fail DNS validation, you’re not just losing one message—you’re damaging trust that takes time to rebuild. Fixing PTR records on IPv6 is not optional for high-volume senders.

Use tools like the bulk verification service to test your list against known delivery hurdles, including DNS validation issues, before you send. It’s a proactive way to catch infrastructure-related delivery risks early.

Why IPv6 PTR Records Are More Prone to SERVFAIL

IPv6 PTR records often return SERVFAIL because reverse DNS zones are vastly larger and more complex than IPv4 ones, increasing the chance of misconfiguration. Many hosting providers don’t automatically set up or validate IPv6 reverse DNS, and even when configured, formatting errors—like incorrect IP syntax or missing trailing dots—can break the lookup entirely. This means a legitimate email server may fail DNS verification simply due to an overlooked technical detail.

Size and Complexity of IPv6 Reverse Zones

IPv6 uses 128-bit addresses, making reverse DNS zones exponentially larger than IPv4’s 32-bit zones. Where IPv4 reverse DNS typically deals with a limited number of zones per provider, IPv6 often requires thousands of subzones just to cover a single provider’s allocation. This scale makes management error-prone and increases the likelihood of incomplete or incorrect configurations.

Consider the RFC 5789 (https://www.rfc-editor.org/rfc/rfc5789) guidelines for reverse DNS delegation—these standards were built for IPv4’s simpler architecture and don’t scale as cleanly into IPv6’s hierarchical model without careful implementation. If a provider fails to delegate zones correctly within a /32 or /48 block, resolvers will hit dead ends, leading to SERVFAIL responses.

Provider Gaps and Common Formatting Errors

Even if you manually set up a PTR record, the odds of success drop if your cloud host—like AWS, DigitalOcean, or Vultr—doesn’t support or validate IPv6 reverse DNS at all. You might think it’s working, but the underlying infrastructure silently drops the lookup. Notably, some providers only allow IPv6 reverse DNS for dedicated IPv6 addresses, not shared ones.

Format issues are another common culprit. For example, a record like 2001:db8::1.in-addr.arpa must include the trailing dot: 2001:db8::1.in-addr.arpa.. Omitting it breaks DNS resolution entirely. Similarly, using a non-conforming IP format (e.g., 2001:db8:0:0:0:0:0:1 instead of compressed form) can cause parsing failures in resolvers. These small oversights are hard to spot but trigger SERVFAIL on every reverse lookup.

Let’s be honest—most email deliverability tools don’t test IPv6 reverse DNS by default. That means you’re flying blind. If you’re sending through IPv6 and seeing delivery inconsistencies, check these low-level details first.

Need to clean up a list of sender domains that may be failing reverse DNS checks under IPv6? Our bulk verification service can help identify problematic email addresses and flag infrastructure misconfigurations early.

How to Diagnose IPv6 PTR SERVFAIL

When your IPv6 email server returns SERVFAIL on a PTR lookup, it usually means the reverse DNS zone isn’t properly set up or delegated. Let’s walk through diagnosing it step by step using standard tools and checks.

  1. Use dig -x <ipv6-address> ip6.arpa to query the PTR record directly. This is the most reliable way to test if reverse DNS resolves for your server’s IPv6 address.
  2. If the response is SERVFAIL, your upstream DNS server couldn’t reach the authoritative zone. This isn’t an issue with your server’s mail software — it’s about DNS delegation.
  3. Check whether the reverse DNS zone exists for your IPv6 block. IPv6 reverse lookups use the ip6.arpa domain, and the zone must be delegated from the parent (like 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.ip6.arpa) down to your DNS provider.
  4. Use tools like MxToolbox or DNSCheck to validate zone delegation. They’ll show whether the PTR records are reachable from the root and if any link in the chain is broken.
  5. Confirm your DNS provider supports IPv6 reverse zones and has configured the necessary NS records in the parent zone. If your provider doesn’t allow custom reverse DNS, the zone won’t work even if everything else is correct.

Common Causes of SERVFAIL

Even with correct setup, you might still see SERVFAIL if upstream servers are misconfigured or if firewalls block DNS queries. Some ISPs or hosting providers don’t delegate reverse zones properly — especially in shared infrastructure. This is more common with cloud providers than dedicated servers.

You can also check your DNS resolver’s behavior by testing with a public resolver like Cloudflare DNS (1.1.1.1) or Google Public DNS (8.8.8.8). If they return SERVFAIL too, the issue is upstream, not your local setup.

Fixing the Issue

Once you confirm the zone is missing or misdelegated, contact your ISP or hosting provider. They must create the reverse zone and delegate it to your DNS provider. It’s often a manual process — automated tools won’t help here.

After fixing, retry the dig command. It may take 10–30 minutes for DNS changes to propagate. Be patient — especially with large blocks like /48 or /64 allocations.

For teams managing email deliverability at scale, catching these DNS issues early prevents bounces and improves sender reputation. Tools like bulk email verification can flag invalid or poorly configured domains before they hurt your deliverability.

Validating IPv6 Reverse DNS: Step-by-Step Configuration

IPv6 email servers return SERVFAIL on PTR lookups when the reverse DNS zone isn’t properly delegated or the PTR record isn’t correctly published. To fix this, you must ensure your IPv6 block’s reverse zone is correctly configured with a valid PTR record, delegated to your DNS provider, and verified using standard tools. A single misstep in syntax or delegation breaks the chain, causing delivery issues.

  1. Identify your reverse DNS zone using the standard IPv6 arpa format. For a /32 block like 2001:db8::/32, the zone is 32.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. Reverse zones are derived from the hex digits of your IPv6 address, reversed and joined by dots. This is defined in RFC 3596.
  2. Confirm the zone is delegated to your DNS provider. Your ISP or hosting provider must allow delegation of the reverse zone to your DNS hosting service. If your provider handles reverse DNS, you cannot set it in your own DNS. Contact your provider to verify delegation or request it.
  3. Create a PTR record in your DNS zone with the correct syntax. For an address like 2001:db8:1:2::1, use 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.ip6.arpa. IN PTR mail.example.com.. The domain name must resolve to the correct A or AAAA record.
  4. Use a DNS manager that supports IPv6 records. Not all DNS platforms handle IPv6 reverse zones correctly. Ensure your DNS provider allows full zone editing and validates syntax. Set TTL values to a reasonable default (e.g., 300 seconds) for timely propagation.
  5. Test the configuration with dig. Run dig -x 2001:db8:1:2::1 ip6.arpa from an external server. If you see SERVFAIL, check: syntax errors, delegation issues, or unconfigured zones. Wait 5-10 minutes after changes for DNS propagation.

Common Pitfalls to Avoid

  • Don’t assume your hosting provider handles reverse DNS. Many do not.
  • Never omit the trailing dot in the PTR record. Missing it breaks the DNS syntax.
  • Ensure the hostnames in PTR records are valid, fully qualified domains.
  • Verify the zone delegation using tools like MXToolbox or DNSStuff.

Final Check

Once configured, run multiple tests from different geographies. A SERVFAIL in one location doesn’t mean you’re done—some resolvers may cache failures. Persistent SERVFAILs often point to upstream delegation failures, not syntax errors.

After resolving IPv6 reverse DNS, you'll improve sender reputation and deliverability. For email list hygiene that avoids issues like invalid or unverifiable addresses, consider validating your entire list with bulk verification tools. Verify your list at scale with accuracy you can trust.

Common Mistakes That Cause SERVFAIL on IPv6 PTR

IPv6 reverse DNS fails with SERVFAIL when the PTR record isn't formatted correctly, the reverse zone isn't properly delegated, or DNS infrastructure lags behind configuration changes. You’re likely hitting a validation error because the reverse zone doesn’t match the DNS zone structure, or your provider doesn't support IPv6 delegation. Fixing this starts with validating the full chain: format, delegation, and zone propagation.

Common Format and Delegation Errors

    • Use online tools like MXToolbox or DNS Stuff to query your IPv6 PTR record from different global points—especially from regions where your recipients are located.
    • Automate this with scripts using dig -x or nslookup from servers in diverse data centers; a single geographic result can mislead you.
    • Check that the returned hostname aligns with your expected branding or server identity, and ensures SPF/DKIM records are consistent.
    • Deploy uptime monitors like Uptime Robot or Pingdom that support IPv6 and alert you if your reverse DNS becomes unavailable.
    • Use an inbox placement testing service—it simulates actual email delivery paths, including reverse DNS validation, to show if your IPv6 server is flagged or rejected.
    • Run checks through platforms like inbox placement testing to detect SERVFAIL or similar failures early, before sending to real users.
    • 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)
    • Validity's analysis of 22+ million domains found 84% of domains used in email From addresses have no published DMARC record at all. — Validity (2024)

Include the full IPv6 address in reverse format, with no spaces—e.g., 2.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.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.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.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.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.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.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.0.0.0.0.0.0.0.

Email Verification as a Preventive Measure for Deliverability Issues

Running a PTR lookup on an IPv6 email server fails when reverse DNS isn’t properly configured or the DNS infrastructure doesn’t support IPv6 resolution. This breaks SPF and DKIM alignment checks, triggering spam filters. You can avoid this by verifying sender domains before sending — catching invalid or misconfigured domains early through tools that test DNS records and sender reputation. A single misconfigured server can hurt deliverability across your entire campaign.

Early Detection of DNS and Infrastructure Risks

Before sending to a list, validate every email address. Tools like Emaillistchecker.io don’t just check syntax — they probe the domain’s actual infrastructure. If a domain lacks a reverse DNS record (PTR) or has inconsistent MX, SPF, or DKIM configurations, the tool flags it. This catches problems before they lead to bounces, spam traps, or blacklisting.For IPv6 setups, reverse DNS can fail silently if the PTR record isn’t published for the IPv6 address block. Emaillistchecker.io detects missing or misconfigured PTR records during verification, including those tied to IPv6 zones. It also identifies domains using known problematic IP ranges or shared hosting infrastructures that correlate with poor sender reputation and high bounce rates.

Patterns in Bulk Lists Signal Broader Problems

When you run a bulk verification, you’re not just cleaning a list — you’re auditing your sender ecosystem. If dozens of emails from the same domain fail due to PTR lookup issues, it suggests the domain’s mail server infrastructure is subpar. This could mean shared IPs, lack of proper DNS hygiene, or even compromised infrastructure.Let’s say your list has a cluster of addresses from a domain with repeated SERVFAIL responses on PTR lookups. This pattern often shows up under IPv6-enabled servers without full reverse DNS support. Emaillistchecker.io surfaces these clusters, allowing you to either segment the list or pause sending to affected domains until their DNS is fixed.According to RFC 5321, reverse DNS is not mandatory but strongly recommended for sender authentication and spam defense. While not all systems enforce it, failing to match a PTR record reduces trust and can lead to inbox filtering. That’s why preventive verification is more than a cleanup task — it’s a deliverability safeguard.Use real-time verification at API scale for automated workflows, or run a full bulk verification on your campaign list to catch hidden issues before launch. The goal isn’t 100% perfect addresses — it’s a list that clears technical and reputational hurdles.

How Emaillistchecker.io Helps Catch IPv6 PTR Issues

When your IPv6 email server returns SERVFAIL on PTR record lookups, it signals a misconfiguration that harms deliverability. Emaillistchecker.io detects these issues during bulk email verification by checking reverse DNS, SPF, DKIM, and sender reputation—all before you send. It flags domains with missing, invalid, or failing PTR records, including those returning SERVFAIL, even if the mailbox technically exists.

Real-Time Detection of IPv6 Reverse DNS Failures

IPv6 PTR records are more complex than IPv4 ones due to longer addresses and different DNS structures. When a resolver returns SERVFAIL during lookup, it often means the DNS infrastructure doesn't support the reverse zone, lacks proper delegation, or has a misconfigured zone file. These issues alone can trigger spam filters and blocklist entries. Emaillistchecker.io’s verification process includes a full reverse DNS validation layer that identifies these failures programmatically.It doesn’t just test whether an email address is syntactically valid—it checks the underlying infrastructure. If your server’s IPv6 address fails reverse lookup, the service flags it as a deliverability risk, even if the domain and email are otherwise correct. This prevents messages from being rejected or marked as spam before they ever reach the inbox.

High Accuracy and Seamless Integration for Proactive Fixes

With 98.9% accuracy, Emaillistchecker.io provides reliable insights across large lists. Its real-time API, available at integration with Mailchimp, HubSpot, Klaviyo, and SendGrid, allows you to validate every new sign-up or uploaded list instantly. This catches IPv6 PTR failures early, avoiding costly mass-bounce campaigns.For teams managing large databases, bulk verification (available at our bulk verification tool) runs these checks in parallel across thousands of records. It’s not a single-point test—you’re not just checking one email. You’re assessing the entire sender infrastructure’s health. For more detailed delivery outcomes, the inbox placement test (inbox placement tool) simulates real-world sender reputation behavior, including how ISPs react to misconfigured reverse DNS.Understanding IPv6 reverse DNS isn’t optional for modern senders. The SMTP specification (RFC 5321) requires proper reverse DNS for authentic sender identification. Tools that skip this step leave senders exposed to filtering and reputational damage. Emaillistchecker.io doesn’t just report issues—it helps fix them by surfacing problems you might otherwise miss until your email gets blocked.

Proactive Steps to Ensure IPv6-Based Email Servers Are Trusted

IPv6 email servers return SERVFAIL on PTR lookups when reverse DNS records aren’t properly configured or aren’t reachable from global networks. To fix this, you must validate your reverse DNS setup from multiple geographic locations, monitor DNS uptime with IPv6-capable tools, and test inbox placement using services that simulate real-world delivery conditions. These steps uncover hidden issues before they block your messages.

Test Reverse DNS from Multiple Locations

Monitor DNS Health and Inbox Placement

Even a valid PTR record fails if it’s unreachable from the mail server’s path—proactive verification is the only way to catch this.

Remember: an IPv6-only server that can’t resolve reverse DNS correctly will be treated as suspicious by major ISPs. This leads to bounces, poor sender reputation, and inbox filtering—even if all other technical checks pass. Let’s treat reverse DNS not as a one-time setup but as a continuously monitored component of your email delivery stack.For teams managing high-volume sending, consider integrating a real-time verification API to pre-validate recipient addresses and avoid waste on invalid or non-routable IPv6 setups. You can test this via our API with full IPv6 support.

Why Fixing IPv6 PTR Is Necessary for Modern Email Delivery

IPv6 reverse DNS (PTR) records are increasingly checked by modern email systems. If your IPv6 server returns SERVFAIL on PTR lookup, it signals misconfiguration or unresolved DNS, which can lead to email rejection—even if SPF and DKIM are correctly set. Fixing this improves inbox placement and supports long-term sender reputation, especially for large-scale senders.

Reverse DNS Checks Are No Longer Optional

As IPv6 adoption grows, email receivers are more likely to validate reverse DNS for every incoming connection. This includes cloud-hosted services, mobile email apps, and messaging platforms. Failing a PTR check on IPv6 often results in immediate rejection or spam filtering, regardless of authentication success.Let’s be clear: even if your SPF aligns and DKIM cryptographically verifies, a SERVFAIL on PTR can still block your message. Many systems, especially those using real-time blocklists (RBLs) or sender reputation scoring, treat missing or invalid reverse DNS as a red flag. This is not speculative—research from the Internet Society and industry reports confirm reverse DNS as a consistent factor in deliverability decisions.IPv6 address allocation and management have become system-level requirements, not just technical preferences. If your server’s IPv6 address doesn’t resolve to a valid hostname via PTR, the email system assumes the source is either untrusted or poorly managed. Over time, this erodes sender reputation, especially when sending at scale.

How Clean DNS Supports Long-Term Deliverability

For high-volume senders, every rejection—even a soft one—impacts reputation metrics. A consistent SERVFAIL on IPv6 PTR can trigger automated systems to throttle or block traffic. This is especially true for providers using feedback loops or advanced filtering, such as Microsoft Outlook’s anti-abuse systems.Proactively validating your reverse DNS setup reduces risks. Use tools that check both IPv4 and IPv6 PTR records to catch issues before they impact your deliverability. At email list verification, you can test and clean your sender list, ensuring you’re not sending to invalid or misconfigured endpoints that could indirectly harm your reputation.Correcting IPv6 reverse DNS isn’t just about troubleshooting a single error—it’s part of maintaining a sustainable, trustworthy sending infrastructure. With increasing reliance on IP reputation, fixing PTR issues now protects your future deliverability. Don’t wait for blocklists to notice the failure.

Summary: Fixing IPv6 PTR SERVFAIL Improves Deliverability

SERVFAIL on IPv6 PTR record lookups signals that reverse DNS is either missing or misconfigured. This undermines email trust and increases the risk of messages being rejected or marked as spam.Use tools like dig to diagnose the issue. Verify that the IPv6 reverse zone is properly delegated and that PTR records follow the correct format: ip6.arpa zones must resolve with valid, correctly structured pointers.Correcting reverse DNS configuration prevents bounces, improves sender reputation, and boosts inbox placement. Proactively catch issues before they affect outreach by validating your email list with tools that detect invalid or poorly configured sender addresses.

Sources

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 DNS PTR lookup?

SERVFAIL indicates the DNS server could not process the query due to a problem with the server or zone setup, such as missing delegation or misconfiguration.

Is reverse DNS required for IPv6 email servers?

Yes, while not always enforced, modern email systems use reverse DNS to validate server authenticity, and failures may lead to rejection.

Can a single SERVFAIL cause all emails to be blocked?

Not necessarily, but repeated SERVFAILs across multiple senders or domains can trigger spam filtering or reputation penalties.

Do all email providers check IPv6 reverse DNS?

Many do — especially for high-volume senders — and failure to respond correctly can reduce inbox placement even if SPF and DKIM are valid.

What’s the difference between IPv4 and IPv6 reverse DNS zones?

IPv6 uses the ip6.arpa zone, with addresses formatted in reverse with hex digits, while IPv4 uses in-addr.arpa with decimal numbers and reversed octets.

How can I test my IPv6 PTR record?

Use the command `dig -x <ipv6-address> ip6.arpa` to check for errors like SERVFAIL or NXDOMAIN.

Does Emaillistchecker.io check reverse DNS for email domains?

Yes, it tests email domains for common deliverability risks, including missing or failing reverse DNS on both IPv4 and IPv6.

What happens if my email server has a SERVFAIL on IPv6 PTR?

Mail servers may reject messages, mark them as spam, or assign lower sender reputation scores, especially if the issue persists.

Can cloud providers set up IPv6 reverse DNS for me?

Most do not — you must manually configure it with your provider or domain registrar, especially for high-traffic or outbound email services.

How often should I check my reverse DNS setup?

At least monthly, especially after network changes, provider updates, or when setting up new email infrastructure.

Keep reading