Test DKIM Selector Name in DNS

Why is testing your DKIM selector name in DNS critical for email deliverability?

You send an email that looks perfect. The content is clean, the domain is verified, the SPF record is set. But it lands in the spam folder—or worse, fails outright. Why? One overlooked detail: the DKIM selector name.

Even a single typo in the selector (like mail instead of default) breaks the signature validation. Major providers like Gmail and Microsoft reject mail with invalid DKIM, often resulting in hard bounces or spam filtering. This happens even if everything else—your key, domain, and DKIM policy—is correct.

Testing your DKIM selector name in DNS before sending ensures that the public key resolves as expected. It’s not a luxury. It’s a must-have step in avoiding delivery failures.

Key takeaways

A single character error in your DKIM selector name can cause emails to fail validation and be rejected by major providers.
DKIM validation relies on correct DNS record resolution—testing the selector before sending prevents delivery failures due to misconfiguration.
Even if your domain and key are valid, an incorrect selector breaks authentication and harms sender reputation.

What exactly is a DKIM selector, and why does it matter?

The DKIM selector is the unique identifier in a DKIM DNS record that tells receiving mail servers which public key to use for validation. It’s part of the TXT record name—like mail._domainkey.yourdomain.com—where "mail" is the selector. If the selector in the email header doesn’t match the one in DNS, the DKIM signature fails, and your message may be rejected or marked as spam.

The Selector Lives in DNS, But Rules Email Verification

When you set up DKIM, you pick a selector—commonly something like mail, default, or key1. This name defines the subdomain used in your DNS TXT record. Receiving servers use it to look up the public key required to verify the signature on incoming mail. A mismatch between the selector in the email header and the DNS record is a common reason for DKIM failures, even if everything else in the setup is correct.

Because DKIM is a foundational part of email authentication, even a typo in the selector name breaks the verification chain. For example, if your email header shows selector=mail but your DNS record is named mail2._domainkey.yourdomain.com, validation will fail. This isn’t just technical detail—it’s what keeps your messages out of spam folders or blocked outright.

How to Test Your DKIM Selector Name Without Guessing

Manually checking DNS records is error-prone. You’re better off using a tool that verifies the full chain—from the header to DNS. The MailTester inbox placement tool gives you a realistic view of how your authenticated messages land in real inboxes, including DKIM validation status.

If you're setting up DKIM or auditing existing setups, the best practice is to ensure the selector name in your headers precisely matches the one in DNS. You can test this by sending a message through a trusted service and checking the full header and DNS record via tools like MXToolbox or by examining raw email source. For developers and admins, RFC 6376 (the standard for DKIM) clearly defines the structure and expected behavior of selectors and their use in verification.

How does the DKIM selector interact with email sending and authentication?

When you send an email, your server uses a private key tied to a DKIM selector to sign the message. The receiving server checks that signature by looking up the selector in DNS to find the public key. If the selector is wrong, missing, or malformed, the signature fails—even if SPF and DMARC are perfectly configured. This failure means your email may be marked as unauthenticated or rejected, even if everything else is correct.

How the selector ensures signature validity

Every DKIM signature includes a selector—essentially a name that tells the receiving server which public key to fetch from your domain’s DNS records. Let’s say your selector is mailgun. The receiving server will query mailgun._domainkey.yourdomain.com to retrieve the public key. If the record doesn’t exist, is misformatted, or doesn’t match the signing key, verification fails. This is a common source of delivery problems, especially after changing email providers or configuring new sending systems.

Why DNS lookup is the critical step

DKIM authentication doesn’t happen in isolation. It depends entirely on DNS being set up correctly. If your DNS provider has a propagation delay, or if you’re using a caching resolver that hasn’t updated, the public key might not be available when checked. This causes transient validation failures, even if your email and signing keys are correct. The same applies if you’ve changed your selector but forgotten to update the DNS record.

