What does 'DKIM d= tag not in zone' mean in plain terms?

You sent an email. The signature passed SPF, but the DKIM validation failed with: “d= tag not in zone.” You’re not sure why it’s breaking, especially since mail still lands in inboxes. It’s not about delivery—yet.

This error means the DNS zone for the domain listed in the DKIM d= tag doesn’t have the required DNS record, even if the domain is otherwise valid. It’s like showing up at a building with a key, but the door’s labeled with a different name than the one on your access badge.

This isn’t about real-time delivery. It’s about the technical validation that happens before the message is signed. If the DNS record isn’t there, the signature can’t be trusted—regardless of whether the recipient accepts the email.

Key takeaways

  • DKIM d= tag not in zone means the DNS zone for the domain in the DKIM signature lacks a valid TXT record.
  • Delegating a subdomain to a nameserver doesn’t automatically create the DNS record—configuration must follow.
  • Even valid domains with functional mail delivery can fail DKIM if the d= domain's DNS zone is unconfigured.

How is the DKIM d= tag used in email authentication?

The d= tag in a DKIM signature identifies the domain responsible for signing the email. Receivers use this domain to fetch the public key from DNS, typically at a record like _domainkey.example.com. If the DNS record is missing, non-authoritative, or misconfigured—especially when a subdomain is delegated without proper DNS setup—the signature fails, even if the key is technically correct.

What happens when the d= domain isn't properly configured?

Let's say you send an email from [email protected]. The DKIM signature might use d=company.com as the signing domain. The receiving server then queries DNS for _domainkey.company.com. If that record doesn't exist—or if the DNS zone for company.com doesn't include the subdomain record as authoritative—the validation fails.

This often happens when subdomains like blog.company.com or mail.company.com are delegated to another DNS provider (like AWS Route 53 or Cloudflare) but the parent domain’s DNS isn’t updated to point to them. Without correct delegation or a matching DNS entry, the public key can’t be found. This is a key reason why DKIM fails even when the email body and headers seem clean.

For instance, if you’ve set up DKIM for mail.company.com but the d=mail.company.com DNS record doesn’t exist or is not signed by the domain’s authoritative nameservers, receivers will reject the signature.

How to avoid DKIM failures from missing or incorrect d= settings

Ensure the domain in the d= tag matches the DNS zone where you publish the DKIM record. If you're using a subdomain, the parent domain must either delegate it properly or allow the subdomain’s DNS to be authoritative for the DKIM record. You can verify the DNS setup using tools like MXToolbox or DNSDumpster.

It’s also smart to test your DKIM configuration before sending at scale. You can check a single email’s DKIM signature with our email checker, which verifies the full authentication chain—including D mar, SPF, and DKIM—before sending. For bulk sends, use bulk verification to catch invalid or improperly configured domains early.

The DKIM d= tag isn’t optional—it’s a direct claim. If the domain behind it doesn’t resolve with a valid, authoritative key, the email will fail authentication and may land in spam or be blocked entirely.

Why does the error appear when a subdomain is delegated but not configured?

When you delegate a subdomain like mail.example.com to its own DNS servers, the parent domain no longer controls it. If you haven’t set up a DKIM record at that subdomain level—such as _domainkey.mail.example.com—the receiving mail server can’t find the public key during verification. Since the DNS lookup fails, the server reports a d= tag not in zone error, even if the subdomain exists.

What happens during a DKIM verification check?

When a receiving server processes an email, it checks the d= tag in the DKIM signature. This tag specifies the domain that signed the message—often a subdomain like mail.example.com. The server then attempts to resolve a TXT record at that domain: _domainkey.d= domain. If the subdomain is delegated but lacks a record, the DNS query returns no answer, triggering the “not in zone” error.

This doesn’t mean the domain is invalid—it means the DKIM infrastructure for that domain is incomplete. Delegation alone does not imply configuration. You can delegate mail.example.com to your own DNS, but unless you add the required DKIM TXT record there, the key won’t be found during verification.

Consider this analogy: a post office delegates mail delivery for a neighborhood to a new local branch. If that branch has no address posted, the mail gets returned—even though the neighborhood exists and is active. The same applies to DNS: delegation shifts authority, but without a record, no key is retrievable.

