How do email headers reveal spoofed authentication attempts?

You receive a message that looks like it’s from your bank. The sender address matches. The subject line is urgent. But something feels off. You glance at the email headers—and that’s where the truth begins to show.

Headers are the digital logbook of an email’s journey. They record every server it passed through, the domains involved, and whether cryptographic checks like DKIM were applied. Spoofed messages often fail these checks. A missing or invalid DKIM signature is a red flag. But validating that signature means retrieving the sending domain’s public key—this is where public key lookup comes in.

Key takeaways

  • Public key lookup in DNS is required to verify DKIM signatures in email headers.
  • Mismatched or missing DKIM signatures in headers often indicate spoofed or tampered messages.
  • Validating authentication results by parsing headers and performing real-time public key lookups is essential for detecting email impersonation.

What is public key lookup and why does it matter in email authentication?

Public key lookup is the process of retrieving a domain’s DKIM public key from DNS records to verify the authenticity of an email’s digital signature. Without this step, even a valid DKIM signature can’t be trusted—you can’t prove it came from the sender it claims to. It’s a critical checkpoint in email authentication that stops spoofed messages from slipping through.

How public key lookup works in practice

When an email arrives, the receiving server checks the DKIM signature in the headers. To verify it, the server performs a DNS query to pull the public key tied to the sending domain. That key is used to decrypt the signature and confirm the message wasn’t altered in transit. If the key isn’t found, or if the DNS record is misconfigured, the validation fails—regardless of the signature’s existence.

Let’s say a customer hits "reply" to a phishing email that mimics your brand. If your DKIM records are set up correctly and a public key lookup is performed, the receiving server will detect that the signature doesn’t match your domain’s published key. That stops it from being marked as legitimate—even if it looks like it came from your company.

This process is defined in RFC 6376, the standard for DKIM, which mandates that verification systems must fetch the public key from the sender’s DNS zone. You can read the full specification at IETF’s RFC 6376. The system’s trust model relies on DNS as a trusted source of public keys, making the lookup not just technical—but foundational to email integrity.

Why skipping public key lookup breaks authentication

If a server skips or fails to perform a public key lookup, DKIM verification becomes meaningless. A signature could be forged, or the key could be outdated, and there would be no way to detect it. Some older systems or misconfigured providers assume the key is safe without validating it—this is a serious vulnerability.

That’s why tools like MailTester’s email checker include public key lookup in their verification process. It doesn’t just confirm that an address exists—it checks whether the domain has properly published a DKIM record and whether that record is reachable and valid. A flawed key record is a red flag, even if the email address is real. If you’re sending emails at scale, catching these issues early avoids sender reputation damage and inbox placement failures.

Think of public key lookup as the final gate before trust is granted. No key? No trust. It’s not optional. It’s built into the email ecosystem for a reason—and skipping it weakens the entire chain.

How does public key lookup help detect spoofed authentication in email headers?

When an email includes a DKIM-Signature header, the receiving server looks up the sender’s public key using DNS to verify the signature. If the key is missing, expired, or doesn’t match the signing domain, the message fails authentication — a red flag for spoofing. Attackers can fake DKIM headers but can’t produce a valid public key tied to the claimed domain, so public key lookup exposes fraudulent messages.

How DKIM Verification Works in Practice

Let’s say you receive an email claiming to be from your bank. The message includes a DKIM-Signature header. The receiving mail server extracts the signing domain — like bank.example.com — and queries the domain’s DNS records for the public key published under a specially named TXT record. If the key exists and matches the signature, the email passes. If not, it fails. This step is automated and happens in milliseconds.

Spoofers can’t replicate the real public key, so they often leave it blank or insert a fake one. A missing or invalid key in DNS is a strong indicator that the header was forged. This is why SPF and DKIM are often paired — SPF checks the sending server, while DKIM checks the message integrity via public key lookup.

Public key lookup is part of a larger email authentication framework. It relies on proper setup of DMARC policies, which tell receivers what to do with messages that fail DKIM or SPF. The Internet Engineering Task Force (IETF) outlines these protocols in RFC 6376 (DKIM) and RFC 7483 (DMARC). You can review the technical details in the official standards documents through IETF's datatracker.

Why This Matters for Deliverability and Security

Even if a message passes SPF, a failed DKIM lookup can still sink it in the spam folder. Mail receivers like Gmail and Microsoft use a combination of auth results to score each email. Failures in public key lookup contribute to negative reputation signals, especially when repeated across large sends.

