DKIM Selector Lookup How to Find

What Is a DKIM Selector and Why Does It Matter?

You’re troubleshooting a failed DKIM verification and staring at a signature like DKIM-Signature: a=rsa-sha256; s=brisbane2024; d=example.com;. You know the key is in DNS, but your tool says it can’t find the public key. That missing piece? The selector.

The DKIM selector is a unique label tied to your domain’s public key in DNS. It’s what lets receiving servers locate and validate the signature. Without it, even a properly signed email fails authentication.

Knowing how to perform a DKIM selector lookup — and why it matters — is essential for debugging deliverability issues, setting up email systems, and maintaining sender reputation. We’ll walk through the mechanics, how to find a selector, and what to do when it’s missing or misconfigured.

Key takeaways

A DKIM selector is the identifier in DNS that points to a public key used to verify email signatures.
The selector appears in the DKIM-Signature header as part of selector._domainkey.domain, such as brisbane2024._domainkey.example.com.
You can find a selector by checking the DKIM-Signature header in an email and querying DNS for TXT records at the corresponding domainkey subdomain.

How to Find a DKIM Selector Using Public DNS Tools

You can find a DKIM selector by querying the domain’s DNS TXT records using tools like dig or nslookup. The record name follows the format selector._domainkey.yourdomain.com. For example, to check Gmail’s DKIM setup, query gmail._domainkey.google.com. The returned TXT value contains the public key and metadata used by receivers to validate DKIM signatures.

Step-by-Step DKIM Selector Lookup

Open a terminal or command-line interface.
Run dig TXT selector._domainkey.yourdomain.com, replacing selector with the actual selector name and yourdomain.com with the target domain.
If you're unsure of the selector, try common ones like default, google, or mail. Many providers use predictable names.
Look for the full TXT record value in the response. It will start with v=DKIM1; followed by key parameters such as k=rsa, p= (the public key), and others.
Verify the p= value matches the public key expected by the sender’s domain.

Understanding the Returned Data

The TXT record returned during a DKIM selector lookup contains standardized fields. The v=DKIM1 tag confirms the record is DKIM-related. The k=rsa indicates the key type. The p= field holds the actual public key used to verify email integrity. This is critical for receivers to confirm that messages originated from your domain and weren’t tampered with in transit.

The 5 steps described in “Step-by-Step DKIM Selector Lookup”, in order.

For a deeper look at how DKIM works, refer to RFC 6376, which defines the DKIM protocol. This standard also covers how selectors should be structured and validated across the email ecosystem.

Some domains use multiple selectors for key rotation. If you can’t find one selector, try others: default._domainkey.yourdomain.com, selector1._domainkey.yourdomain.com, or mail._domainkey.yourdomain.com.

To automate or verify large-scale setups, you can use MailTester’s real-time verification API to validate email addresses and check domain alignment, including DKIM and SPF compliance. It’s useful when assessing list quality or debugging deliverability issues.

Try the real-time verification API for bulk checks, or use bulk verification to clean your list before sending. The system returns detailed results including DNS-based validations like DKIM and SPF.

What Does a DKIM Selector Look Like in DNS?

You can find a DKIM selector in DNS as a TXT record with a name like selector1._domainkey.example.com, containing fields such as v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC.... The v=DKIM1 identifies the protocol version, k=rsa specifies the encryption method, and the p= field holds the base64-encoded public key used to verify email signatures.

Understanding the Components of a DKIM TXT Record

Let’s break down what each part means. The v=DKIM1 tag confirms this is a DKIM record using version 1 of the protocol, defined in RFC 6376. This is non-negotiable—without the correct version tag, the record won't be recognized.

The k=rsa field tells the receiver that the key uses RSA encryption, the most commonly deployed algorithm for DKIM. While other key types exist (like ECDSA), RSA remains the standard across the industry.

How the Public Key Works in Practice

The p= value is the heart of the record: it’s a base64-encoded public key. When an email is sent with a DKIM signature, the receiving server retrieves this public key from DNS using the selector and checks if the signature matches. If it does, the email is marked as authentic. If not, it may be flagged or rejected.

These records are typically 200–1000 characters long, depending on the key size. A 1024-bit RSA key, for example, produces a base64 string around 136 characters. Larger keys (such as 2048-bit) generate longer strings but provide stronger security.

