What does 'DNS DKIM a tag unknown' mean and why does it break email delivery?

You sent an email that passed every test—valid address, clean content, proper formatting—yet it never reached the inbox. Instead, you got a soft bounce with a baffling error: "DNS DKIM a tag unknown." What now?

This isn’t about the recipient’s email being wrong. It’s about a mismatch in your domain’s email authentication setup. The receiving mail server found a DKIM signature, but the selector (the "a tag") it referenced in your DNS TXT record doesn’t exist. It’s like showing up at a secure building with the right badge, but the access code doesn’t match any known door.

Fixing this isn’t about scrubbing your mailing list—it’s about aligning your DNS records with the actual DKIM keys used to sign messages. Left uncorrected, this breaks inbox placement and slowly damages your sender reputation. The good news? You can identify and fix it, even at scale.

Key takeaways

  • DNS DKIM a tag unknown indicates a selector mismatch between DKIM signature and DNS TXT record
  • It causes soft bounces or inbox placement failure despite valid email addresses and clean content
  • Resolution requires aligning the selector in the DKIM signature with the correct DNS TXT record, not altering email addresses

How DNS DKIM verification works: the handshake that fails silently

When an email is sent, the sending server adds a DKIM signature with a selector (like 'default' or 's1') and a cryptographic hash. The receiving server checks the sender's domain for a matching TXT record under selector._domainkey.yourdomain.com. If that record is missing, malformed, or references a non-existent selector, validation fails silently with a 'tag unknown' error—no bounce, no alert, just lost deliverability.

The DKIM lookup: a silent dependency

DKIM relies on DNS to verify authenticity—no DNS, no trust. The receiving server pulls the public key from the domain’s DNS using the selector from the email’s signature. A missing or misformatted TXT record means the server can’t verify the signature. This is where ‘tag unknown’ appears: the recipient system sees an unrecognized or unstructured tag, usually due to a syntax error or misconfiguration.

For example, if the selector is 's1' but no record exists under s1._domainkey.yourdomain.com, or if the TXT value isn’t properly formatted (e.g., missing quotes, invalid base64), the validation fails. This isn’t always detected immediately—most email systems log such failures internally and do not notify the sender.

Common causes of ‘tag unknown’

These are the most frequent root causes: a typo in the selector, a missing DNS record, or a malformed record (e.g., double quotes, incorrect syntax). It's common for automated systems to generate DKIM records with slight errors—especially if a new selector is added without updating the DNS.

MailTester’s email checks can surface these issues before you send. Its real-time verification API validates DNS records, including DKIM, during list hygiene. You can test a single address at https://mailtester.com/email-checker/ or verify entire lists via bulk verification at https://mailtester.com/email-list-verify/. This helps catch DNS flaws early, before they hurt deliverability.

The process is defined in RFC 6376, the standard for DKIM. You can review it at IETF’s official document to see how the cryptographic check works, including how the selector and public key exchange is structured. A valid signature depends entirely on correct DNS setup.

Common causes of 'a tag unknown' in DKIM records

If your DKIM verification fails with "a tag unknown," it often means the DNS TXT record for your domain’s DKIM selector contains a syntax error, outdated key, or mismatches your email service’s current signing key. This typically breaks email authentication, leading to inbox placement issues or outright rejection. Let's walk through what's likely going wrong.

  • You changed the DKIM selector in your email service provider (like SendGrid or Mailchimp) but forgot to update the corresponding DNS TXT record. A mismatch between the selector in your email provider and the one in DNS will trigger a "tag unknown" error during verification.
  • The TXT record was copied incorrectly—extra spaces before or after, missing leading or trailing quotes, or using the wrong subdomain (e.g., selector._domainkey.yourdomain.com vs selector._domainkey.yourdomain.com. with a trailing dot). Even small syntax glitches break DKIM validation.
  • Third-party services like Amazon SES, SendGrid, or Mailchimp periodically rotate their signing keys. If they updated their key but your DNS record wasn’t refreshed, the DKIM signature becomes invalid, causing "a tag unknown" or a hard failure in email validation.
  • Your domain uses multiple DKIM keys—say, one for transactional mail, another for marketing—across different platforms. If one selector is stale or missing while the others are active, receiving servers may report "a tag unknown" when checking the inactive or outdated selector.
  • You’re using a custom or outdated key setup, possibly inherited from older configurations. Some systems expect a specific format, and if your record’s structure deviates from the RFC 6376 standard, authentication fails.

