DIY DKIM Record Validation Using DNS TXT Query and Command Line

Why DKIM Validation Matters for Email Deliverability

You send an email. It lands in the spam folder. Or worse, it never arrives. You check your setup—SPF looks good, DNS is correct. But something’s still off.

One silent culprit: a broken or missing DKIM record. Without it, your email’s integrity is unproven. Even if the content is clean, receivers trust nothing without cryptographic proof.

DKIM isn’t a feature. It’s a trust signal. A digital signature baked into your email headers, verified via DNS. If the signature doesn’t match the record, the receiver treats your email like it’s forged or altered. Manual validation using a DNS TXT query is the only way to be sure.

Key takeaways

• DKIM ensures your emails haven’t been tampered with in transit by cryptographically signing them.
• Misconfigured or missing DKIM records directly harm deliverability—most major ISPs reject or flag unverified emails.
• You can validate DKIM records in real time using standard command-line DNS tools like dig or nslookup.

What Is a DKIM Record and How Does It Work?

You publish a DKIM record as a DNS TXT record on your sending domain. It holds a public key that email receivers use to verify the digital signature attached to your outgoing messages. If the signature doesn’t match the key, the receiving server sees the email as potentially forged and may reject it or flag it as spam.

How DKIM Fits Into Email Authentication

DKIM isn’t standalone—it’s one layer in a chain that includes SPF and DMARC. When you send an email, your server signs it using a private key. The public key, stored in your domain’s DNS, lets receivers confirm the message hasn’t been altered in transit.

Receiving servers fetch your DKIM record from DNS and use it to validate the signature. If the math doesn’t add up, the email fails verification. This helps prevent spoofing and phishing, especially for domains with high-profile targets.

Why It Matters for Deliverability

Most major email providers (Gmail, Outlook, Yahoo) require DKIM as part of their anti-abuse checks. Without it, your messages are more likely to land in spam or be blocked entirely.

Even if your SPF record is correct, a missing or improperly configured DKIM record can still break delivery. It’s not just about compliance—it’s about trust. A valid DKIM signature tells receivers, “This message came from us, and it hasn’t been tampered with.”

For more on how to validate your own DKIM setup, you can test your domain’s configuration with tools that query DNS directly. The process isn’t complex, but accuracy matters—especially if you're managing email infrastructure without a dedicated team.

If you’re validating multiple domains or building an email verification workflow, you’ll want a solution that checks not just syntax, but also deliverability signals. MailTester’s bulk verification helps identify invalid, risky, or catch-all addresses before they hurt your sender reputation.

For deeper insight into how email authentication works, the IETF’s official specification is a reliable source: RFC 6376 outlines DKIM’s technical framework. You can also explore real-world email behavior in industry reports from trusted organizations like Return Path (formerly Validity), which tracks trends in email deliverability and abuse patterns.

How to Validate Your DKIM Record Manually with Command Line Tools

You can validate your DKIM record using the dig command in your terminal. Run dig TXT selector._domainkey.yourdomain.com to fetch the DNS TXT record. The response should include a public key formatted as v=DKIM1; k=rsa; p=-----BEGIN PUBLIC KEY-----.... If it doesn't, your DKIM setup is incomplete or misconfigured. This check is essential for ensuring your emails are authenticated and trusted by receivers.

Step-by-Step Validation Process

1. Open your terminal or command-line interface. Make sure dig is installed, which it is by default on most Linux and macOS systems. On Windows, use WSL or install DNS tools via PowerShell or a package manager.
2. Replace selector with your actual DKIM selector (often default or mail) and yourdomain.com with your real domain. For example: dig TXT default._domainkey.example.com.
3. Execute the command. The output will include a TXT record. Look for a value starting with v=DKIM1; k=rsa; followed by a long base64-encoded public key.
4. Verify the key format. It must include -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----. If these are missing, your record is invalid or truncated.
5. Check for syntax errors. The record should not contain extra spaces, line breaks within the p= value, or invalid characters. If you see these, your DNS record needs correction.

Why This Matters for Deliverability

DKIM failure is a common reason emails land in spam folders. According to industry data, over 50% of bulk email failures originate from authentication issues like missing or malformed DKIM records. Validating the DNS record manually gives you certainty before sending to large lists.