Many major email receivers—like Gmail, Yahoo, and Microsoft—rely on DKIM validation as part of their spam and phishing filters. A failed DKIM check can hurt your sender reputation, even if SPF and DMARC pass. This is why testing your selector before sending mail is essential. Tools like MailTester’s email checker can validate the full stack—including DNS alignment—for any address in real time.

For teams managing larger campaigns, regular verification helps catch errors early. You can test your domain’s DKIM setup across multiple email clients and inboxes using MailTester’s inbox placement test to simulate delivery conditions. The full DKIM chain—from signing key to DNS record—must be valid for your messages to reach the inbox.

Common causes of DKIM selector name validation errors

You’re getting DKIM validation failures not because your signing is broken, but because the selector name in your DNS record doesn’t match what your email client or server is actually using. A single typo, a missing DNS record, or an outdated configuration can break the chain. Let’s walk through the most common, often overlooked missteps.

Incorrect or missing selector in DNS

Typing the selector name wrong (e.g., maill instead of mail) breaks validation—DNS is case-sensitive and exact. Double-check the spelling every time you configure it.
If the selector isn’t published in DNS at all, receivers can’t retrieve the public key. Use tools like MxToolbox or RFC 6376 to verify the TXT record exists.
Don’t assume the DNS record is correct just because you entered it. Verify with a dig or nslookup command: dig TXT selector._domainkey.yourdomain.com — the output must match your signed DKIM header.

Misconfigured signing setup

Using multiple selectors without updating the email signing engine means outdated or unused keys are referenced. Only one selector should be active at a time unless you’re actively transitioning.
Changing the selector name in DNS but forgetting to update the signing server or client means the email content uses an old selector that isn’t published. This breaks validation even if everything else is correct.
Some systems auto-generate selectors like 202410 or default—if you’ve changed them, ensure your sending tool references the exact same name. Even a trailing space can fail validation.

Let’s say you’re sending from a third-party platform like SendGrid or HubSpot. If they’re generating DKIM headers with mail but your DNS points to mail2, validation fails. It's not the tool’s fault—it’s a mismatch. Fix it by checking both ends: the header and the DNS record.

You can audit these issues efficiently with a real-time email verification service that checks headers and DNS simultaneously. Test your DKIM setup before sending to real users. Try inbox placement testing to see how your messages land across providers, including Gmail and Outlook.

How to test your DKIM selector name in DNS using MailTester

You can test your DKIM selector name in DNS instantly using MailTester’s DNS verification tool. Just enter your domain and full selector (like mail for mail._domainkey.example.com) to validate that the DNS record exists, returns a correct public key, and follows proper syntax. Any mismatch or malformed record is flagged immediately, helping you avoid email authentication failures before they impact deliverability.

Step-by-step: Validate your DKIM selector in DNS

Go to MailTester’s DNS verification tool via the web app or API. This tool is designed to check real DNS records in seconds, not simulate them. It’s the fastest way to confirm your DKIM setup aligns with standards and your email provider’s requirements.
Enter your domain and full DKIM selector. For example, if your selector is mail, you’re testing mail._domainkey.example.com. Accuracy here matters—wrong selectors fail validation even if the record exists.
MailTester performs a real DNS lookup. It checks for the TXT record at the correct subdomain and validates that it contains a properly formatted public key, including correct syntax and alignment with RFC 6376. Misplaced quotes, extra characters, or broken base64 encoding are caught automatically.
Review the immediate result. You get a clear “Valid” status or a breakdown of specific issues—missing record, malformed key, incorrect selector name, or syntax errors. No guesswork.
Fix and retest. Use the feedback to correct your DNS entry in your hosting or email provider’s console. Re-run the test to confirm the fix before sending emails at scale. This prevents bounces and inbox filtering.

Why DNS validation matters for DKIM

DKIM relies on a valid DNS record to authenticate email sources. If the selector is wrong or the public key is malformed, receivers flag your message as untrusted. According to RFC 6376, DKIM verification requires exact matching of selector and domain. The first DNS record lookup failure means authentication fails—even if your email content is clean.

The 5 steps described in “Step-by-step: Validate your DKIM selector in DNS”, in order.