How to validate your DKIM setup

Use a real-time DNS lookup tool to confirm the TXT record exactly matches your provider’s current configuration. You can test this with MXToolbox or RFC 6376, which defines the DKIM specification. The record must include the correct selector, proper key format, and no extra delimiters.

  • Browse your email service’s documentation to confirm the current DKIM selector and public key. Always double-check before updating DNS.
  • Use the MailTester email checker to verify if a specific recipient’s address passes DKIM validation before sending to catch issues early.
  • If you manage multiple domains or email channels, maintain a clear, updated inventory of all active DKIM selectors and their associated services.

Fixing "a tag unknown" starts with matching your DNS records to your live email infrastructure. Don’t assume your system has kept up with recent changes—verify it.

Step-by-step: Diagnose and fix 'DNS DKIM a tag unknown' errors

If your email service reports a "DNS DKIM a tag unknown" error, it means the DKIM signature header includes a selector that doesn’t match any valid DNS record. You need to verify the DKIM signature from the email headers, locate the selector, cross-check it in your DNS records, and ensure the TXT record at selector1._domainkey.yourdomain.com contains a properly formatted public key. Use tools like MxToolbox or Google Public DNS to test your record. Fixing it requires correcting the DNS entry, waiting for propagation, and confirming delivery success with a real inbox test.

Step-by-step diagnosis and fix

  1. Confirm the DKIM signature is present in the email headers. Use a real-time email verifier like MailTester’s email checker to pull the raw headers of a sent message. Look for a DKIM-Signature header. If it’s missing, the issue is outside DNS — likely a misconfigured email sender.
  2. Extract the selector from the DKIM-Signature header. The header will look like DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1;. The value after a= is the selector — in this case, selector1. This is the DNS lookup key.
  3. Check your DNS record at the exact location. Query the TXT record for selector1._domainkey.yourdomain.com using tools like MxToolbox or dig TXT selector1._domainkey.yourdomain.com. If the record is missing or shows an error, the DKIM check will fail.
  4. Validate the TXT record format. The record must start with v=DKIM1; and specify the key type with k=rsa;. The public key must follow p= without extra characters, line breaks, or spacing. An incorrectly formatted record will be rejected by receivers.
  5. Recreate or update the record if missing or malformed. Log in to your email service’s admin panel (e.g., SendGrid, Sendinblue, Amazon SES) and regenerate the DKIM key pair. Use the public key provided to create a new TXT record in your DNS zone. Avoid copying keys with extra spaces or quotes.
  6. Wait for DNS propagation. DNS changes can take up to 48 hours to propagate globally. In practice, most providers update within 5–60 minutes. Use Google’s DNS tools to verify the record has propagated before testing again.
  7. Verify deliverability with a real inbox test. Send a test email and run it through MailTester’s inbox placement tester. Check if the “DKIM validation” status changes from “unknown” to “passed” and if the email lands in the inbox. This confirms the fix is effective.
DKIM signatures that can’t be verified due to missing or malformed DNS records are frequently flagged as spam by major providers — including Gmail and Outlook — even if content is clean.

Even if your message passes sender authentication, a failed DKIM check can degrade sender reputation. Correcting the error is not optional. Once fixed, monitor your email deliverability over 3–5 days. Use MailTester’s bulk verification tool to scan large lists before sending and catch such issues early.

Why checking the selector is more important than it seems

Even a single character error in your DKIM selector—like typing 's1' instead of '1'—breaks the entire authentication chain. DKIM is exact: case matters, spacing counts, and a mismatch means "a tag unknown." Automated systems won't tell you what’s wrong; they just log failure, degrade your sender reputation, and drop your inbox placement. Catch it early.

The cost of a typo

Let’s say you set up DKIM with a selector named default, but accidentally published deault. The receiving server checks the DNS record at default._domainkey.example.com. It finds nothing because the TXT record is at deault._domainkey.example.com. It logs a failure and treats the message as unverified, even if the signing was otherwise correct. This is a silent, systemic failure no user sees.

DKIM requires exact matches. A missing space, a capital letter where lowercase was expected, or a hyphen used instead of an underscore—all break validation. The result? An "a tag unknown" error. That’s the server’s way of saying, "I don’t know what this tag is, and I can’t verify it." It’s not a typo in the email body. It’s in the infrastructure.

Why automated tools don’t flag this