Many email providers, including Microsoft, Google, and Yahoo, use DKIM to reduce spam and spoofing. A valid DKIM record improves sender reputation and helps avoid inbox filtering. You can test your DKIM setup using tools like MxToolbox or RFC 6376, which define the standard.

If you're verifying email addresses at scale and want to catch invalid or risky domains early—before they harm deliverability—MailTester’s bulk verification can help. You can also use our real-time verification API to check domains on the fly, including DKIM and SPF alignment, reducing bounce rates and protecting sender reputation.

Why Is Finding the DKIM Selector Important for Deliverability?

Missing or misconfigured DKIM selectors break email authentication, causing valid messages to fail validation and land in spam or get rejected. Without a working DKIM selector, your emails lack cryptographic proof of origin, weakening sender reputation and hurting inbox placement. It’s one of the three pillars—alongside SPF and DMARC—that define email trustworthiness.

DKIM, SPF, and DMARC Form a Trust Triangle

DKIM, SPF, and DMARC aren’t standalone tools—they work together to confirm your identity, protect against spoofing, and let email providers assess your sender reputation. SPF checks if the sending IP is authorized; DKIM validates the email content hasn’t been altered; DMARC combines both to enforce policy and report on failures. When any piece is broken—like a missing DKIM selector—the entire chain is suspect.

Let’s say you’re sending from a domain with a misconfigured DKIM record. Even if SPF passes, the absence of a valid DKIM signature means the email lacks a verifiable digital fingerprint. Providers like Gmail and Microsoft Exchange routinely flag such messages as high-risk or outright reject them. This happens even if content is legitimate and your list is clean.

How DKIM Selector Lookup Prevents Deliverability Failures

Running a DKIM selector lookup tells you exactly what key your domain is using for signing. If you’re managing multiple apps or senders, this avoids confusion. Some providers auto-rotate selectors; others use custom ones. Without finding the right one, you can't validate the key, test signing, or diagnose why an email failed.

Using tools like MailTester’s bulk verification gives you full visibility into DKIM alignment across your list. It checks not just email syntax, but also whether SPF, DKIM, and DMARC are properly set. This lets you spot problems before sending—like missing selectors or mismatched records—before they hurt deliverability.

The same applies to real-time verification. When integrating with our API, you can validate not only address validity, but also authentication readiness. If a domain lacks a valid DKIM selector, the API will flag it as risky, saving you from sending to unauthenticated domains.

For deeper insight, test inbox placement directly. MailTester’s inbox tester sends real emails through major providers, showing where your messages land—spam, inbox, or blocked. It reveals whether missing DKIM selectors are already affecting real-world delivery.

For authoritative context, see RFC 6376, which defines DKIM’s role in email authentication. You can review the specification at IETF RFC 6376. It details how DKIM works and why proper selector alignment is non-negotiable.

DKIM Selector Lookup: Common Format Patterns

You can find DKIM selectors by checking a domain’s DNS records for TXT records with names like selector._domainkey.example.com. Common selectors include default, gmail, s1, key2, or dmarc. They’re typically short, descriptive, and case-insensitive in DNS but must match exactly in email headers. Some domains use multiple selectors for different services or key rotations over time.

Common Selector Patterns You’ll See

Use default for domains configured with a single default key — common in legacy setups or small providers.
Look for gmail or google in records from Google Workspace or Gmail sends — these are standardized across Google’s infrastructure.
Short numeric or alphanumeric names like s1, dkim1, or key2 often indicate multiple keys for key rotation or service separation.
Domain-specific selectors like mail or post may align with particular email platforms or senders within a larger organization.
Multi-tenant providers (like SendGrid or AWS SES) may assign unique selectors per domain or subdomain to isolate authentication per client.

Selector Matching: What to Watch For

DKIM selectors are not case-sensitive in DNS, but they must match exactly in the email header — Default and default are not the same when validating an email’s signature.
When troubleshooting deliverability, always cross-check the selector in the email’s DKIM-Signature: header against the DNS TXT record.
Some domains rotate keys over time and use different selectors for old and new keys — this means a single domain can have multiple valid DKIM records.
Domains with multiple senders (e.g. marketing, transactional, customer support) often assign separate selectors to each stream.
Use tools like MXToolbox or RFC 6376 to verify selector placement and syntax.

