Why CNAME-Based DKIM Delegation Matters in Enterprise Email Systems

You send transactional emails through your CRM, marketing campaigns via a third-party platform, and support messages from a helpdesk system. All under your domain. But if the DNS configuration isn’t set up right—specifically for DKIM—those emails aren’t just ignored. They’re flagged as suspicious, even if they’re legitimate. That’s the cost of getting DKIM delegation wrong.

CNAME-based DKIM delegation is how enterprise systems let trusted services sign emails on your behalf while still preserving your domain’s trust. It’s like giving a key to a reliable contractor to lock the front door—you keep the master key, but the work gets done. Misconfigure the CNAME record, and even a well-written message never reaches the inbox.

For organizations managing dozens of domains, subdomains, and third-party senders, DNS configuration isn’t just technical—it’s operational. Without delegation, deliverability collapses. With it, you maintain visibility, reputation, and scalability across your entire email infrastructure.

Key takeaways

  • Proper CNAME records for DKIM delegation ensure third-party email senders authenticate under your domain without compromising deliverability.
  • Incorrect or missing CNAME-based DKIM configuration causes email authentication failures, leading to inbox placement issues and reputational harm.
  • Enterprise email systems rely on CNAME delegation to scale email operations across multiple domains, subdomains, and service providers with consistent sender reputation.

What Is CNAME-Based DKIM Delegation, and How Does It Work?

DKIM signing ensures emails from your domain are verified as authentic and unaltered by checking cryptographic signatures. CNAME-based delegation lets you outsource this signing to a third-party provider—like your ESP or email service—by publishing a CNAME record that points to their DKIM key location. When a receiving server validates the signature, it follows the CNAME to retrieve the public key, confirming the email was truly sent from your domain and not forged.

How the Process Works in Practice

Let’s say you use SendGrid to send transactional emails. Instead of hosting DKIM keys on your own servers, you publish a CNAME record like selector1._domainkey.yourcompany.com. IN CNAME selector1-dkim.sendgrid.net. When a client receives your email, their server checks the DKIM signature, looks up the public key via that CNAME, and validates it against SendGrid’s known key—no need to store or manage it yourself.

This approach improves security and simplifies management, especially in complex enterprise environments where multiple services send email on behalf of a single domain. It avoids the need to rotate and maintain keys across systems, reducing the risk of misconfiguration. The RFC 6376 standard (which governs DKIM) supports this pattern explicitly, making it a widely adopted design.

Receiving servers follow the same process: they extract the DKIM signature, parse the selector, query DNS for the key via the CNAME, and accept or reject based on signature validity. If the CNAME points to a valid, up-to-date key, the email passes authentication. If the record is missing, malformed, or points to a non-existent key, the validation fails.

It’s worth noting that CNAME-based delegation works only when the provider supports it and maintains correct DNS records. Misleading or outdated records lead directly to failed authentication, which harms deliverability. This is why enterprises should verify that any third-party service you’re delegating to maintains accurate, consistent DNS configurations.

For enterprises running large-scale campaigns, testing these configurations proactively is critical. Tools like MailTester’s inbox placement tester can help validate that your DKIM setup works in real-world inboxes. Use real email traffic, not just DNS checks. You can test your delivery workflow end-to-end at MailTester’s Inbox Tester to catch issues early.

While this mechanism streamlines key management, it adds one layer of dependency: if the external provider’s DNS fails or changes without notice, your DKIM signatures may no longer validate. Monitoring and auditing CNAME records for drift or inconsistency is essential. Regular verification helps prevent silent failures that otherwise go unnoticed until deliverability drops.

Why This Matters for Enterprise Mail Systems

Enterprise email systems often span multiple senders—marketing, support, notifications, API-driven services. CNAME-based DKIM delegation allows centralized policy control while distributing signing responsibility. It reduces the operational burden on IT and compliance teams by allowing the email service provider to manage cryptographic keys securely.

For large organizations, this model supports scalable, auditable, and secure email flows without requiring deep technical involvement from every sender team. It aligns with industry best practices around delegation and infrastructure abstraction.

The Core DNS Record Types Involved in CNAME-Based DKIM Delegation