If you’re sending bulk mail, checking for valid DKIM signatures before sending reduces the risk of rejection. You can test your setup with inbox placement tools that simulate real-world delivery, like the inbox tester on MailTester, which checks whether your emails land in the inbox and how they fare against authentication checks.

What happens when public key lookup fails during email verification?

If a public key lookup fails during email verification, DKIM validation cannot be completed, even if SPF passes. This results in a failed authentication check, increasing the risk score for the email—especially if the domain enforces DMARC policies set to reject or quarantine unauthenticated messages. Without a valid DKIM signature, the message may be treated as suspicious or outright rejected by receiving servers.

Why DKIM failure matters even when SPF passes

SPF and DKIM serve different roles in email authentication. SPF validates the sending server’s IP address, while DKIM ensures the message content hasn’t been altered and confirms the sender’s domain ownership. A successful SPF check doesn’t compensate for a missing or invalid DKIM signature. If the domain has DMARC policies configured to enforce rejection, a failed DKIM lookup means the message is likely blocked or sent to spam.

Public key lookup is critical for this process. DKIM relies on a public key stored in the domain’s DNS records. If the lookup fails—due to misconfiguration, missing records, or outdated DNS—verification tools cannot validate the signature. This is common with domains that use dynamic key rotation or inconsistent DNS setups.

How MailTester catches failures early

Let’s say you're sending a campaign and want to ensure your emails reach inboxes. You might assume SPF is enough. But unless you verify DKIM, you’re missing a key layer. MailTester’s real-time verification API includes automated public key lookup to detect exactly this issue before you send.

When you check an email address via the real-time verification API, it doesn’t just check validity—it tests the full authentication chain, including whether the receiving domain’s DKIM public key is retrievable and correctly referenced. If the lookup fails, the tool flags it as a high-risk indicator. This isn’t speculative; it’s based on how email servers actually validate messages.

According to the RFC 6376 standard, which defines DKIM, the receiver must retrieve the public key from DNS to verify the signature. When this fails, the validation process cannot proceed. You can see how a single point of failure—like a misconfigured DNS record—can jeopardize deliverability even with a correct sender IP.

Because MailTester checks the full stack, including DNS record accessibility and cryptographic consistency, you know exactly which addresses carry a higher risk of delivery issues. This isn’t just about catching invalid addresses—it’s about catching authentication flaws that lead to rejections you can’t see until it’s too late.

How MailTester performs public key lookup to detect spoofed authentication

When an email arrives, MailTester checks the DKIM-Signature header to extract the selector and domain. It then queries the recipient domain’s DNS to retrieve the corresponding public key. If the key is missing, malformed, or doesn’t match the signature, the message is flagged as risky or invalid—helping catch spoofed emails before they reach your inbox.

Step-by-step: How public key lookup works in practice

  1. Extract the DKIM selector and domain from the DKIM-Signature header. This tells MailTester which public key to look up. The selector is part of the DNS record name, like key1._domainkey.example.com, and determines where to find the key.
  2. Query the domain’s DNS using standard DNS lookup protocols. MailTester checks for the TXT record at the location specified by the selector. If no record exists, or the response is malformed, the key is unreachable.
  3. Validate the key format and syntax. The retrieved key must follow the standards laid out in RFC 6376. If it's incorrectly formatted—missing required fields, invalid base64 encoding, or uses an unsupported algorithm—it’s rejected.
  4. Verify the signature against the public key. MailTester uses the public key to decrypt the digital signature in the header and compares the result with a hash of the message content. A mismatch indicates tampering or spoofing.
  5. Flag the result with precise error codes. If any step fails, the result is marked as 'invalid' or 'risky' with a descriptive code. These codes help you understand exactly what went wrong—whether it was a missing key, wrong format, or signature mismatch.

Why this stops spoofed emails before they land in your inbox

Spammers and attackers often forge DKIM signatures to bypass filters. But without the correct private key, they can’t produce a valid signature. MailTester doesn’t just check if a key exists—it validates its actual use. That means a forged signature with a fake key will fail at step four, even if the DNS record appears present.