Use MailTester’s verification tool to catch these issues before they reach recipients. Whether you're configuring a new domain, migrating services, or auditing existing setups, it’s a fast, accurate check. For bulk testing or integration into your workflow, access the real-time verification API or bulk verification feature. No guesswork. Just confirmation.

What should you see in a valid DKIM selector DNS record?

You should see a TXT record at the selector subdomain (like mail._domainkey.example.com) containing the tags v=DKIM1, k=rsa, and p= followed by a full, properly formatted RSA public key in base64. The v tag must be exactly DKIM1—no other version is supported. The k tag must be rsa, indicating the key type. Any deviation will cause DKIM validation to fail. A malformed or missing p tag is a common cause of email authentication failures.

Check the required tags in your DKIM DNS record

Let’s walk through what each required tag does. The v=DKIM1 tag identifies the record as a DKIM signature and ensures compatibility with email clients and receiving servers. While other versions exist, only DKIM1 is universally accepted. If you see v=DKIM0 or a custom value, your record is invalid. You can confirm this behavior in RFC 6376, section 3, which defines DKIM’s syntax and requirements.

The k=rsa tag specifies that the public key is in RSA format. While other key types exist, RSA is the only one in widespread use today. If the k tag is missing or set to a non-standard value, the receiving server will reject the signature, even if the key is correct. This is a hard validation rule, not just a recommendation.

Verify the public key format and completeness

The p= tag must contain the full public key, starting with the MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC header and continuing in PEM format. It should include the entire key block without line breaks or truncation. If the key is cut off or formatted incorrectly (e.g., with spaces where they don’t belong or missing the final ==), DKIM will fail silently.

Even small errors—like an extra space, a missing =, or a wrong tag order—can break validation. You can test your record with tools like MXToolbox or dig queries to ensure it resolves correctly. If you’re using an email service provider, make sure your DKIM settings are correctly deployed to DNS. For a full pre-send validation, run your list through bulk email verification, which checks for DNS-level issues—including DKIM, SPF, and MX problems—before you send.

Can you test multiple DKIM selectors at once?

You can test multiple DKIM selectors across different domains or DNS records simultaneously using MailTester’s real-time verification API. This lets you validate all your email streams in one go, whether you’re managing hundreds of domains or multiple services with unique selectors, reducing manual effort and catching issues before they hit deliverability.

Bulk validation for complex email ecosystems

Large organizations often run separate email streams—transactional, marketing, support—each using a different DKIM selector. Manually checking each one in DNS is time-consuming and error-prone. With MailTester, you can automate the process using the API to verify multiple selectors in a single request, across multiple domains, ensuring each alignment is correct before sending.

Let’s say you run a SaaS with email streams from marketing@, support@, and no-reply@, each signing with a different selector. Testing them individually slows down your workflow. Using the API, you can send a batch of validation requests and get back precise results—valid, invalid, or misconfigured—without waiting on DNS lookups one by one.

This capability is especially useful during setup, after a change to your email infrastructure, or when auditing deliverability health. It’s aligned with industry standards: RFC 6376 (which defines DKIM) requires selectors to be resolvable in DNS, and any misconfiguration can result in failed validation and rejected messages.

Why it matters for deliverability

DKIM validation failure is a common reason for emails landing in spam or being rejected. Even a minor error—like a missing TXT record, incorrect selector name, or mismatched key—can break the chain. Testing multiple selectors at once helps you identify configuration drift across systems, especially when different teams manage different domains or services.

Many email providers, including Gmail and Outlook, rely on DKIM as a core part of their spam filtering. Validating the entire set of selectors ensures consistency across your outbound traffic. Tools like MxToolbox can check single records, but only MailTester’s API enables true bulk, real-time validation across multiple domains and selectors.

Use the real-time verification API to integrate DKIM selector validation into your deployment or audit workflow. If you're checking email addresses before sending, the email checker also verifies sender infrastructure readiness as part of delivery readiness. For large-scale campaigns, the bulk verification tool supports validating entire sender lists with DKIM validation included.