Let’s say you’re testing an outbound email and see a DKIM failure. The first step? Check the selector in the raw header and query the corresponding DNS record. If you’re verifying large lists or checking sender reputation, use MailTester’s API to validate authenticity and deliverability in bulk.

How MailTester Helps You Find and Verify DKIM Selectors

You can find and verify DKIM selectors using MailTester’s real-time verification API by checking a domain’s DNS records directly. The API queries the DNS for TXT records under the specified selector (e.g., default._domainkey.example.com), confirms DKIM existence, validates its signature format, and checks alignment with the sender domain. You get structured results showing if the selector is active, properly configured, and aligned with SPF and DMARC policies.

Check DKIM Configuration in Real Time

Let’s say you’re troubleshooting why a message failed delivery despite valid SPF. The issue might be a misconfigured DKIM selector. With MailTester’s real-time verification API, you can test any email address and see if the domain’s DKIM record exists and is valid. The API returns clear fields: dkim_valid, selector_found, and dmarc_alignment_status. This tells you instantly whether the selector is missing, incorrectly published, or misaligned with the sender.

Each API call performs a full DNS lookup, including all relevant TXT records for the domain. This includes checking common DKIM selector names like default, mail, or selector1 — the same way email servers do. This level of technical detail avoids false positives you might get from tools that only check syntax or surface-level records.

Verify DKIM at Scale with Bulk Checks

When managing a large list, you need to assess domain health, not just individual addresses. MailTester’s bulk verification process includes DNS lookups for DKIM, SPF, and DMARC records as part of the domain validation step. This means every email in your list is checked not just for format, but for whether the sending domain actually supports valid authentication.

Domains with no DKIM record or mismatched selectors often appear in inbox placement tests as high-risk senders. By catching them early, you avoid sending to domains where delivery failures are statistically likely. This is especially important for marketing and transactional workflows — a single unauthenticated domain can harm your sender reputation.

For deeper insights, use the inbox placement tester to simulate delivery across inboxes. It checks if DKIM and SPF are not just present but also technically valid and aligned, matching industry standards like RFC 6376 for DKIM signing.

Authentication setup isn’t complete until all three — SPF, DKIM, and DMARC — are properly configured and verified. MailTester’s approach gives you the data to prove it. Start with your first 100 free verifications at our pricing page to test real-world email health.

What Happens If a DKIM Selector Doesn’t Exist?

If a DKIM selector doesn’t exist, the receiving server can’t locate the public key needed to verify the email’s digital signature. Without that, DKIM validation fails — even if the message is otherwise valid. This failure can lead to spam filtering, delivery delays, or outright rejection, especially if it happens repeatedly. You might not see immediate bounces, but reputation damage accumulates.

What Goes Wrong When the Selector Is Missing?

The receiving mail server attempts to look up the DKIM public key using the selector specified in the email header, but finds no DNS record for it.
Since the signature cannot be validated, the email fails DKIM checks, which are standard in modern email validation.
Even one failure doesn’t always block delivery, but repeated failures (especially across multiple domains) signal poor sender hygiene.
Receiving servers, including Gmail, Outlook, and Yahoo, correlate DKIM failures with sender reputation. Consistent failure can lead to inbox filtering or quarantine.
DKIM is one of the core signals used by spam engines — a failed check increases the likelihood your message is classified as spam.
If your domain has DMARC set to "reject" or "quarantine", a DKIM failure can result in a hard bounce, especially if SPF also fails.

How to Catch This Early

Before you send bulk campaigns or build new email systems, verify that your DKIM setup is correct. A missing selector often means a typo in the header, a misconfigured DNS record, or a forgotten update when changing email services.

Use tools that check your email metadata for issues. The MailTester Inbox Placement Test can simulate how your messages behave across major mail providers, highlighting DKIM and DMARC failures before you send.

For ongoing email list health, use bulk verification to find invalid or malformed addresses, including those that fail to validate DKIM even if the domain seems correct. Our API lets you automate this step at scale.

DKIM is not optional for serious senders. According to the RFC 6376, DKIM is designed to be a fundamental part of email authentication. Skipping it, or misconfiguring it, leaves your messages vulnerable to rejection.

Let’s be clear: even a single failing DKIM check doesn't destroy your reputation — but repeated issues do. The key is catching them before they accumulate.

Best Practices for Managing DKIM Selectors