Step-by-step: How public key lookup works in practiceThe 5 steps described in “Step-by-step: How public key lookup works in practice”, in order.1Extract the DKIM selector and domain from the DKIM-Signature header.This tells MailTester which public key to look up. The selector is partof the DNS record name, like key1._domainkey.example.com, and determineswhere to find the key.2Query the domain’s DNS using standard DNS lookup protocols. MailTesterchecks for the TXT record at the location specified by the selector. Ifno record exists, or the response is malformed, the key is unreachable.3Validate the key format and syntax. The retrieved key must follow thestandards laid out in RFC 6376. If it's incorrectly formatted—missingrequired fields, invalid base64 encoding, or uses an unsupportedalgorithm—it’s rejected.4Verify the signature against the public key. MailTester uses the publickey to decrypt the digital signature in the header and compares theresult with a hash of the message content. A mismatch indicatestampering or spoofing.5Flag the result with precise error codes. If any step fails, the resultis marked as 'invalid' or 'risky' with a descriptive code. These codeshelp you understand exactly what went wrong—whether it was a missingkey, wrong format, or signature mismatch.
The 5 steps described in “Step-by-step: How public key lookup works in practice”, in order.

This is an industry-standard practice. The IETF’s RFC 6376 defines DKIM as a cryptographic mechanism to verify email authenticity, and DNS-based public key lookup is its foundation. RFC 6376 covers the protocol in detail—this is how legitimate systems verify DKIM.

“DKIM is not a filter—it’s a trust mechanism. Without proper public key validation, spoofing remains possible.”

If you’re building or managing email workflows, understanding this process helps you spot anomalies early. You can test your own messages before sending with our inbox placement tester, or verify bulk lists with precise accuracy using our bulk verification tool. Every step is designed to expose problems before your message gets rejected or marked as spam.

What are common public key lookup failures and what they mean

When a public key lookup fails, it means the email’s DKIM signature can’t be validated. A missing, malformed, or mismatched key often indicates poor authentication setup, intentional spoofing, or a tampered message. These failures are red flags for deliverability and security—especially since legitimate senders should have consistent, correct public keys. If you’re seeing them at scale, it’s time to audit your authentication setup or check if messages are being intercepted.

Common failure reasons and their implications

  • No DNS record found: The DKIM selector (e.g., default in default._domainkey.example.com) doesn’t resolve in DNS. This usually means authentication is either incomplete or misconfigured—common with temporary setups or poorly managed domains. A lack of entry here means no valid public key exists, so any DKIM signature fails by definition.
  • Invalid key format: The DNS record exists but contains malformed or non-standard data—like a key wrapped in quotes, missing PublicKey= prefix, or using a non-RFC-compliant encoding. This commonly occurs in test environments, automated scripts, or when attackers insert fake entries. Valid keys follow the structure defined in RFC 6376, and deviations typically signal non-compliance or spoofing.
  • Key mismatch: The public key in DNS doesn’t match the signature’s cryptographic hash. This means the message was altered after signing, or the key was tampered with. Even if the record exists and is valid, a mismatch indicates an active compromise. This is not a misconfiguration—it’s a strong sign of message tampering.

How to verify and act on lookup results

Let’s be clear: you can’t trust an email unless its DKIM signature validates against a matching public key. Tools like MailTester’s email checker let you test individual addresses or headers in real time to see if a DKIM key resolves and matches. You can also use the verification API to validate large volumes during onboarding or before sending.

Beyond individual checks, monitor your outbound email streams. A sudden rise in key lookup failures across your domain indicates either a flaw in your email infrastructure or a potential breach. Use public tools like MxToolbox to test DKIM records interactively, but pair that with automation—because manual checks don’t scale.

How to use public key lookup in bulk email verification for security

You can use public key lookup during bulk email verification to detect spoofed authentication by validating DKIM signatures and checking DMARC policy compliance. This helps flag domains with weak or missing encryption settings, reducing the risk of sending to compromised or fake addresses. Let’s break down how to apply this effectively at scale.

Include DKIM and DMARC checks in your verification pipeline

When verifying large email lists, treat public key lookup as a core part of your security filter. DKIM relies on published public keys in DNS to verify email integrity, and DMARC enforces policy enforcement based on these checks. If a domain fails DKIM validation or shows no DMARC record, it could indicate poor email hygiene or spoofing risk.

For example, a missing or misconfigured DKIM record means no valid signature verification is possible—making the email header vulnerable to tampering. This is especially critical when sending marketing or transactional mail, where inbox placement and sender reputation depend on technical trust signals.

According to the IETF’s RFC 6376, DKIM is designed to cryptographically sign email headers and body content. If the public key isn’t retrievable or the signature fails, the message is flagged as suspicious by receiving providers.

Use MailTester’s API to catch weak authentication early