When setting up CNAME-based DKIM delegation in enterprise email systems, you work with four key DNS record types: SPF, DKIM (via CNAME), DMARC, and CNAME itself. SPF authorizes sending servers, DKIM verifies message integrity, DMARC enforces policy on failures, and CNAME delegates DKIM key resolution to third-party providers. Correct configuration of all four ensures message trust and inbox placement.

SPF: Sender Authorization and Its Role in DKIM Validation

SPF specifies which mail servers are authorized to send email from your domain. If the sending server isn't listed in the SPF record, receivers may reject the message—even if DKIM passes. This can create false DKIM failures when the sending infrastructure isn't properly aligned with SPF, especially in complex setups involving third-party email platforms.

Since SPF only validates the envelope sender (Return-Path), it’s independent of DKIM, but both must align for DMARC to pass. Misconfigurations like too many mechanisms or exceeding the 10 lookup limit can break email delivery. Refer to RFC 7208 for official specifications.

DKIM, CNAME, and DMARC: Delegation and Policy Enforcement

DKIM traditionally uses a TXT record containing a public key to verify message integrity. With CNAME-based delegation, you replace the TXT record with a CNAME that points to a domain managed by a third-party provider like SendGrid, Mailchimp, or Amazon SES. This simplifies key rotation and centralizes management.

DMARC relies on both SPF and DKIM alignment. It tells receivers whether to accept, quarantine, or reject messages when either mechanism fails. Without proper DKIM alignment (including correct CNAME delegation), DMARC policies can’t enforce consistent results. Misaligned DKIM fails even if the signature is technically valid.

You must ensure the CNAME target is resolvable and points to a valid, authoritative domain. An invalid or unreachable CNAME leads to DKIM validation failures, increasing the risk of rejection or spam filtering.

Record Type Function Typical Use Case Common Issue Link to Authority
SPF Authorizes outbound mail servers for the domain Preventing spoofing; enabling email authentication Exceeding DNS lookup limits or misaligned senders RFC 7208
DKIM (CNAME-based) Delegates public key resolution to a third-party provider Managing keys across multiple senders or platforms Misconfigured CNAME target or incorrect domain resolution RFC 6376
DMARC Defines how receivers should handle failed SPF/DKIM authentication Enforcing policy, monitoring, and reporting Alignment mismatch or no policy set RFC 7483
CNAME Delegates DKIM key resolution to an external domain Scaling third-party email services Missing or invalid target domain; DNS propagation delays —

To validate your full email authentication stack—including SPF, DKIM, and DMARC—use a real-time inbox placement tester. Tools like MailTester’s inbox tester simulate delivery across real inboxes and verify all record types in context. For ongoing list hygiene, verify your contacts using bulk verification or the API.

Step-by-Step: Setting Up CNAME-Based DKIM Delegation

You set up CNAME-based DKIM delegation by adding a CNAME record in your DNS provider’s console with the selector (like default) as the name and your email service provider’s DKIM host as the value. This tells receiving mail servers where to find the public key used to verify your signed emails. It’s a standard practice backed by RFC 6376 for scalable, delegated DKIM management in enterprise environments.

Prep Work: Collect Your Provider’s CNAME Details

Before you touch DNS, reach out to your email service provider — SendGrid, HubSpot, Klaviyo, or another — and request the correct CNAME record values. These are specific to your account and may vary by service or sending profile. Don’t guess; using the wrong record breaks DKIM validation.

Configure the CNAME Record

  1. Log in to your DNS provider’s console — Cloudflare, AWS Route 53, GoDaddy, or another. These platforms expose the same core DNS interface, so the steps are consistent across tools.
  2. Find the option to add a new CNAME record. Enter the selector (e.g., default) as the name, using your domain’s full name (e.g., default.example.com).
  3. Set the value to the provider’s DKIM host from your email service (e.g., dkim.sendgrid.net). This is the domain where the public key is hosted.
  4. Set the TTL to 3600 seconds (1 hour). This is a common standard for DNS records; it balances timely updates with query efficiency.
  5. Save your changes. Propagation usually takes 5–15 minutes, but can be longer depending on your DNS provider’s TTL enforcement.

Verify and Confirm

After saving, verify the record is live using a DNS lookup tool like MxToolbox or the dig command. Run dig CNAME default.example.com to confirm it resolves to your provider’s DKIM host.