How does MailTester compare to other DNS validation tools?

Unlike basic tools like MxToolbox or DNSimple, MailTester doesn’t just check if a DKIM record exists—it verifies whether the key is correctly formatted, matches the selector in your email headers, and will actually work in production. While other tools may report “record found,” MailTester digs deeper, catching syntax errors, mismatched selectors, and invalid key structures that would break authentication.

What most DNS tools miss

Many public DNS checkers treat a record as valid simply because it’s present in the zone. But a record can be technically “there” and still be unusable—missing required fields, malformed base64 encoding, or referencing a selector that doesn’t match the one used in your sending system. This is a common source of DKIM failures, even when everything looks correct at first glance.

MailTester validates the full lifecycle of DKIM: it checks the DNS record’s syntax, ensures the selector aligns with your sending setup, and confirms the key can be parsed and verified by receiving mail servers. This goes beyond basic DNS lookup and simulates real-world validation behavior. For example, it can detect when a selector is misnamed (e.g., dkim1 vs. dkim._domainkey) or when the public key includes extra characters that break parsing.

Why this matters for delivery

Mail servers don’t accept just any DKIM record—they verify the cryptographic signature during delivery. If the key is invalid or misaligned, the message may be rejected or marked as suspicious, especially by ISPs with strict enforcement like Gmail or Outlook. A misconfigured selector or malformed key leads to validation errors, even if the record appears in DNS.

According to RFC 6376 (the standard for DKIM), the public key must be structured correctly and accessible under the defined selector. MailTester’s approach aligns with this standard, ensuring compatibility with all major mail providers. For deeper checks, you can test email deliverability using our inbox placement tests, where real messages are sent to inboxes across major platforms to confirm DKIM is working end-to-end.

Other tools may let you check DNS records, but few integrate the full picture—domain policy, sending reputation, and delivery outcome. With MailTester, you don’t just validate syntax, you verify whether a DKIM setup will succeed in the real world. This is crucial for maintaining sender reputation and avoiding hard bounces or spam filtration.

What happens if your DKIM selector is valid but your emails still fail verification?

If your DKIM selector appears correct in DNS but emails still fail validation, the issue likely lies in mismatched configuration, incorrect key usage, or misalignment between the signing process and the published DNS record. The selector must match exactly—case-sensitive and with no extra spaces—across the header, the signing server, and the DNS record. Even small deviations break verification.

Double-check the full chain of DKIM configuration

Verify the Selector in the DKIM-Signature header (e.g., d=example.com; s=2023) matches the DNS record name 2023._domainkey.example.com exactly, including case and spacing.
Confirm the signing server or ESP is using the correct selector and key during message generation—some systems default to a generic or outdated one.
Ensure your email service provider (ESPs) like SendGrid, Klaviyo, or Mailgun are configured to reference the right selector in their DKIM settings, not a fallback or placeholder key.
Test the full delivery path: send a message through your system and check if the DKIM-Signature header correctly reflects the selector and domain in use.

Validate inbox placement and real-world delivery

Even with a technically valid selector and key, emails might still be blocked due to reputation, content, or infrastructure issues. Let's move beyond DNS checks to real-world testing.

Use MailTester’s inbox placement testing to see how your emails land across major providers like Gmail, Outlook, and Yahoo—even if DNS checks pass, these services apply additional filters.
Inspect actual delivery reports: some hosts reject messages silently (hard bounces) or mark them as spam, even with valid DKIM.
Check if the signing key is expired or revoked—publishing the same selector with a new key is fine, but using an expired key will cause failures.
Review the DMARC policy on the domain: if your domain enforces DMARC with reject or quarantine, failed DKIM checks will result in delivery loss regardless of DNS accuracy.

DKIM validation is not just about DNS records—it’s about consistency across the entire email delivery chain. The DKIM standard defines the signing process, but real-world delivery depends on alignment between server configuration, email client behavior, and recipient policies.