MailTester’s bulk verification API checks public key lookup automatically as part of each address’s validity and reputation score. It doesn’t just confirm syntax—it analyzes whether a domain has functional DKIM and DMARC enforcement, helping you spot high-risk domains.

After verification, you can filter out domains where public key lookup consistently fails or where DMARC policies are set to “none” or “quarantine,” indicating weak or non-existent enforcement. This reduces exposure to spoofing attacks and improves overall deliverability.

You can integrate this directly into your workflow using the real-time email verification API or upload a list for comprehensive analysis via the bulk verification tool. The output includes detailed verdicts, including risks tied to broken or missing cryptographic alignment.

Think of it as auditing your sender infrastructure before sending. If a domain can’t prove it signs emails correctly, there’s no reason to include it in your campaign — even if the address looks valid.

Can public key lookup alone prevent phishing attacks?

No — public key lookup alone cannot prevent phishing attacks. It’s one piece of a larger authentication puzzle. Even if a public key is verified, spoofed messages can still slip through if SPF, DMARC, or domain reputation checks are weak or misconfigured. You need all layers working together to catch most threats.

Why public key lookup isn’t enough

Public key lookup, often tied to DKIM, checks whether a digital signature in an email header was signed with the expected private key. But it only verifies authenticity if the domain actually publishes that key. If the key is missing, expired, or improperly configured, the check fails — and you’re left with no proof of origin.

Even if the key validates, a message can still be spoofed. For example, if the From domain isn’t properly aligned with the DKIM-signing domain, or if DMARC policy is set to none (which just monitors traffic), no action is taken, even with valid signatures. This gap is exploited by attackers who abuse trusted domains with lax policies.

How to close the gaps

Let’s be clear: no single mechanism stops every phishing attempt. Public key lookup only addresses one layer. To reduce risk, you must combine it with SPF (which validates the sending server’s IP), DMARC (which enforces policies based on SPF and DKIM results), and real-time checks for domain reputation and known spam patterns.

That’s why systems like MailTester’s email verification platform include multiple validation steps. When you run a list through our bulk verification, we check for invalid addresses, catch-all domains, disposable emails, and alignment issues — all before the message even leaves your system. It’s not just about the public key; it’s about the full context of the email’s journey.

For example, a message might pass public key lookup but still come from a server with a poor sender reputation or a recently compromised domain. A full stack of checks catches those. As defined in RFC 7001, DMARC is built on the idea that alignment and policy enforcement are essential — not optional. And that alignment needs real-time visibility, which tools like MailTester provide through live, verified data.

Bottom line: public key lookup is useful. But it’s not a silver bullet. Use it in concert with DNS-based authentication and behavioral analysis — not in isolation.

How MailTester’s 98.9% accuracy supports reliable public key lookup

MailTester achieves 98.9% accuracy in public key lookup by combining real-time DNS queries with verified cached records, then validating responses against RFC 6376 standards. This dual-source approach ensures that even transient DNS issues don’t flag legitimate emails as spoofed. You’re not just checking a key — you’re verifying its integrity across a consistent, standards-compliant system.

Real-time DNS checks with defensive caching

When you verify an email’s domain for DKIM alignment, MailTester doesn’t rely on a single snapshot. It performs live DNS lookups to confirm current public key records, but it also uses a resilient cache of recent, validated responses. This means performance stays high even during brief DNS latency spikes or temporary server outages.

Transient failures — like a brief outage on a domain’s DNS resolver — are common but not meaningful. Without caching, these would trigger false alerts. MailTester filters them out by cross-referencing new results with previously confirmed data, reducing noise without sacrificing precision.

Anomaly detection through RFC 6376 compliance

Public key lookup isn’t just about finding a key — it’s about confirming it’s valid in context. MailTester checks every DNS response against the technical requirements in RFC 6376, the foundational standard for DKIM. This includes validating key formatting, selector and domain alignment, and signature consistency.

For example, a key that claims to be from a domain but lacks a valid TXT record with the correct selector syntax raises a red flag. So does a record that’s syntactically correct but points to a non-existent or misconfigured public key. Such anomalies are caught before they can be misinterpreted as spoofing attempts.

By anchoring every verification in actual standards and maintaining a feedback loop between live and cached data, MailTester minimizes the risk of marking legitimate senders as risky. This accuracy is tested and proven through real-world use across email campaigns and delivery systems. If you’re checking domains before sending, you’re not just validating syntax — you’re ensuring sender reputation holds up in practice.

For teams using MailTester to verify large lists or test inbox placement, this level of precision reduces bounce rates and protects sender reputation. Whether you're scanning a single address or doing bulk verification, the system ensures that only actionable risks surface.