According to RFC 6376 (the DKIM specification), the receiving server must validate the DKIM signature by querying the DNS record at the domain listed in the d= tag. If the record does not exist or is unreachable, validation fails. This is the foundation of how DKIM enforces sender authenticity.

How to confirm your DKIM setup is correct

You can test whether your DKIM record is properly published by using a DNS lookup tool like MxToolbox or checking the record directly with dig TXT _domainkey.mail.example.com. If no result appears, the record is missing—even if the subdomain is active.

If you're managing emails through a third-party service (like senders like Mailchimp or SendGrid), their systems might handle DKIM for a subdomain, but only if you’ve correctly configured and published the record on your end. Many senders auto-generate and publish keys, but only if you’ve authorized the DNS setup.

For teams managing multiple domains or subdomains, a real-time email verification API like MailTester’s API can help catch these issues before sending. It checks if the domain’s DKIM and SPF records are properly configured, reducing the risk of delivery failure due to DNS misconfiguration.

What are typical real-world scenarios where this happens?

When a subdomain like newsletter.company.com is delegated to its own mail server but no DKIM DNS record is added to that subdomain’s zone, the DKIM signature fails validation—even if mail delivery works. The absence of a d= tag in the DNS zone at the subdomain level breaks SPF/DKIM alignment, which harms sender reputation and inbox placement. You can test this with tools like MailTester’s email checker, which verifies if a domain’s DKIM configuration is properly published.

Common configurations that trigger this issue

  • You’re using a separate mail server or ESP (e.g., SendGrid, Mailgun) for transactional emails on a subdomain (e.g., mail.yourcompany.com) but only set up DNS records there for MX or SPF—not DKIM.
  • Your IT team delegated a subdomain via NS records but forgot to add the DKIM TXT record in the subdomain’s DNS zone, assuming the parent domain’s DKIM would cover it (it doesn’t).
  • Automated email setup scripts handled MX or SPF records for a new subdomain but skipped DKIM, especially when using a third-party email service with default templates.
  • You’ve migrated or spun up a new subdomain for marketing purposes and published the SPF record under the parent domain, but the DKIM selector and public key are never published in the subdomain’s DNS zone where they’re expected.
  • A vendor or agency configured mail services for your subdomain but didn’t document or verify that the DKIM record was placed in the correct DNS zone—only MX and SPF were done.

Why this breaks deliverability

DNS-based email authentication relies on precise record placement. A subdomain’s DKIM d= tag must resolve to a key in its own DNS zone, not the parent’s. Even if the subdomain accepts mail, SPF and DKIM alignment will fail if the signature uses a d= tag that doesn’t have a matching public key in its DNS zone. This leads to poor inbox placement and increased spam tagging.

Many mail providers, including Google and Microsoft, use DMARC policies to reject or quarantine messages where DKIM fails validation. This isn’t optional—DMARC enforcement is standard across large inboxes. You can test your DKIM signature’s reachability using MailTester’s inbox placement tool, which checks how your messages land across real provider inboxes.

For deeper context: RFC 6376 (DKIM) mandates that the DNS lookup for the d= domain must be performed in the subdomain’s zone. Misconfigurations like this are common in enterprise environments where multiple teams handle different parts of email infrastructure without centralized oversight.

How to diagnose the missing DKIM d= record in a delegated subdomain?

You're seeing a missing DKIM d= record in a delegated subdomain because either the DNS zone for that subdomain isn’t configured to include the DKIM TXT record, or the delegation to the subdomain’s name servers is misaligned. Use a DNS lookup tool to verify the record exists at the expected location—dig txt _domainkey.subdomain.example.com—and confirm the authoritative servers respond with the proper TXT entry. If not, check the zone setup and delegation.