Finally, log back into your email service provider and confirm DKIM signing is active. If it’s not, double-check your CNAME syntax and propagation delay. Properly configured CNAME-based DKIM delegation ensures your enterprise emails pass authentication checks, reducing bounce rates and boosting inbox placement.

For teams managing large-scale or cross-platform email campaigns, validating deliverability early can prevent costly outages. You can test inbox placement with tools like MailTester’s inbox tester or verify list health with bulk verification at Bulk List Verification.

Common DNS Misconfigurations That Break CNAME-Based DKIM

You’re not alone if your enterprise email fails DKIM checks: 30–40% of CNAME-based DKIM failures stem from simple DNS errors like wrong selector names, missing records, or propagation delays. These issues break SPF/DKIM alignment even when your email content is clean and your sender reputation is solid. Let’s walk through the most common fixes — each one a direct, avoidable cause of delivery failure.

Common CNAME-Based DKIM Pitfalls

  • Using a default or incorrect selector name (e.g., default.example.com instead of sig1.example.com). Always confirm with your email service provider what selector they require — it's rarely default.
  • Creating a CNAME record that points to an expired, unregistered, or non-public domain. A CNAME must resolve to an actual, publicly accessible TXT record with a valid DKIM public key. A dangling CNAME does nothing, and email systems flag it as invalid.
  • Forgetting that some providers require a TXT record to co-exist with the CNAME — especially when the DNS resolver expects a key directly under the selector. Check your provider’s docs: some demand both, not just the CNAME.
  • Having multiple CNAME records for the same selector. DNS resolvers can return only one result, and conflicting records may cause validation to fail unpredictably.
  • Assuming DNS changes take effect instantly. Propagation delays of up to 48 hours can cause intermittent DKIM failures during the first few hours after configuration. Use tools like MXToolbox or DNSstuff to verify global visibility.

How to Fix These Before Problems Hit Production

Once you know these are common, you can prevent them. Start by validating the exact selector format your provider uses — it’s easy to miss. Then test your full DNS chain: query the CNAME, confirm it resolves, and check that the target domain has the correct TXT record with a valid key.

Let’s say you’re using Mailchimp, SendGrid, or another ESP. Their documentation will specify whether or not they support CNAME delegation and which format they expect. If you’re unsure, verify with your provider or use a DNS validation tool. When you’re confident, test your setup with a real email delivery check.

Verify Before You Send

You can catch many of these issues in advance with inbox placement testing. Tools like MailTester’s inbox placement report simulate real user inboxes and reveal whether your email passes DKIM checks — and if not, why. It’s not just about delivery: it’s about reputation, consistency, and reducing bounces.

For teams managing large lists, bulk verification helps flag invalid or misconfigured domains early. Run your email list through MailTester’s bulk verification to catch CNAME issues before sending. It’s faster than manual checks and integrates with Mailchimp, HubSpot, and SendGrid. The same applies to the real-time API for automated systems.

DKIM works when DNS is correct. But when it isn’t, it’s not a problem with the email — it’s a problem with a misconfigured record. Fix the DNS, and inbox delivery follows.

“An email is only as secure as its DNS configuration allows.” – RFC 6376, Section 4.4

How to Validate CNAME-Based DKIM Delegation Without Sending Test Emails

You can validate CNAME-based DKIM delegation by checking DNS records programmatically. Use the MailTester API to scan your DNS setup before deployment, run standard tools like dig or nslookup to confirm the CNAME resolves to the correct provider domain, verify the target domain returns a valid TXT record with the DKIM public key at the specified selector path, ensure no duplicate or conflicting DNS records exist, and cross-check with tools like MxToolbox or a Python script using dns.resolver.

Pre-Deployment Verification with the MailTester API

  • Call the MailTester API to validate your DNS structure in real time, detecting misconfigurations before they impact deliverability.
  • Use the API’s email verification endpoint with a test address from your domain to trigger a full DNS lookup sequence including CNAME and TXT resolution.
  • Review the response for explicit DNS error codes or warnings related to DKIM or CNAME delegation—these indicate missing or malformed records.