Learn how to verify email addresses in advance of sending: check single addresses or verify entire lists with confidence. You can also test real deliverability with inbox placement reports or integrate MailTester into your existing workflow via native integrations.

What should you do when public key lookup fails on your outbound emails?

If your outbound emails fail public key lookup, the most common cause is a misconfigured DKIM record—either the selector is wrong, the public key isn’t published, or it’s not reachable from external DNS resolvers. Let’s walk through the immediate checks and how to test your setup before sending to real users.

Verify your DKIM configuration is correct

  • Confirm your DKIM selector matches the one used in your email signing process. A mismatch here breaks the lookup entirely.
  • Ensure the DNS TXT record for your selector is published under the correct subdomain (e.g., selector1._domainkey.example.com) and isn’t truncated or malformed.
  • Check that the SubjectPublicKeyInfo section of the public key is properly encoded in base64 without extra whitespace or line breaks.

Test external accessibility of your public key

  • Use tools like MXToolbox or DNSChecker from multiple global locations to verify your DKIM record resolves correctly from outside your network.
  • Avoid relying solely on internal DNS servers—some configurations work only within your corporate network but fail for external senders.
  • If the public key resolves locally but not from the internet, your DNS provider may be blocking or filtering external queries.
  • Ensure no firewall, reverse proxy, or CDN is interfering with DNS queries to your domain’s authoritative server.

Even if your DNS looks correct, you might still see lookup failures if your signing process uses an incorrect or deprecated algorithm. Use RFC 6376 to confirm your implementation follows standard DKIM signing procedures.

  • After fixing your DNS, test the full chain: ensure your sender domain is properly aligned with the domain in the From: header, and that DMARC policies are set to evaluate (not just monitor).
  • Use MailTester’s inbox-placement testing to validate DKIM and DMARC alignment before sending to a real audience. This simulates real-world inbox rules and shows where verification might fail.
  • Run verification on a small batch of real email addresses to catch issues early. Don't wait until your first campaign lands in spam.

DKIM isn't just about signing—it’s about ensuring every piece of the chain is publicly verifiable. A single misstep in DNS, selector, or key placement can break the entire mechanism. Fix it before your emails are rejected by Gmail, Yahoo, or other major providers.

Final thoughts: Public key lookup as a defensive layer in email security

Public key lookup isn't a standalone fix for email spoofing. It doesn't replace DMARC, SPF, or DKIM on its own. But it does offer a critical verification step—validating that a public key used in a message's digital signature is genuine and correctly configured.

When integrated into email verification workflows, public key lookup enables early detection of spoofed messages. This reduces exposure to phishing and business email compromise, especially in inbound or high-volume transactional flows.

With MailTester’s real-time API and bulk verification, you can automate public key lookup at scale. It’s part of a broader validation stack that achieves 98.9% accuracy in identifying valid, authentic, or suspicious addresses.

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 public key lookup in email headers?

It’s the process of retrieving a domain’s DKIM public key from DNS to verify the authenticity of a signed email message.

Why does public key lookup fail in some emails?

It may fail if the DKIM record is missing, incorrectly formatted, or if the DNS resolver cannot access it.

Can spoofed emails pass public key lookup?

No—spoofers cannot provide a valid public key unless they control the domain, making lookup a robust fraud detection step.

Does public key lookup work for all domains?

It works for domains with properly configured DKIM records in DNS. Unsupported domains will return no key.

How does MailTester use public key lookup?

It queries DNS for the public key, validates its structure, and checks it against the DKIM signature in the header.

What happens if public key lookup fails during verification?

The email is flagged as 'risky' or 'invalid' due to inability to verify DKIM, indicating potential spoofing.

Can public key lookup help prevent phishing?

Yes—but only as part of a broader system including SPF, DMARC, and sender reputation monitoring.

How accurate is public key lookup in MailTester?

MailTester achieves 98.9% accuracy in verification, including reliable public key lookup and validation.

Is public key lookup required for email authentication?

It’s required for DKIM verification, which is a core component of modern email authentication standards.

Can I test public key lookup manually?

Yes—use tools like dig or nslookup to query the DKIM TXT record for a domain and verify its content.

Why does MailTester offer inbox-placement testing?

To test how well authenticated emails perform in real inboxes, including detection of spoofing and filtering issues.

Do purchased credits in MailTester expire?

No—MailTester credits never expire, allowing you to use them flexibly over time.