To catch issues early, use a real-time email checker before sending. For example, MailTester’s single address validation can confirm if a recipient’s domain supports DKIM and if the record is accessible.

For larger mailings, use the bulk verification tool to test your entire list for deliverability risks—including missing or invalid DKIM entries—before launch. It checks the full chain of DNS-level auth: SPF, DKIM, and DMARC.

Understanding DKIM Record Syntax and Key Structure

You can validate a DKIM record by checking its DNS TXT entry using a command-line tool like dig or nslookup. The record must start with v=DKIM1 to indicate the version, specify k=rsa for RSA encryption, and contain a p= field with a properly formatted, base64-encoded public key. If the key is missing, malformed, or improperly encoded, validation will fail regardless of other settings.

The Version and Key Type

Every DKIM record starts with v=DKIM1. This signals that the record follows the DKIM specification defined in RFC 6376. While newer versions are unlikely to be used, this header is non-negotiable — any missing or incorrect version tag will cause the record to be ignored by receiving mail servers.

The k=rsa field specifies that the key is an RSA public key, which is the most widely supported key type. You’ll see this in nearly all real-world DKIM setups. If the key type is missing or set to an unsupported value like k=ed25519 (which is valid but less common), some older systems may fail to validate it properly. The DKIM specification outlines all acceptable parameters and their meanings.

Decoding the Public Key

The p= field holds the base64-encoded version of the public key, wrapped in -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- delimiters. It must be exactly as generated — no truncation, no extra characters, no line breaks within the encoded string. The key is used by receiving servers to verify the cryptographic signature in the email header.

If the key is malformed — if it’s missing the headers, has incorrect padding, or contains invalid base64 characters — DNS lookup may succeed, but the validation will fail. Even a single incorrect character can break the signature verification process. You can use tools like SSL Shopper's key checker to validate the key format, though it's not specific to DKIM.

Let’s say you’re diagnosing a bounce from a large mailing: if your DKIM record passes DNS lookup, but deliverability is poor, the issue could lie in the key structure. Tools like the MailTester email checker can test whether an address is valid and whether your domain’s DNS records are sound — not just for DKIM, but for SPF, MX, and more — giving you a full picture before sending.

Common DKIM Validation Failures and Root Causes

You’ll hit DKIM validation failures when the DNS TXT record is missing or expired, the selector in the email header doesn’t match the one in DNS, the public key format is broken (like invalid base64 or embedded line breaks), or the domain in the DKIM-Signature header doesn’t align with the From: domain. These are common misconfigurations that break email authentication and hurt deliverability. Let’s walk through the details so you can fix them.

Missing or Expired DNS TXT Record

• Check your DNS zone file: a missing DKIM TXT record means the domain never publishes the public key. Use dig TXT selector._domainkey.example.com to confirm existence.
• Verify TTL and expiration: records with short TTLs or expired DNS records lead to intermittent validation failures. Most DMARC-compliant receivers expect valid records to persist for weeks.
• Use tools like MXToolbox or DNSStuff to scan your domain and check for missing or expired entries.

Selector or Domain Misalignment

• Double-check the selector in the email header against your DNS: DKIM-Signature: a=rsa-sha256; s=mail; d=example.com; must match the TXT record name mail._domainkey.example.com.
• Ensure the d= tag in the DKIM header matches the actual sending domain — not a subdomain or a different registered name.
• Domain alignment issues are a frequent cause of DMARC failures. If the From: domain doesn’t align with the domain in the DKIM-Signature, receivers may mark messages as unauthenticated, even if DKIM passes.
• Use a real email sender test via inbox placement testing to see how your messages land in real user inboxes, including alignment checks.

Key Format and Encoding Issues

• Ensure the public key is properly formatted: it must be a valid PEM block with -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----.
• Invalid line breaks or whitespace in the key string break parsing. Many tools auto-insert line breaks every 64 characters — but they must not occur mid-base64 block.
• Use base64 -d to verify encoding works before publishing. If decoding fails, the key is malformed.
• Be cautious with tools that auto-generate keys — some omit proper PEM formatting entirely. Validate your output using a known working tool or RFC 6376.

Real-World Example: Validating a DKIM Record in Production