Step-by-step verification process

  1. Query the full DKIM domain using a DNS tool — Run dig txt _domainkey.mail.example.com or host -t txt _domainkey.mail.example.com. This asks the DNS resolver to find the TXT record for your DKIM selector in the exact domain where it should be published.
  2. Check for NXDOMAIN or empty results — If the query returns NXDOMAIN, the DNS zone doesn't recognize the domain. If no record appears, the DKIM TXT record is missing from the zone. This is common when a subdomain is delegated but no DNS records are yet added.
  3. Confirm the subdomain’s zone includes the DKIM record — Log into the DNS provider for the subdomain (e.g., Cloudflare, AWS Route 53, or your hosting provider) and check that the TXT record for _domainkey.mail.example.com exists, with the correct selector (like selector1) and full DKIM key. A missing or incorrectly spelled record is a frequent cause.
  4. Verify delegation and authoritative servers — Ensure the parent domain delegates the subdomain to the correct name servers. Use dig NS example.com and dig NS mail.example.com to confirm. If the subdomain is delegated, its authoritative servers must respond to queries with the full zone data, including the DKIM entry.
  5. Test across DNS resolvers — Run the same query from multiple public DNS resolvers (like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1) to rule out local caching or resolver issues. Consistent absence across resolvers confirms the record is truly missing in the zone.

Common root causes and fixes

Mistakes often stem from incomplete zone setup after delegation. Just because the subdomain has name servers doesn’t mean it has TXT records. The DKIM RFC specifies the record must be published in the subdomain’s DNS zone, not the parent. Also, ensure the record isn’t truncated or malformed—some providers have character limits or misbehave with long TXT values.

Once you confirm the record is missing or misconfigured, update the DNS zone and wait for propagation. Use a tool like MailTester’s email checker to validate that your DKIM configuration resolves correctly before sending. This helps catch issues before they affect deliverability.

Can a delegated subdomain still pass DKIM if only the parent domain has the record?

No — even if the parent domain has a valid DKIM record, a delegated subdomain cannot pass DKIM validation if the d= tag in the signature points to the subdomain and that subdomain’s DNS zone lacks the required DKIM record. The receiving server checks the domain in the d= tag directly. If the subdomain’s zone is delegated but not configured with a TXT record for DKIM, resolution fails. You cannot rely on the parent domain’s record to validate a subdomain’s signature.

How DKIM validation works in practice

When an email includes a DKIM signature, the receiving server looks up the public key at the domain listed in the d= tag. That domain must be authoritative for its own DNS. If the subdomain is delegated — say, marketing.example.com — but no DKIM record exists in its own zone, the DNS lookup will return no result. The server sees no key, and the signature fails.

Even if the parent domain example.com has a proper DKIM record, that does not help. The receiver doesn’t walk up the DNS chain to check the parent — it looks only at the domain specified in d=. This is consistent with RFC 6376, which defines DKIM’s key retrieval mechanism. The specification states that the signature domain must be able to answer for its own key. If it can’t, the signature is considered invalid.

Why this breaks deliverability

When DKIM fails on a subdomain level, it often leads to lower inbox placement, especially with stricter receivers like Gmail or Outlook. These systems check both SPF and DKIM. If DKIM fails due to missing or unmatched records, the sender’s reputation can be penalized — even if the parent domain is fully compliant.

Let’s say you use [email protected] for outbound campaigns. You’ve set up DKIM only on example.com, assuming it will cover subdomains. It won’t. The d= tag in the signature must resolve to a public key in marketing.example.com’s DNS zone — not the parent's. If it doesn’t, the message fails validation.

To test this before sending, use a real-time email verification tool like MailTester’s email checker to validate both the address and the full email’s authentication chain. It shows you whether SPF, DKIM, and DMARC are aligned and properly configured across domains and subdomains before you send.

What happens to email delivery when DKIM validation fails?

If your email lacks a valid DKIM signature—especially when the d= tag isn’t present in the DNS zone for a subdomain you’ve delegated—the receiver won’t be able to verify the email’s authenticity. DKIM failure doesn’t block delivery outright, but it signals weak sender reputation, increases the chance of spam filtering, and gradually hurts your inbox placement, especially with major providers like Gmail and Outlook.

DKIM: not a gatekeeper, but a credibility signal

Receiving mail servers don’t reject emails outright just because DKIM fails. They do, however, treat failed validation as a red flag—especially if it happens repeatedly. You’re essentially sending a message without a trust badge. Gmail and Microsoft’s inbox filters weigh DKIM consistency heavily when deciding whether an email merits the inbox or gets marked as suspicious.