Most email validation tools test inbox delivery, basic syntax, or disposable domains. They don’t parse DNS records for selector mismatches. You won’t see it in a bounce report unless you’re deep in SMTP logs. Some tools even let you publish a DKIM record in DNS with an incorrect selector and still return “valid” because the record exists—and that’s misleading.

According to RFC 6376, the DKIM signature must match the selector exactly. The domain key name is constructed from the selector, the subdomain, and the domain. Deviations break the lookup path. This is not a configuration nuance—it’s a hard requirement defined in the standard.

Use MailTester’s email checker to validate a single address before sending, or bulk verify your list for technical errors, including failed DNS lookups that could point to selector issues. It runs real SMTP checks and flags common misconfigurations early.

When you’re troubleshooting DKIM failures, start with the selector. Double-check the DNS TXT record. It’s the first and final checkpoint. A typo there isn’t a minor glitch. It’s a full chain break. And it costs your deliverability.

How DNS propagation delays affect DKIM validation

After updating a DKIM TXT record in DNS, global propagation can take up to 48 hours—even though most providers update within minutes. During this window, older records may still be served, causing intermittent DKIM validation failures. Testing during propagation can produce false positives, making it seem like your email setup is broken when it’s actually just catching up to the new configuration.

Propagation delays create false failure signals

DKIM relies on DNS to verify that a signature was issued by an authorized sender. When you update the DNS TXT record for DKIM, not every recursive resolver across the internet will see the change at the same time. Some will still return the old record, leading to failed validation attempts even if the new record is correct.

This inconsistency can make your email appear invalid or untrusted during the propagation window. If you run a test or delivery check during this time, you might wrongly assume the DKIM setup is broken. In reality, you’re seeing transient behavior tied to DNS cache TTLs (time-to-live), which are designed to reduce query load but extend the window of potential inaccuracy.

Why testing during propagation leads to bad decisions

Running automated checks, inbox placement tests, or bulk validations too soon after a DNS update can mislead you into thinking your email infrastructure has a problem. You might reconfigure your sender stack, disable DKIM, or escalate a ticket—only to discover later that the issue was temporary.

According to the IETF’s RFC 1035, DNS records can have varying TTLs, from as low as 30 seconds to several days. Many hosting and email providers default to long TTLs (e.g., 24–48 hours) to minimize resolvers’ load. If your DKIM record’s TTL was set high, this delay can persist well beyond the moment you made the change.

Let’s be clear: you don’t need to wait the full 48 hours to test. But testing immediately after a DNS change increases the risk of a false negative. Wait at least 1–2 hours after propagation begins, and consider using a tool that confirms DNS changes have taken effect across multiple locations. If you're verifying a list, MailTester’s DNS checker can help validate that your DKIM record is live in key regions before proceeding with sends.

When validating DKIM, treat temporary failures during propagation as expected, not as errors. Use tools that account for infrastructure lag—especially if you’re validating domain alignment or testing deliverability at scale.

Real-world example: how a misconfigured selector caused a 35% deliverability drop

When a mid-sized SaaS company saw a sudden 35% drop in inbox placement, their deliverability team traced it to a mismatched DKIM selector. SendGrid had deployed a new DKIM key, but the old DNS record remained active. MailTester’s bulk verification flagged 19% of their domains with 'a tag unknown' errors—indicating DNS couldn’t resolve the selector. Once they updated the DNS record and validated using MailTester’s inbox-placement tester, delivery stabilized within 48 hours.

How the error made its way into production

SendGrid automatically rotates DKIM keys for security, but it doesn’t remove old records. When the new key was rolled out, the old selector—still published in DNS—no longer mapped to a valid key. Email receivers check the DKIM-Signature header and verify it against the DNS record using the selector. If the DNS record is missing or malformed, the validation fails. This is why you see “a tag unknown” in MailTester’s results: the DNS lookup returns no match for that selector.

Diagnosing the root cause with real data

Let’s say you’re seeing a spike in soft bounces, especially from Gmail or Outlook. Check your email headers and look for DKIM validation failures. If you see something like dkim=fail (no key for selector), the issue is likely a misconfigured selector. In this case, the company ran a bulk verification through MailTester’s email list verifier, which surfaced the 19% failure rate. The tool doesn’t just detect syntax issues—it correlates them with real recipient behavior.