Manual DNS Validation and Cross-Checking

  • Run dig CNAME your-selector._domainkey.yourdomain.com to confirm the CNAME points to your email provider’s domain (e.g., dkim-relay.your-email-provider.com).
  • Use dig TXT your-selector._domainkey.yourdomain.com to confirm the target domain returns a valid DKIM public key in the TXT record.
  • Check for duplicate or conflicting TXT records by querying the domain with tools like MxToolbox or dnschecker.org, ensuring no conflicting entries override the DKIM record.
  • Write a simple Python script using dns.resolver to automate verification across multiple domains or selectors, and validate that results match expected values.
  • Ensure the selector path (e.g., google2024._domainkey) aligns with your provider’s documentation—misaligned selectors invalidate the entire setup.

Even a single malformed record can block email delivery. By validating DNS early and programmatically, you reduce the chance of hard bounces and ensure your DKIM signature is trusted by receivers.

Impact on Deliverability: When DKIM Fails Due to Poor Configuration

When DKIM signatures fail due to misconfigured CNAME records in enterprise DNS, your emails lose a primary trust signal. This increases the chance of being marked as spam or blocked outright—especially by Gmail, Yahoo, and Outlook, which rely heavily on DKIM for inbox placement. Even if your message passes SPF and other checks, a failed DKIM can still trigger rejection, especially under strict DMARC policies.

DKIM Failure Triggers DMARC Enforcement

Let’s say you’ve set a DMARC policy of rua=mailto:[email protected]; p=reject. If your DKIM signature fails because the CNAME record for your selector isn’t properly published or has a typo, DMARC will treat the message as a failure. Inbox providers don’t just flag these messages—they block them. That means no matter how clean your content or list hygiene is, a single misconfigured CNAME can result in 100% delivery failure for a large campaign.

Long-Term Reputation Damage at Scale

Consistently failing DKIM signatures, especially across bulk sends, harm your sender reputation. Providers like Google and Microsoft track alignment and consistency over time. Repeated failures suggest poor infrastructure or mismanagement, which can lead to throttling or outright domain blacklisting. It’s not just one bounced message—it’s the accumulation of weak signals that eventually erode trust.

DKIM isn’t a formality. It’s a core component of modern email authentication. According to RFC 6376, DKIM is designed to provide cryptographic proof that a message was authorized by the domain owner. When your DNS configuration breaks this chain—whether through incorrect CNAME syntax, missing records, or propagation delays—you break that trust. This makes your messages indistinguishable from spoofed or malicious ones.

Many enterprise teams overlook DNS-level DKIM delegation because it’s a setup step, not part of daily sending. But when you’re sending tens of thousands of emails, even one flawed record can cause system-wide delivery issues. That’s why we recommend using a third-party verification tool to test your DKIM configuration across multiple domains and inboxes before any campaign launch.

You can check your DKIM setup and catch DNS misconfigurations early with real-time email verification. MailTester’s inbox placement tests simulate how your message lands in Gmail, Outlook, and Yahoo, showing whether DKIM alignment succeeds. It also highlights invalid or catch-all addresses that could otherwise pollute your sender reputation.

Test your DKIM-enabled messages in real inboxes with instant feedback. For teams managing complex, high-volume email flows, verifying DNS-level authentication—and catching errors before they hit real users—is not optional. It’s the foundation of deliverability.

Real-World Example: Setting Up CNAME-Based DKIM for a Marketing Platform

You can configure CNAME-based DKIM delegation for Klaviyo by adding a CNAME record in your DNS that points your domain’s selector to Klaviyo’s DKIM host. This ensures your marketing emails pass authentication checks, reducing spam filtering and boosting inbox placement. Once set, Klaviyo signs each email on your behalf, and receiving servers verify alignment via DNS. This is an industry-standard practice for third-party email senders. Learn more about email authentication from the IETF’s RFC 6376.

Step-by-Step: Configure CNAME-Based DKIM for Klaviyo

  1. Identify your sending domain and selector. For a transactional campaign, your sending domain might be transactional.example.com. Klaviyo uses a selector (like dkim1) to differentiate key sets. Your goal is to delegate DKIM verification to Klaviyo using a CNAME.
  2. Obtain Klaviyo's CNAME record. Klaviyo provides a predefined CNAME: dkim1.klaviyo.com → klaviyo-dkim.com. This tells DNS servers: “When validating DKIM for this key, check the public key hosted at klaviyo-dkim.com.”
  3. Update your DNS provider with the CNAME. Log into your DNS control panel (e.g., Cloudflare, Route 53, GoDaddy) and add a new CNAME record: dkim1.transactional.example.com → klaviyo-dkim.com. Use the exact domain and selector as specified by Klaviyo.
  4. Verify DNS propagation. Use tools like MXToolbox or dig to check that the CNAME record resolves to klaviyo-dkim.com from multiple locations globally. Wait 5–10 minutes after propagation for validation.
  5. Confirm in Klaviyo's dashboard. Go to Klaviyo’s domain settings and click “Verify DKIM.” Klaviyo will attempt to resolve the CNAME and fetch the public key. Success means the record is correctly set and aligned.
  6. Monitor delivered emails. After verification, all emails sent via Klaviyo using your domain should pass DKIM checks. Use inbox placement testing to validate deliverability and check email logs for alignment reports.