Let’s be clear: a missing or misconfigured DKIM record—like a d= tag not published for a subdomain you control—doesn’t mean your email never arrives. But it does make it far more likely to be routed to a spam or junk folder. Over time, even a few dozen failed validations can erode trust with inbox providers.

Why bulk sending makes DKIM failures worse

If you’re sending in volume—say, transactional messages at scale, or marketing blasts—repeated DKIM issues become a major liability. High-volume senders are under stricter scrutiny. A single failed signature may not trigger action, but consistent failures across hundreds or thousands of messages signal poor mail hygiene to filters like those used by Gmail.

Some providers track DKIM failure rates as part of their reputation scoring. A long-running pattern of unchecked subdomain DKIM records can correlate with phishing campaigns, spoofing attempts, or compromised infrastructure. That’s why even small misconfigurations matter. Even if you’re not using a subdomain today, validating your entire domain’s DKIM setup helps maintain long-term deliverability.

For a deeper check—not just on DKIM, but on all deliverability signals like spam traps, role accounts, and disposable domains—use real-time verification before sending. Run a single email through the checker to catch issues early. Or use the bulk verification tool to clean entire lists, identify risky addresses, and validate DNS records across your sending domains. This includes catching missing or invalid DKIM setups before they hurt deliverability.

NIST and IETF best practices emphasize consistent alignment between SPF, DKIM, and DMARC—especially in enterprise email systems. You can find the core technical standards at RFC 6376 (DKIM) and RFC 7483 (DMARC). These documents define the expected behavior. When your setup deviates, you’re not violating a rule—but you’re weakening your sender reputation. And that’s not a risk worth taking.

How to prevent this error from affecting deliverability?

If your DKIM d= tag references a subdomain that isn’t properly configured in DNS, receiving mail servers will reject or flag your messages. This breaks authentication and hurts deliverability. Test every DKIM signature in real time, ensure every subdomain used in d= has a valid DNS record, and automate setup when deploying new subdomains. This prevents silent failures that reduce inbox placement and damage sender reputation.

Verify DKIM signatures before sending

  • Use tools that validate both the cryptographic signature and the underlying DNS lookup. A signature can appear valid but fail if the DNS zone is missing or misconfigured.
  • Test with a real email delivery service like MailTester’s inbox placement tester to simulate how your message lands in inboxes across providers.
  • Never assume a DKIM record is effective just because it’s published. Check the full chain: domain, subdomain, selector, and DNS resolve.

Manage subdomain DNS configuration rigorously

  • Each subdomain used in a DKIM d= tag must have its own DNS zone with a properly published DKIM record. Delegation alone isn’t enough.
  • If you use mail.example.com in d=mail.example.com, the mail subdomain must have a functional DNS zone with a valid txt record for the DKIM selector.
  • Use RFC 4871 (the DKIM specification) as a reference for correct syntax and placement — the original RFC details how signatures must be verified using the d= domain.
  • When setting up email for new subdomains, treat DKIM record deployment as mandatory — not optional or “maybe later.”
  • Automate DKIM record creation across all subdomains used for email via infrastructure-as-code or email platform integrations. This reduces human error and ensures consistency.
  • Use a bulk email verification tool like MailTester’s email list verifier to catch invalid or misrouted addresses before sending, including cases where DKIM domains are missing.
  • Monitor for mismatches between your d= tag and DNS records using third-party tools like MxToolbox or dmarcanalyzer.com before launching campaigns.
A misconfigured d= tag doesn’t always cause immediate bounce — but it damages sender reputation over time. Even one failed verification can lead to throttling or filtering.

How does MailTester help verify DKIM configuration and avoid these errors?

You can catch DKIM d= tag issues early by testing your domain’s authentication setup before sending. MailTester checks whether DKIM, SPF, and DMARC records are properly configured and aligned, flagging cases where the subdomain’s DNS zone hasn’t been updated despite delegation. This prevents send failures caused by misconfigured signing domains, especially when the d= tag points to a subdomain that lacks a valid DKIM record.

Real-time checks for DKIM validity