Once they cross-referenced the results with email headers and their SendGrid logs, they confirmed the new key used a different selector, but the old DNS entry was still live. Updating the DNS TXT record to point to the correct selector resolved the issue. They retested using MailTester’s inbox placement tester, simulating delivery across major inboxes, and confirmed full recovery.

This isn't an isolated case. According to industry data, improperly configured DKIM records account for a significant portion of email deliverability issues. The DKIM RFC requires that selectors be unique and resolvable—failure to maintain this leads to validation breakdowns. Many senders assume the email service provider handles everything, but DNS misconfiguration remains a top cause of failed DKIM checks.

Best practices to avoid 'a tag unknown' errors in the future

You can prevent 'a tag unknown' errors by using only one DKIM key per domain, logging selector details in your config management system, scanning DNS records regularly with free tools or MailTester’s API, and automating verification in your deployment pipeline. This reduces misconfigurations and catches issues before they reach recipients.

Stick to one DKIM selector per domain

  • Use a single DKIM selector across all your outbound mail for a given domain. Multiple selectors increase the chance of misalignment with receiving servers.
  • More than one active selector can confuse SPF/DKIM validation—some receivers treat mismatched or unused selectors as signs of poor configuration or potential spoofing.
  • For multi-tenant or complex routing setups, evaluate whether the need for multiple selectors is truly required. If yes, ensure each is clearly documented and tied to a known service.

Track and verify DNS records systematically

  • Always document your DKIM selector, key length, and intended use (e.g., "sendgrid-sending-2024") in your configuration management system. This avoids lost or conflicting keys.
  • Use tools like MXToolbox or DNSChecker to verify that your TXT records are correctly published and resolving.
  • Integrate MailTester’s verification API into your CI/CD pipeline to scan for DKIM configuration issues before sending campaigns.
  • Regularly audit your DNS records—DNS changes can slip past review, especially during team turnover or onboarding.

When you automate verification, you're not just checking for typos—you're validating that your entire email stack is in sync. The bulk verification tool helps find invalid addresses before you send, improving sender reputation and reducing bounces.

DKIM validation isn’t just about signing emails—it’s about ensuring every step of the path from your server to a recipient’s inbox remains intact. A known, consistent selector, paired with regular checks, is the simplest way to keep your messages trusted.

How MailTester helps prevent and detect DKIM issues before they break delivery

You can catch DKIM configuration problems—like an a tag unknown error—before they cause bounces or inbox placement failures. MailTester checks DKIM record syntax and DNS reachability in real time, runs inbox placement tests across major providers, and uses AI to interpret and fix header issues, all with 98.9% accuracy and no expiration on credits.

Real-time DNS checks catch DKIM syntax and reachability errors early

When you validate an email address, MailTester doesn’t just check if it exists— it verifies whether the associated DKIM record is correctly published and reachable in DNS. An incorrectly formatted or missing DKIM record can silently break authentication, leading to messages flagged as suspicious. By detecting syntax issues (like malformed key formats) and unreachable records during verification, MailTester stops problems before they reach the inbox.

DKIM works by cryptographically signing emails using a private key tied to a public key published in DNS. If the receiving server can’t retrieve or verify that public key—due to incorrect syntax, TTL mismatches, or DNS propagation delays—it may reject the email or mark it as suspicious. This is where real-time verification becomes critical.

Inbox placement tests simulate real delivery across providers

Even if a DKIM record exists, it might not pass all filters. MailTester's inbox placement test sends your email to real inboxes at Gmail, Outlook, Yahoo, and other providers. It monitors how each system processes the message and reports anomalies like an a tag unknown error—common when a DKIM signature includes a tag that’s unrecognized or misparsed by the receiving server.

These issues often arise from outdated or malformed headers, improper tag ordering, or incorrect key length. By simulating real delivery paths, MailTester surfaces these problems in a testing environment before you send to real users. You can fix the issue and verify the change before your next campaign goes live.

For those still unsure what’s going wrong, MailTester’s in-app AI assistant analyzes the DKIM header and suggests specific DNS corrections. It doesn’t just say “incorrect”— it explains which tag is invalid, where it’s misformatted, and how to resolve it.

With 98.9% accuracy and no expiration on purchased credits, MailTester offers a reliable, long-term verification layer. You’re not paying for a short-term fix—you’re building a foundation that scales.

See how it works: verify your entire list in bulk or test delivery to real inboxes with full insight into DKIM and SPF behavior.

You can't fix it by sending more — remediate with precision, not scale