You can find your DKIM selector by checking your domain’s DNS records for a TXT record prefixed with the selector name (e.g., default._domainkey.example.com). Use a tool like MailTester’s DNS verification or MxToolbox to confirm it’s properly published. Always validate the full DKIM setup, including DNS propagation and alignment with your sending infrastructure.

Consistency and Rotation

Use a consistent naming convention across all your DKIM selectors—like mail, sendgrid, or newsletter. This makes it easier to track which system signs which messages.
Rotate your DKIM keys every 90 to 180 days. But keep the old key active for at least 30 days after deprecation to avoid breakage in delayed delivery or legacy systems.
Monitor your email logs to confirm no messages are still signed with old keys before removing them. This step prevents unexpected fails in authentication.

Verification and Validation

After adding or updating a DKIM record, use a DNS lookup tool like MxToolbox or MailTester’s DNS checker to confirm the record is visible and correctly formatted.
Validate the full signing chain: ensure the selector matches the published TXT record, and the public key is properly formatted and matches the private key used in your mail server.
Use MailTester’s inbox placement test to simulate real-world delivery and check whether messages with your DKIM signature are accepted by major providers.

DNS propagation delays can last up to 72 hours. Always check your records across multiple global DNS resolvers to confirm they’re live before assuming they’re active. As per RFC 6376, DKIM relies on consistent, predictable DNS publication—any deviation can trigger filtering or rejection.

DKIM vs. SPF vs. DMARC: The Relationship Between Them

SPF, DKIM, and DMARC work together to verify email sender authenticity. SPF checks if the sending server’s IP is authorized; DKIM cryptographically signs the email to ensure content hasn’t been altered; DMARC uses both results to decide what to do with emails that fail either check—like rejecting them or quarantining them. Together, they stop spoofing and improve inbox placement.

SPF: The Sender’s Address Check

SPF (Sender Policy Framework) verifies that the email came from an IP address authorized to send on behalf of the domain. It’s like checking the return address against a list of approved mail servers. If the IP isn’t on that list, the email fails SPF. This prevents unauthorized servers from impersonating your domain.

While SPF protects against forged sender addresses, it only checks the envelope From field and doesn’t cover the visible "From" in the email body. It’s also limited to one SPF record per domain, and complex configurations can trigger failures. A well-configured SPF record is essential, but not sufficient on its own.

DKIM: The Email’s Digital Signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email. This signature is verified using a public key published in your domain’s DNS records. Let’s say you send an email—DKIM signs it, and the receiving server checks that signature against your DNS key. If it doesn’t match, the email was tampered with.

Unlike SPF, DKIM works regardless of the sending IP. It proves the message content is unchanged from the time it left your server. If you’re using a mailing service, they’ll manage DKIM keys—but you still need to publish them correctly. For more insight, RFC 6376 outlines the full specification here.

DMARC: The Enforcement Layer

DMARC (Domain-based Message Authentication Reporting & Conformance) is your policy engine. It tells receiving servers what to do if an email fails SPF or DKIM. You can choose to monitor, quarantine, or reject failing messages. DMARC also collects feedback from receivers, giving you visibility into how your authentication is working across the internet.

It’s not a standard—yet. But it’s now standard practice. According to data from the M3AAWG, 90% of major email providers now enforce DMARC policies for authenticated domains. Without DMARC, even correct SPF and DKIM checks don’t stop phishing. And with DMARC, you gain control and insights.

Use tools like MailTester’s bulk verification to check for valid, deliverable addresses—and ensure your authentication setup (SPF, DKIM, DMARC) aligns with your sending practices. For real-time checks, integrate with the MailTester API or test inbox placement with the in-box tester.

How to Confirm DKIM Alignment with Your Domain

You can confirm DKIM alignment by verifying that the domain in the From header matches the d= parameter in the DKIM-Signature, and that the selector in the signature corresponds to an existing DNS TXT record. Use tools like MailTester’s inbox-placement tests to validate real-world deliverability and catch alignment issues before they impact your reputation. This alignment is required for email authentication to pass in modern inbox filters.