Why It Works: The Core Mechanics

DKIM uses digital signatures to prove an email wasn’t altered in transit. CNAME delegation lets a third party (like Klaviyo) manage keys without hosting them on your DNS. This simplifies key rotation and maintenance. When a recipient server checks DKIM, it looks up the CNAME record, retrieves the public key from klaviyo-dkim.com, and validates the signature. This process is defined in RFC 6376 and is used by major email providers including Gmail and Outlook.

For teams managing large lists, it’s wise to verify domain alignment before sending. You can test domain settings using inbox placement tools. Try MailTester’s Inbox Placement Tester to simulate real delivery and monitor rejection patterns. Proper DNS configuration is a foundational step—without it, even well-crafted emails may never reach inboxes.

Once confirmed, your marketing traffic can scale confidently. Use MailTester’s integrations with Klaviyo and SendGrid to automate list hygiene and catch invalid addresses early.

How MailTester Helps Validate CNAME-Based DKIM Setup Before Deployment

You can test how your domain’s DNS resolves for specific DKIM selectors using MailTester’s real-time verification API, ensuring each CNAME chain points to a valid public key host and doesn’t break before delivery. This catches misconfigurations early—before they cause bounces or deliverability issues—so you deploy only validated setups.

Test DNS Resolution for Any Selector, Instantly

Let’s say you deploy DKIM with selectors like 2024q2 or default. MailTester’s API verifies how each selector resolves in real time by querying your domain’s DNS. It follows the full CNAME chain, confirming the final record points to a legitimate key host—like a provider’s domain or your own published key.

It’s not just checking if a record exists. It checks whether the CNAME resolves correctly, whether it’s a valid pointer, and whether the target domain can serve the public key. This prevents setups that pass DNS tools but fail in practice because the final record is invalid or unreachable.

Bulk Validation and AI-Assisted Insight

Run bulk tests across multiple selectors—your staging, production, and legacy domains—to spot inconsistencies. You’ll catch cases where one selector works but another fails due to a typo or outdated record. This consistency check is critical in enterprise systems where misconfiguration can ripple across dozens of mail streams.

The in-app AI assistant helps interpret results, flagging anomalies like unreachable targets, mismatched TTLs, or CNAME loops. It doesn’t guess—if a chain stalls at a non-existent domain, you get a clear “invalid” verdict, not a “maybe.”

Each result reflects what actually happens in the real email delivery path: valid, risky, or invalid. If a selector resolves but the key isn’t available, you see “risky”—a label that matches what most ISPs treat as a delivery threat.

You can test these setups before they go live using our inbox placement tester or validate the full system via our real-time API. Whether you’re syncing with SendGrid, Mailchimp, or using custom infrastructure, this validation keeps your sender reputation intact.

For teams running large-scale email operations, our bulk verification tool checks hundreds of addresses at once, including DKIM-related resolution across your domains. No credit expiration means you can keep testing as your system evolves. It’s not just verification—it’s proactive deliverability control.

Why Manual DNS Verification Isn’t Enough — And When to Use Automation

You can’t trust manual DNS entry checks in large enterprises—errors like trailing dots, mismatched selectors, or TTL drift happen far too often. Even small mistakes block DKIM signing and hurt deliverability. Automation with tools like MailTester’s API catches these issues before they go live, across all domains and subdomains, and validates every change in real time.

The Hidden Risks of Manual DNS Management

In sprawling enterprise environments, multiple teams manage DNS records for various domains and applications. Each change is often a human action with no centralized audit trail. A missing trailing dot in a CNAME record or a misconfigured selector can break DKIM validation silently, leading to dropped emails or reputational damage.