Let’s say your email client or ESP is using a subdomain like mail.yourcompany.com for DKIM signing. If that subdomain is delegated to a nameserver but no DKIM record exists there, your email will fail authentication. MailTester’s real-time verification API checks that the domain specified in the d= tag is reachable and valid. It doesn’t just read DNS; it attempts to resolve the record, confirming whether your DKIM public key is actually published where it needs to be.

Use the real-time verification API to catch these issues programmatically — you can plug it into your onboarding or sending workflows. It returns clear results: “Valid,” “Invalid,” “Catch-all,” or “Risky,” helping you avoid sending to addresses where authentication fails due to missing or malformed DKIM records.

Bulk checks reveal systemic risks

If you’re managing a large email list, you can’t check each address manually. MailTester’s bulk email verification feature scans thousands of recipients at once, identifying domains that lack proper DKIM (or SPF, DMARC) configuration. This reveals patterns — such as multiple addresses on a single subdomain with no DKIM record — before you send to them.

This is especially useful when dealing with shared or outdated domains. For example, a domain might have been split, and the new subdomain’s DNS not yet updated. By detecting such gaps early, you avoid sending to addresses that will be rejected on authentication grounds — and reduce your risk of hitting blacklist triggers or losing sender reputation.

Authentication alignment is a requirement for strong deliverability. RFC 6376 specifies that DKIM signatures must include a domain that matches the sending domain's DNS zone. Tools like MailTester help you verify that this condition holds — not just in theory, but in practice — by testing the real DNS resolution and response.

For full visibility into how your emails will perform in real inboxes, run inbox placement tests with real-world conditions. These tests simulate major inboxes (Gmail, Outlook, Apple) and surface authentication failures, including issues with the d= tag, before they affect your delivery rate.

What should you do if your subdomain is delegated but not yet configured?

Delegation does not mean configuration. A delegated subdomain does not inherit DNS settings from its parent domain. This includes DKIM records, SPF policies, and any other email authentication mechanisms.

Immediately create the required DKIM TXT record in the subdomain’s DNS zone using the exact selector and key. Leaving this step incomplete will result in failed authentication during email delivery, leading to bounces or spam filtering.

Before sending any mail through the subdomain, verify the TXT record is publicly visible using tools like MXToolbox or DNSLeakTest. Visibility ensures the record is correctly propagated and recognized by receiving mail servers.

Sources

Keep reading

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

Frequently asked questions

Does a missing DKIM record block email delivery?

No — delivery may still succeed, but the email is less trusted. Repeated failures harm sender reputation and reduce inbox placement over time.

Can I use a parent domain’s DKIM record for a subdomain?

Only if the sender policy allows it. By default, the d= tag must reference a domain that has its own authoritative DNS configuration for DKIM.

How can I check if a DKIM record exists for a subdomain?

Use DNS lookup tools like dig or mxtoolbox.com to query the TXT record at _domainkey.subdomain.example.com.

Why does 'not in zone' mean the record isn’t found?

The authoritative DNS server for the domain in the d= tag is not responding with data. This often means the zone is missing or misconfigured.

Is DKIM required for email deliverability?

Not required by all systems, but strongly recommended. Missing or failed DKIM significantly impacts spam filtering and inbox placement.

Can a subdomain be authenticated if it’s only delegated but not yet active?

No — delegation means authority is transferred. If no DKIM record is added, validation will fail for any email signed with that domain.

How does MailTester detect 'DKIM d= tag not in zone' errors?

It performs DNS lookups on the domain specified in the d= tag and checks for existence and format of the DKIM TXT record.

Does MailTester work with subdomain-specific DKIM checks?

Yes — it validates DKIM signatures using the domain in the d= tag, regardless of whether it’s a root or subdomain.

Can a catch-all domain affect DKIM verification?

Yes — if the domain is catch-all, recipients may not be validated, but DKIM still requires a valid, reachable DNS record.

How often should I verify DKIM configurations?

After any DNS change, before launching new campaigns, and periodically — at least monthly for high-volume senders.

What happens if I fix the DKIM record after some emails were sent?

The sender reputation improves over time. But earlier failures may already have affected email filtering and inbox placement.

Why does a subdomain with correct DNS still show 'not in zone' occasionally?

DNS propagation delays or transient outages may cause temporary failures. Retest after 24–48 hours to confirm resolution.