Fixing broken DKIM isn’t about blasting more mail to overwhelm the system. It’s about identifying and correcting failed checks before they erode sender reputation. Even a single DKIM failure per 100 emails compounds over time, risking blacklisting by filters that prioritize consistent reliability over volume. You don’t remediate scale — you remediate accuracy.

One failed DKIM check matters — even in bulk

DKIM is not a checkbox you can ignore in large campaigns. Every failed signature is a signal to inbox providers that your mail isn’t properly authenticated. Even if only 1% of your sends fail DKIM verification, that’s enough to trigger reputation scoring systems that track consistency. Over time, this leads to filtering, lower inbox placement, and potentially permanent blacklisting with services like Spamhaus or Cloudflare. It’s not about how much you send — it’s about the quality of every single email.

If your email service sends to lists with inconsistent or broken DKIM configurations, you're sending trust signals that degrade your standing with receiving servers. A reputation system doesn't care how many messages you send; it cares whether every one meets the technical standard. This isn’t about sending more — it’s about sending only what passes.

Preemptive verification stops the damage before it starts

Let’s be clear: you can’t fix DKIM after the fact with more delivery attempts. The damage is already done by the time mail hits the inbox. The real solution is stopping invalid or malformed addresses — including those with broken DKIM — before they leave your server.

MailTester’s bulk verification checks every address for structural validity, server reachability, and DNS-level authentication like DKIM, SPF, and DMARC. It catches problems like malformed DKIM signatures, expired or missing keys, or mismatched domains before you send. Use it before your campaign begins to identify and remove flawed addresses, so you never risk reputation erosion in the first place.

For real-time integration, the API checker validates emails as they’re added to your system, preventing bad data from ever entering your database. These tools don’t rely on guesswork — they use actual DNS lookups, SMTP checks, and protocol analysis based on standards like RFC 6376. That’s how you build sender trust — not by sending more, but by sending smarter.

Summary: Fix 'a tag unknown' with DNS, DKIM, and real verification

The 'a tag unknown' error originates in DNS, not the email address itself. It signals a mismatch between the DKIM selector in your email header and the corresponding DNS TXT record.

Check your email headers to confirm the DKIM selector. Then locate the matching DNS TXT record in your domain's configuration. Correct any discrepancy in the selector name or record content to resolve the issue.

After making changes, verify the fix using MailTester. Its real-time inbox testing confirms DKIM alignment across actual mail servers, not just DNS analyzers.

Prevent recurring issues by auditing DKIM configurations regularly. Track selectors and their records to maintain alignment across domains, mailers, and outbound campaigns.

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 does 'a tag unknown' mean in a DKIM error?

It means the receiving server found a DKIM signature but could not locate the matching public key because the selector in the DNS record is missing or incorrect.

Can a valid email address have a 'a tag unknown' error?

Yes. The error is about the signing configuration, not the address. A valid email can fail deliverability if the DKIM record is misconfigured.

How long does it take for a DNS DKIM update to take effect?

Typically 1–10 minutes. In rare cases, propagation can take up to 48 hours. Test after this window.

Does MailTester detect DKIM signature inconsistencies?

Yes. Its API validates the DKIM header and checks for selector alignment in DNS, helping detect 'a tag unknown' before deployment.

Can a typo in the DKIM selector break email delivery?

Yes. Even one character difference — like 's1' vs. '1' — breaks the lookup and results in 'a tag unknown'.

Is DKIM required for email deliverability?

Not mandatory, but most major providers (Gmail, Outlook) use DKIM as a key signal. Without it, deliverability drops sharply.

What’s the difference between SPF and DKIM?

SPF verifies the sender IP; DKIM verifies the message content. Both are part of email authentication, but they serve different roles.

How often should I audit my DKIM records?

At least monthly if sending regularly. After any email service change, test immediately with an inbox-placement tool.

Do DKIM failures affect sender reputation?

Yes. Repeated DKIM failures reduce trust and can lead to filtering or blacklisting.

Can third-party tools like SendGrid or Mailchimp cause 'a tag unknown'?

Yes. When they update their DKIM keys, the old selector must be removed from your DNS to avoid conflicts.

What happens if I ignore 'a tag unknown' errors?

Emails will fail at the receiving end. This harms domain reputation and reduces inbox placement over time.

Does MailTester support bulk DKIM validation?

Yes. Its bulk verification and API allow for checking the DKIM state of thousands of domains or emails at once.