You're using SendGrid to send mail from yourdomain.com with a DKIM selector s1. To verify the DNS record, run dig TXT s1._domainkey.yourdomain.com and check that the output includes v=DKIM1; k=rsa; p=.... If it doesn’t, the record is misconfigured — common issues include typos, missing quotes, or propagation delays. DNS propagation can take up to 48 hours, but most changes resolve within minutes. If the record is still missing after 10 minutes, double-check the configuration in your DNS provider's dashboard.

Step-by-Step Validation Process

1. Open your terminal or command line. Run dig TXT s1._domainkey.yourdomain.com. This fetches the TXT record stored in DNS for your DKIM selector.
2. Look for a response that includes v=DKIM1 — this confirms the record is properly formatted as a DKIM key. Without this, your emails can’t be verified by receiving servers.
3. Check that the k=rsa tag appears, indicating the key uses RSA encryption. This is the only supported algorithm for DKIM in practice, per RFC 6376.
4. Confirm that p=... contains the public key. It should start with MIGf... or similar — a base64-encoded key pair. If this is missing, the record is incomplete.
5. If you get no output or a non-existent domain error, the record isn’t published. Go to your DNS provider (e.g., Cloudflare, Route 53, GoDaddy), verify the TXT record is created, and ensure the name is s1._domainkey.yourdomain.com exactly.

Common Pitfalls and Fixes

Even if the record exists, it can fail silently. One frequent mistake is forgetting to enclose the full value in quotes when editing it in some DNS interfaces. For example, omitting "v=DKIM1; k=rsa; p=..." as a single quoted string breaks parsing.

Another issue: some providers strip whitespace or line breaks. Use dig to check the raw output. If it’s missing or malformed, update the record and recheck. You can also test via third-party tools like MXToolbox or RFC 6376, which defines DKIM syntax.

If you're still stuck, verify your domain’s SPF and DMARC records. A misconfigured DMARC policy can cause your DKIM-valid emails to be rejected in practice, even if the DNS record is technically correct.

Once verified, your domain’s sender reputation improves. According to industry data, properly configured DKIM reduces spam complaints and improves inbox placement — a key metric you can test using MailTester’s inbox placement tool.

DKIM, SPF, and DMARC: The Triad of Email Authentication

You can’t guarantee email delivery without correctly configured SPF, DKIM, and DMARC records. SPF checks if the sending IP is authorized, DKIM verifies the message wasn’t altered in transit, and DMARC tells receiving servers what to do if either check fails. All three must align and be publicly available via DNS to avoid being flagged as spam or rejected outright.

How Each Record Works in Practice

SPF is like a guest list — it lists the IP addresses allowed to send emails on your domain’s behalf. If an email arrives from an unlisted IP, the server may reject it. DKIM acts as a digital signature: it cryptographically signs each message so the recipient can confirm it hasn’t been tampered with during delivery. DMARC is the enforcement layer — it tells receivers how to handle messages that fail SPF or DKIM checks, based on your policy (p=none, p=quarantine, p=reject).

For example, a message passing SPF but failing DKIM will still be rejected if your DMARC policy is set to reject. Misalignment — like sending from a subdomain but signing with a different domain — breaks the chain. Reputable services like Google and Microsoft use these records to filter millions of messages daily. According to RFC 7672, proper alignment reduces phishing and spoofing attempts by over 90% in enterprise environments.

Verifying the Triad: Why DNS Checks Matter

Just publishing records isn’t enough. You must verify they’re correct, published, and accessible. That’s where tools like MailTester’s DNS check come in — it shows if your SPF, DKIM, and DMARC records are properly formatted and reachable from the public internet.

Running a DNS TXT query via command line (dig, nslookup, or host) lets you see raw record data. If SPF returns multiple mechanisms or syntax errors, your email may be rejected. If DKIM’s public key doesn’t match the signature, the message fails integrity checks. DMARC policy failures often result in silent drops or spam folder placement.

Let’s say you send a test email. Without all three records validated, even a single mistake can ruin deliverability. Use MailTester’s email checker to test individual addresses before sending, and its inbox placement tool to simulate how your messages land across real inbox providers.

Always treat these records as a system. One weak link — like an expired DKIM key or a misaligned DMARC policy — can cause entire domains to be blacklisted. Regular validation with public DNS tools is no longer optional — it’s how you maintain sender reputation at scale.

How MailTester Can Help Verify DKIM-Related Deliverability Risks