To catch misconfigurations early and avoid sender reputation damage, test your full email flow across multiple inboxes. Use MailTester’s inbox placement test to validate real-world delivery success before sending to large lists.

How to prevent DKIM selector errors in the future?

You can avoid DKIM selector mistakes by using standard names like 'mail' or 'default' across your email services, keeping a documented registry of every selector and its purpose, validating DNS records automatically during deployment—especially using tools like MailTester’s API—and auditing configurations quarterly to catch drift or unintended changes. These steps stop errors before they reach your inbox.

Standardize and document selector usage

Use consistent DKIM selector names—prefer 'mail' or 'default'—across all sending systems, including marketing, transactional, and internal tools. This reduces confusion during troubleshooting and ensures predictable DNS lookup behavior.
Keep a living document listing every selector in use, paired with the signing domain, sending service, and team responsible. Tools like RFC 6376 define DKIM syntax, but operational consistency is what prevents real-world failures.

Automate validation and schedule audits

Integrate MailTester’s verification API into your CI/CD pipeline to check DKIM DNS records before deployment. This catches misconfigurations early, especially when rotating keys or updating domains.
Run quarterly audits of all DKIM records to spot drift—such as unused selectors, duplicate entries, or outdated key pairs. A simple DNS lookup script or a tool like MxToolbox can help verify records are correctly published.
When testing new configurations, use MailTester’s inbox placement tester to simulate real-world delivery. This reveals whether a selector is correctly validated by receiving mail servers.

DKIM is only effective if it’s properly published and verified. A misnamed selector or a forgotten revision can trigger validation failures even when the key is correct. By making validation part of your workflow and tracking every change, you reduce the risk of silent delivery breakdowns.

Final thoughts: A properly tested DKIM selector ensures inbox delivery

DKIM is one layer of authentication — but a failed one can sink your deliverability. A single misconfigured selector in DNS can trigger rejection or spam filtering, even if all other signals are clean.

Testing the selector in DNS isn’t optional. It’s a required step before sending emails at scale. Skipping it leaves you exposed to errors that only appear under real-world sending conditions.

MailTester provides fast, accurate validation with up to 98.9% precision, helping you avoid errors before they hit the inbox.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)

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 a DKIM selector name?

A DKIM selector is a label in your domain’s DNS used to locate the public key for email signing. It appears in TXT record names like mail._domainkey.example.com.

Can the DKIM selector be anything?

It can be any string, but it should be consistent across systems. Use clear names like 'mail' or 'default' to avoid confusion.

What happens if the DKIM selector name is wrong?

The receiving server won’t find the public key, and the DKIM signature will fail. This often results in email rejection or placement in spam.

How do I find my DKIM selector name?

Check the DKIM-Signature header in a received email or your email provider's configuration. It's the part before the '@' in the selector subdomain.

Does MailTester check DKIM key content?

Yes. It validates the full record syntax, including the 'v', 'k', and 'p' tags, and confirms that the base64 public key is correctly formatted.

Can MailTester test multiple domains at once?

Yes — use the bulk verification API to test DKIM selectors across multiple domains or selectors in a single request.

Is DKIM testing required for all email sends?

Yes, especially in high-volume or transactional email. Failed DKIM verification often leads to delivery failure, regardless of other settings.

How often should I test my DKIM selector?

Test after any configuration change. Perform quarterly audits to ensure no selector drift has occurred across your email infrastructure.

Can I test DKIM from a mobile device?

Yes — MailTester is accessible via any browser on any device, including mobile, with full DNS validation features.

Does MailTester show detailed error messages?

Yes — it returns specific feedback like 'missing v=DKIM1 tag' or 'invalid base64 key' to help fix the issue immediately.

Can I automate DKIM selector testing?

Yes — use MailTester’s real-time API to integrate DNS checks into CI/CD pipelines or post-deployment validation workflows.

How accurate is MailTester’s DKIM DNS validation?

MailTester achieves 98.9% accuracy in identifying valid and invalid DKIM selector configurations in DNS.