Check the From header and DKIM-Signature domain match Open the raw email headers and look for the d= value in the DKIM-Signature header. Ensure this domain matches the domain in the From address. If they don’t match, the email fails DKIM alignment — a common reason for inbox filtering.
Verify the DKIM selector exists in DNS The selector in the DKIM-Signature (the part before the @ in the s= field) must resolve to a valid TXT record at selector._domainkey.yourdomain.com. Use a DNS query tool like MxToolbox to inspect the record. A missing or malformed record means the signature cannot be verified.
Confirm the public key in the TXT record is correct The value in the TXT record should start with v=DKIM1; followed by p= and the public key. If the key is truncated, malformed, or missing, the signature fails validation. Double-check it against your email service’s published key.
Test deliverability in real inboxes A correct configuration doesn’t guarantee inbox placement. Use MailTester’s inbox-placement testing to send test emails to major inboxes (Gmail, Outlook, Yahoo) and see how your DKIM alignment performs under real conditions.

Why alignment matters beyond technical correctness

Even if DKIM signs correctly, misalignment (e.g., From: example.com but d=mail.example.org) leads to authentication failure in most modern email systems. This is not just a technical detail — it’s a key factor in inbox placement. According to the DKIM specification (RFC 6376), alignment ensures the signing domain matches the display domain, preventing spoofing.

Use real-world testing to catch hidden issues

Many organizations assume DNS records are sufficient. But issues like temporary greylisting, overly aggressive spam filters, or sender reputation quirks can block emails even with correct DKIM. MailTester’s inbox-place testing simulates real delivery paths and gives you a practical result, not just a syntax check.

DKIM alignment isn’t optional. It’s required for authentication to count in today’s inboxing algorithms.

After verifying the signature, use MailTester’s real-time verification API to audit large lists, ensuring your sending domains align across every recipient. You can also connect directly to Mailchimp, HubSpot, Klaviyo, or SendGrid for ongoing validation. For new campaigns, start with a free test at MailTester’s pricing page. You’ll get a full report on alignment, deliverability risk, and domain health.

The Bottom Line: Accurate DKIM Lookup Is Part of a Healthy Sender Reputation

A missing or malformed DKIM selector breaks the chain of trust. Even one misconfigured domain can trigger filtering systems and reduce inbox placement across major providers.

Proactive DNS checks aren’t optional. They’re a foundational part of sender reputation management. Tools that validate DKIM, SPF, and DMARC configurations help catch issues before they impact deliverability.

MailTester’s 98.9% accuracy in verification helps identify configuration flaws—like incorrect DKIM selectors—before they hurt your sender reputation. Real-time checks and bulk validation keep your list clean and your emails trusted.

Sources

The number of top domains at DMARC enforcement grew from 233,249 in 2023 to 411,935 in 2026 — a 77% increase driven largely by mailbox-provider sender mandates. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
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)

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?

A DKIM selector is a unique name used to locate the public key in DNS for verifying email signatures. It appears in the DKIM-Signature header and in the DNS TXT record as selector._domainkey.domain.com.

How do I find my DKIM selector?

Use DNS tools like dig or nslookup to query TXT records under selector._domainkey.yourdomain.com. The selector name is typically visible in the email header or provider settings.

Can DKIM selectors be changed?

Yes, but only when rotating keys. Old selectors must remain active until all signed messages have been processed to avoid failures.

Why is my DKIM lookup failing?

Possible causes include a typo in the selector name, a missing DNS record, or misaligned domains in the From header and DKIM d= tag.

Does every domain need a DKIM selector?

Only if you send authenticated email. DKIM is required for strong deliverability and sender reputation when sending at scale.

What does the _domainkey part mean in DKIM?

It’s a standard DNS convention used to group all DKIM-related records. The full record name is selector._domainkey.example.com.

Can a domain have more than one DKIM selector?

Yes. Multiple selectors can coexist to support different services, time-based key rotation, or fallback mechanisms.

How do I test if my DKIM selector is working?

Use MailTester’s real-time API or inbox placement tools to verify signature validation, DNS records, and alignment with the From header.

What happens if the DKIM selector is incorrect?

Emails fail DKIM validation, which harms sender reputation. Receiving servers may reject messages or mark them as spam.

Is DKIM necessary if I use SPF and DMARC?

Yes. SPF alone does not verify message content. DKIM ensures content integrity. All three are required for full email authentication and high inbox placement.

Can I look up a DKIM selector for any domain?

Yes — if the domain publishes a DKIM record in DNS. Use tools like dig or MailTester’s API to query public records.

How does MailTester help with DKIM verification?

It checks DNS records for valid DKIM selectors, validates signatures, and provides real-time insights into deliverability health during testing.