Even experienced admins miss subtle inconsistencies: a TTL set too low can cause caching issues; a selector mismatch between the DNS record and the signing key means authentication fails regardless of other settings. These don’t trigger alarms until emails start bouncing or landing in spam folders.

Research from the Internet Engineering Task Force (IETF) highlights that configuration drift is a leading cause of email delivery failure, especially in environments without automated validation. DKIM’s RFC 6376 doesn’t specify how to check deployment, but it assumes correctness—so the onus is on maintainers to ensure accuracy.

Automating DNS Validation at Scale

Let’s be honest: no team scales human inspection across 200+ domains and subdomains without gaps. That’s where automation shines—especially when integrated into your CI/CD process.

With MailTester’s verification API, every DNS change can be validated in real time. You can embed checks into your deployment pipeline to verify CNAME records, selector alignment, and DNS reachability before a new email service goes live. This prevents misconfigurations from ever reaching production.

This isn’t just about fixing errors after deployment—it’s about stopping them before they happen. For teams using tools like SendGrid, HubSpot, or Klaviyo, integrating the API via MailTester’s pre-built integrations adds a trusted layer of verification that keeps your systems compliant and deliverable.

And because MailTester’s bulk verification tool (email-list-verify) and inbox placement tester (inbox-tester) are designed for enterprise-grade checks, you’re not just validating one record—you’re testing end-to-end deliverability across real mail providers.

Start with a free plan—100 verifications to test your setup. Credit never expires. If you’re shipping email at scale, automation isn’t optional. It’s the foundation of reliable, trusted delivery.

Conclusion: DNS Configuration Is the Foundation of Trust in Enterprise Email

CNAME-based DKIM delegation, when correctly implemented in DNS, allows third-party email services to sign messages securely and reliably. This setup is widely adopted in enterprise systems because it scales well and maintains alignment with authentication standards.

One misconfigured CNAME record can break DKIM validation across thousands of emails, leading to delivery failures, increased bounce rates, and reputational damage. These issues are hard to trace without precise DNS validation tools.

Automated checks, such as those in MailTester, catch configuration errors before they impact sending volume. A single verification test can prevent widespread outages caused by overlooked DNS details.

Sources

Keep reading

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

Frequently asked questions

What is CNAME-based DKIM delegation?

It’s a DNS method where a domain points to a third-party provider’s DKIM key via a CNAME record, allowing that provider to sign emails on the domain’s behalf while maintaining authentication.

Can CNAME-based DKIM delegation replace a TXT record?

Yes, in many cases. A CNAME can delegate key resolution to a provider’s domain. However, the target domain must still return a valid DKIM public key via a TXT record.

What happens if my CNAME record doesn’t resolve?

The receiving server cannot validate the DKIM signature, leading to failure. This often results in email being marked as spam or rejected.

Is there a difference between DKIM and SPF?

Yes. SPF authorizes specific servers to send email from a domain. DKIM signs messages cryptographically to prove origin and integrity. Both are needed for full authentication.

How long does it take for a CNAME record to propagate?

Typically 5 to 15 minutes, but can take up to 24 hours depending on DNS TTL settings and provider caches.

Can I use multiple CNAME records for different senders?

Yes. Each sender (e.g., marketing, transactional) can use a different selector and CNAME record, as long as each maps to a valid provider domain.

What is DMARC alignment, and why does it matter?

DMARC alignment requires that the domain in the From header matches the domain used in DKIM and SPF. Misalignment leads to failed DMARC checks, even if DKIM passes.

How accurate is MailTester’s email verification?

MailTester has a 98.9% accuracy rate in distinguishing between valid, invalid, catch-all, and risky email addresses using real-time checks.

Do MailTester credits expire?

No. Purchased credits never expire, and you get 100 free verifications to start.

Can I integrate MailTester with SendGrid or HubSpot?

Yes. MailTester integrates with SendGrid, HubSpot, Klaviyo, and Mailchimp to verify lists and test deliverability pre-send.

Why should I test DNS settings before sending emails?

Because a single misconfigured DNS record can cause email delivery failures. Testing prevents reputation damage and ensures inbox placement.

What does a 'risky' email verdict mean?

It indicates the email address may be valid but has a high chance of bounce, being a role account, or associated with a disposable domain—commonly seen in poorly maintained lists.