MailTester’s real-time verification API checks whether domains have properly configured DKIM and SPF records by analyzing the full authentication stack during delivery tests. It gives you immediate feedback on whether an email address resides on a domain with functional email authentication—critical for maintaining sender reputation and inbox placement. With 98.9% accuracy, you can trust the verdicts on whether a recipient is likely to receive your message.

Testing the Full Authentication Stack

When you test an email address with MailTester, it doesn’t just check syntax or existence. It simulates the actual delivery process, probing DNS records including SPF, DKIM, and DMARC in real time. This includes validating that the DKIM signature is present, correctly formatted, and aligns with the domain’s public key. If any part of the chain is broken—say, a misconfigured DKIM record or a missing selector—it surfaces the risk before you send.

For example, a valid email address might still bounce if the domain’s DKIM record is outdated or not published correctly. MailTester catches that. Unlike manual DNS lookups, which only verify record existence, MailTester assesses the functional outcome. It’s like testing whether a door is unlocked, not just checking if the lock exists.

Why Accuracy Matters in Deliverability

Even small misconfigurations in DKIM or SPF can lead to high bounce rates or inbox filtering. ISPs and email providers use these records to verify sender legitimacy. A failed check doesn’t always mean the message is spam—but it increases the risk of being rejected or marked as suspicious.

According to RFC 6376 (which defines DKIM), correct signature alignment is essential for authentication success. MailTester’s 98.9% accuracy ensures you’re not relying on guesswork. It’s built on real-time checks, not heuristic models or incomplete data. If you’re sending to a list and want to know if recipients are truly deliverable, you need more than a DNS query—you need a system that mirrors what email providers see.

Want to vet your entire list in seconds? Use MailTester’s bulk verification to scan thousands of addresses and flag those linked to domains with broken SPF or DKIM. Or integrate our real-time verification API into your signup flow for immediate feedback. The same tool that checks DKIM also evaluates role accounts, disposable domains, and greylisting—giving you a complete picture of deliverability risk.

For deeper insights, try the inbox placement test to see how your message lands across major providers. It’s not just about authentication. It’s about whether your email actually gets seen.

When and Why to Double-Check Your DKIM Configuration

You should verify your DKIM records before launching campaigns, after switching email providers, or when troubleshooting delivery failures. Even a single typo in your DNS TXT record can cause emails to fail authentication and land in spam. Use a DNS TXT query to confirm your DKIM key is live and correctly formatted—this prevents wasted sends and protects sender reputation.

Common Triggers for DKIM Validation

• Before launching a new email campaign: A single misconfigured DKIM record can result in delivery failures. Validate the record to ensure your messages are properly authenticated and trusted by receiving servers.
• After switching email providers or updating DNS: Changes to your email infrastructure often require new DKIM keys. Use a command-line DNS query to confirm the new record is live and accessible before sending to real users.
• When analyzing bounces or spam reports from third-party services: A hard bounce with “Authentication failed” or “DKIM not valid” is a signal that your record may be missing or malformed. Verify it with a real DNS lookup to rule out configuration errors.

How to Confirm Your DKIM Record Is Live

DKIM relies on DNS TXT records that receiving mail servers query in real time. If your record isn’t published correctly, or if it’s delayed due to TTL settings, your emails may fail verification—especially with strict spam filters. Use tools like Google’s DNS Health Check or RFC 6376 to inspect the expected format and content.

For quick, accurate validation, run a command like dig TXT example._domainkey.yourdomain.com and check the output for the correct key syntax. Even if your DNS provider shows the record as "saved," it may not be propagated globally. A real-time query ensures you’re not relying on outdated or incomplete data.

You can test multiple email addresses with a tool like MailTester’s email checker to simulate delivery and verify that DKIM is applied correctly across your list. For high-volume senders, consider integrating MailTester’s API to verify addresses before every campaign, reducing bounces and improving inbox placement.

The Best Tools for Manual DNS Record Validation

You can validate DKIM records manually using built-in command-line tools like dig, nslookup, or host, which are available across Linux, macOS, and Windows (via WSL). These tools give you real-time, precise feedback directly in your terminal, making them ideal for troubleshooting and auditing. Online tools like MXToolbox or Spamhaus offer DNS lookups too, but they don’t provide the same level of control or audit trail during active debugging.

Command-Line Tools: Precision and Control

Let’s be clear: for manual, reproducible checks, nothing beats the CLI. dig is the most powerful and widely available. Run dig TXT yourselector._domainkey.yourdomain.com to fetch the DKIM record directly from DNS. The response includes the full TXT value, error codes, and timing — all critical during deliverability audits. On macOS or Linux, these tools are installed by default. Windows users can leverage WSL for the same experience.

The output isn’t just text — it’s structured data. You can parse it in scripts, log it, and compare results across systems. This level of transparency isn't available with web-based checkers, which often cache responses or obscure details. When an email fails to authenticate but the DNS looks correct, you need to confirm you’re seeing the live, authoritative record — not a proxy snapshot.

Online Resolvers: Convenience, Not Precision

Resolvers like MXToolbox or Spamhaus let you check DNS records by typing a domain. They’re handy for a quick glance, especially when you’re not at your terminal. But they don’t replace CLI tools. They cache data, abstract away details, and don’t offer versioned logging. If you’re debugging a deliverability issue with a major ESP, relying on a web interface without local verification is like guessing instead of measuring.

For any environment requiring compliance, audits, or repeatable troubleshooting, you must use a tool that logs its queries exactly as they were made. The RFC 1035 and RFC 1034 define DNS record behavior with precision — and tools like dig follow those specifications exactly. This is why they’re the industry-standard choice, even in enterprise setups.

If you’re validating DKIM records in bulk or during infrastructure setup, consider using a tool like MailTester’s email checker to verify entire lists for deliverability readiness. It goes beyond DNS — checking syntax, domain reputation, and mailbox existence — giving you a full picture before sending.

Final Steps: Confirming DKIM Alignment and Deliverability Health

Once the DKIM TXT record is published and verified via DNS lookup, the next step is to send a test message to a mailbox provider’s designated test address. This confirms that the record is not only present but actively recognized during delivery.

Use MailTester’s inbox placement testing to see how your message is treated by real inbox providers. This reveals whether the email lands in the inbox, spam, or is blocked entirely — a direct signal of your sender reputation and technical setup.

If both DKIM and SPF validation succeed, and the email content avoids spam triggers, you have a strong foundation for consistent inbox placement. Real-time testing and verification are the only way to confirm that alignment is working at scale.

Sources

• 52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
• Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

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

Frequently asked questions

What does a failed DKIM validation mean?

It means the receiving server could not verify the email's signature against your published public key. This often results in delivery failure or spam filtering.

Can I validate DKIM using only my email client?

No — email clients display the received message but do not reveal DNS-level authentication data. You need external DNS tools or APIs for validation.

How often should I check my DKIM record?

Validate at least once before launching a new campaign, after DNS changes, and periodically during high-volume sending.

What is a DKIM selector?

A selector is a name used to identify the public key in DNS. It’s included in the DKIM-Signature header and must match the TXT record name.

Does DKIM guarantee inbox placement?

No — DKIM ensures message integrity and domain authentication, but inbox placement also depends on reputation, content quality, and engagement.

Is there a difference between DKIM and DMARC?

Yes — DKIM verifies message signature, while DMARC defines policies for handling messages that fail SPF or DKIM checks.

Can I have multiple DKIM records?

Yes — multiple selectors allow different keys for different domains, systems, or time periods, as long as each is correctly published.

Why does my DKIM record show ‘Invalid Public Key’ in tools?

The key may be malformed, have incorrect line breaks, or include non-PEM elements like quotes or extra spaces. Validate the base64 and PEM format.

How do I fix a missing DKIM record?

Add a TXT record to your DNS zone using your provider's interface, with the correct selector and full key syntax.

What happens if DKIM fails but SPF passes?

The message may still be rejected or marked as suspicious if DMARC policy enforces alignment failures, even if SPF is correct.

Can I use MailTester to test DKIM in real-time?

Yes — MailTester’s inbox placement and deliverability tests verify whether DKIM is properly aligned and recognized by major mailbox providers.

Do I need to manually check DKIM every time?

Not if you use tools like MailTester, which provide automated checks across domains. But manual validation remains essential for debugging.

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• How to Fix DMARC p=none adkim=r False Positives in Email Filtering
• Using DNS Query to Verify DKIM Record Alignment and Structure
• Why DMARC Policy p=none with Relaxed Alignment Causes False Positive Quarantine
• How to Correctly Write IPv6 Range in SPF Record for IPv6 Addresses