What does 'DKIM d= domain not in public suffix list' mean?

You sent a well-crafted email, verified your SPF, set up DKIM — and it still failed verification. No bounce, no error message you recognize. Just a quiet "DKIM d= domain not in public suffix list." What does that even mean?

It means the domain in your DKIM signature’s 'd=' tag isn’t one DNS servers treat as valid for authentication. That’s not a typo. It’s not a typo in your email — it’s a typo in your signing setup.

DKIM works by trusting the domain where the signature originates. But that domain must be a public suffix — like example.com or org.uk — not a subdomain like mail.example.com. Otherwise, DNS validation fails, and your email gets treated as unverifiable.

Key takeaways

  • DNS record check for DKIM d= domain not in public suffix list means the domain in the DKIM 'd=' tag is not a recognized public suffix (like .com or .uk).
  • DKIM verification fails if the 'd=' domain is a subdomain, even if it’s real and correctly configured.
  • Always use a top-level or country-code public suffix in the DKIM 'd=' tag to ensure DNS-level validation succeeds.

Why your DKIM d= domain fails the public suffix check

You’re using a subdomain like d=mail.company.com in your DKIM signature, but it’s not a valid public suffix. The DKIM d= domain must be a top-level or registered domain (like company.com) listed in the Public Suffix List (PSL), not a subdomain. Even if the email goes through, misalignment prevents DKIM validation and risks delivery issues.

What the public suffix list actually means

The Public Suffix List defines which domains are controlled by users versus registered authorities. A domain like company.com is a valid public suffix—its DNS is authoritative and widely recognized. But mail.company.com is a subdomain, assigned by you, not the registry. That’s why tools that validate DKIM will fail on it.

When a receiving server checks the DKIM signature, it verifies the d= domain’s DNS records. If that domain isn’t in the PSL, it can’t be trusted as an authority, even if it resolves and accepts mail. This is a standard check enforced by modern email providers and spam filters.

Why alignment matters even if email works

Just because an email from mail.company.com reaches the inbox doesn’t mean DKIM passes. The signing domain must align with the From address domain. If your From is [email protected] and your DKIM uses d=mail.company.com, the alignment fails.

Even if the domain exists and receives mail, DKIM validation can’t proceed if the signing domain isn’t a known public suffix. This is why some email providers mark your messages as “not authenticated” or “low trust”.

See how the PSL is maintained for consistency across systems — you can find the current list at publicsuffix.org. While the list is updated frequently, it’s also a technical baseline used in all major email validation pipelines.

If you're unsure whether your DKIM domain is valid, verify the full signature setup before sending. Use tools like MailTester’s inbox placement test to see if DKIM passes on real receiving servers, and spot alignment issues early.

How DKIM works and what the 'd=' tag does

You verify DKIM by checking if the domain in the 'd=' tag of the DKIM-Signature header is in the Public Suffix List (PSL). If it isn't, the DNS lookup fails or returns unexpected results, breaking signature validation. The 'd=' domain must be a registrable domain — not a subdomain of a domain not under a user’s control — to pass. This is why domains like mail.google.com fail, but google.com works.

The role of the 'd=' tag

The 'd=' tag in the DKIM-Signature header defines the domain responsible for signing the email. It’s not just a placeholder — it’s the domain whose public key is used to verify the signature. Think of it as a digital fingerprint tied to that specific domain. The receiving server doesn't just check the signature; it looks up the public key in DNS under selector._domainkey.d=domain.com.

Let’s say you’re receiving an email signed with d=example.com. The server fetches the DNS record from selector._domainkey.example.com to get the public key. If that domain isn’t in the PSL — meaning it’s not a valid, registrable domain — the DNS lookup will fail, or return junk data, leading to validation errors. This is why using a subdomain that doesn’t resolve to a real registrable domain breaks DKIM.

Why the Public Suffix List matters

Public Suffix List (PSL) is maintained by Mozilla and keeps track of domains where you can register a subdomain. Domains like mail.google.com are not valid for DKIM 'd=' tags because you can’t register them — only Google can. But google.com is valid. This is baked into how DNS resolvers validate domains.

When you sign using a 'd=' value that’s not in the PSL, some mail servers will reject the signature outright. Others may flag the email as suspicious. This is common in cases where senders use nested subdomains like smtp.mails.example.com — even if the domain exists, it’s not a registrable domain and thus fails DKIM checks.

Even if you’re using a proper domain, misconfigured DNS or typos in the selector or domain can cause the same failure. You can verify this using tools like DMARCian's DKIM checker or via MXToolbox. But the real fix starts with ensuring the 'd=' domain is a valid, public suffix.

For teams maintaining sender reputation and inbox placement, validating DKIM setup early is critical. Use real-time email verification tools to catch such issues before sending. Check individual addresses for validity, including proper DKIM alignment, or run a bulk verification to test your list for structural errors in DKIM setup.

How to check if a domain is in the public suffix list

You can verify if a domain used in a DKIM d= tag is in the public suffix list by visiting the official site at publicsuffix.org. Only domains listed there will pass DNS validation, meaning your DKIM signature will be recognized as valid by receiving mail servers. If the domain isn’t in the list—like a subdomain or a private domain—it will fail DNS checks, breaking DKIM verification.

Step-by-step: Validate your DKIM d= domain

  1. Go to https://publicsuffix.org/ — this is the authoritative source for public suffix data used by browsers and email systems.
  2. Copy the domain used in your DKIM d= tag — for example, example.com, not mail.example.com or admin.example.com. Use only the base domain.
  3. Paste that exact domain into the search bar on the Public Suffix List website. The tool will return whether the domain is in the list and show its status (public, private, or wildcard).
  4. If the domain appears, it qualifies as a valid public suffix. That means it can be used in DKIM d= tags and will pass DNS checks.
  5. If it doesn’t appear, the domain is either a private suffix (like a company subdomain) or not recognized as a valid top-level domain. Using it in DKIM will fail validation, leading to email rejection or spam filtering.

Why this matters for DKIM and deliverability

DNS record checks for DKIM rely on correct public suffix parsing. If the d= domain isn’t in the public suffix list, mail servers treat it as unresolvable — even if the DNS record technically exists. This is why, for example, using d=app.example.com fails, but d=example.com works if example.com is in the list.

For senders using DKIM, this step is essential. A misconfigured d= tag due to an invalid domain can break all outbound email authentication, hurt sender reputation, and reduce inbox placement. Always validate the d= domain before sending.

You can also use MailTester’s email checker to verify the full email address and catch these issues early — including invalid d= domains during a real-time validation.

“A domain not in the public suffix list cannot be used in DKIM unless it’s a private domain explicitly trusted by the receiving server.” — RFC 6827

Remember: only top-level, publicly recognized domains (like com, org, co.uk) appear in the list. Subdomains, private domains, or internal domains do not. This is a foundational requirement for email authentication systems working at scale.

Common DKIM d= errors due to invalid domain alignment

If your DKIM d= domain isn’t in the public suffix list—like using a subdomain such as mail.example.com instead of example.com—the signature fails validation, causing bounces or spam placement. This happens because receivers check the domain's root authority, and subdomains aren’t trusted for authentication without explicit policy. Let’s look at the most common causes.

Using subdomains in d= instead of the root domain

  • DKIM requires the d= domain to resolve to a valid, published DNS record. Using a subdomain like d=mail.example.com breaks alignment—mail servers expect d=example.com. The IANA root zone defines what qualifies as a public suffix; subdomains aren’t included.
  • Let’s say you send from [email protected] but sign with d=mail.company.com. Even if the key exists, the validator compares mail.company.com against the SPF and DMARC policies on company.com, which often fail. This misalignment triggers rejection.
  • Fix this by ensuring your DKIM selector and d= domain align with your sending domain’s root. Test your DNS records with tools like MxToolbox to verify visibility and correctness.

Misaligned signing domains and weak DMARC policies

  • Signing with a domain that’s not your sending domain—e.g., d=partner.com when the email is sent from [email protected]—creates a mismatch. Even if DKIM validates, DMARC checks alignment and will fail if the domain doesn’t match the from address.
  • DMARC strict mode (fo=1) requires both SPF and DKIM to pass using the same domain. If the DKIM d= domain doesn’t match the sender’s domain in the header, the message is flagged—even if the signature is technically valid.
  • Weak or overly strict DMARC policies can amplify alignment issues. If you use p=reject on a domain with misaligned DKIM, legitimate emails get bounced. Use p=none during testing to observe behavior without disruption.

Pro tip: Before sending mail, verify your domain alignment using a real-time email verification tool. MailTester’s bulk verification checks not just syntax but DNS-level alignment, including DKIM and SPF record consistency, helping you catch these errors before they hurt deliverability.

How to fix the DKIM d= domain not in public suffix list error

When your DKIM signature uses a subdomain like d=mail.example.com, it can trigger a "not in public suffix list" error because the DNS validation system checks against the root domain. To fix it, set the d= tag to the root domain, such as d=example.com, and ensure your DKIM DNS record is published at _domainkey.example.com. Use a tool that validates the full DKIM record, not just syntax, to confirm public suffix alignment and avoid delivery failures.

Step-by-step fix

  1. Verify the d= tag value in your DKIM signature. It must point to your root domain (e.g., d=example.com), not a subdomain like mail.example.com. The public suffix list includes only top-level domains and their immediate parents (e.g., com, co.uk), not arbitrary subdomains.
  2. Check your DNS record zone. The DKIM record must be published at the exact zone level of the domain listed in d=. For d=example.com, the record goes at _domainkey.example.com, not _domainkey.mail.example.com. Misplaced records are ignored during verification.
  3. Use a tool that checks live DKIM records. Many tools only validate syntax. To catch public suffix issues, you need a system that resolves the full DNS record and checks public suffix list compatibility. This includes testing the actual behavior of the domain in mail systems, not just parsing the string.
  4. Validate against known standards. The public suffix list is maintained by Mozilla and used by major email providers (Google, Microsoft) to determine domain ownership. You can review the latest list at publicsuffix.org to confirm your domain qualifies.

Why this matters

Modern mail servers use the public suffix list to validate DKIM signatures. If a domain isn’t in the list, the signature fails validation—even if the DNS record is correct. This causes rejection or spam filtering, especially for senders using third-party services or custom domains.

Tools like MailTester’s inbox placement tester check real DKIM configurations across multiple providers to catch issues like this before you send to real users.

How MailTester helps catch DKIM d= issues before sending

You’re using DKIM to sign emails, but if your d= domain isn’t a valid public suffix, your signature fails silently—even if DNS resolves. MailTester checks every d= domain in your DKIM signature in real time, flags non-public suffixes, and tells you exactly why: for example, d=mail.company.com is invalid because it’s not a publicly recognized domain suffix. This prevents deliverability issues before they happen.

Why public suffixes matter for DKIM

DKIM uses the d= tag to identify the signing domain. If that domain isn’t in the public suffix list, email servers can’t verify it properly. Even if DNS looks fine, the domain might be a subdomain of a company or internal service—like mail.sales.company.com—which isn’t a valid signing domain. According to publicsuffix.org, only top-level and trusted second-level domains should be used in DKIM d= fields.

Let’s say you’re sending from d=mail.example.com—it resolves in DNS, but the domain example.com is public suffix compliant. That’s okay. But if your d= is mail.department.example.com, that fails because the full path isn’t a valid suffix. MailTester detects this exact mismatch. It doesn’t just check syntax. It validates that the d= domain is a public suffix—and will flag any deviation.

How MailTester catches these issues before you send

With our real-time verification API, MailTester checks every DKIM signature in your batch list against the public suffix list. It does this without requiring you to manually audit each domain. You don’t need to run external tools or guess which subdomains are valid.

When an issue arises, we don’t just say “invalid.” We give clear feedback: d=mail.company.com is invalid because it’s not a valid public suffix. That level of detail helps you fix the root problem—like adjusting your email signing domain to company.com instead of a nested subdomain.

Whether you run bulk lists through our email list verification, automate checks via the API, or test individual addresses with our email checker, you get the same rigorous DNS and public suffix validation. This prevents hard bounces and poor inbox placement due to malformed DKIM—a silent but damaging issue many teams overlook until they see low engagement.

If your DKIM is failing despite correct syntax, check the d= domain. It might not be your key or selector—it might just be the wrong domain type. With MailTester, you find out before the email leaves your system.

What happens if you ignore this error?

If your DKIM d= domain isn’t in the public suffix list, receiving servers may reject or flag your messages, even if SPF and DMARC are set up correctly. This failure undermines trust in your email, reduces inbox placement, and can harm sender reputation over time. Let’s look at what actually breaks when you ignore it.

DNS record check issues trigger real delivery failures

  • DHCP or DNS misconfigurations that exclude the DKIM d= domain from the public suffix list prevent receiving servers from validating the signature. This means your email’s digital seal is treated as broken, even if the key is correct.
  • Without a valid DKIM signature, your messages may be marked as unverified or suspicious by major inboxes like Gmail, Outlook, or Yahoo — regardless of good SPF or DMARC alignment.
  • Even one failed DKIM check is enough to trigger spam filters in some environments, especially if you’re sending at scale or have a history of inconsistent authentication.
  • Receiving servers use the public suffix list to determine which domains are authoritative for DNS checks. If your d= domain isn’t on that list (e.g., a subdomain of a private internal domain), validation fails by design — this is standard behavior per RFC 6376 and used by every major email provider.

Reputational damage compounds over time

  • Repeated DKIM validation failures, even if isolated, can degrade your sender reputation. Some providers track authentication consistency over time and may reduce your delivery rate if errors persist.
  • Emails from poorly authenticated senders often end up in folders like Promotions, Social, or Spam — not just one time, but consistently, reducing engagement and signaling poor list hygiene.
  • Even if your domain passes SPF and DMARC, a single DKIM failure can break the chain of trust. These three protocols work together — and if one fails, the whole stack is questioned.
  • Reputable systems like Spamhaus and MxToolbox use authentication results as part of their reputation scoring. A pattern of unverified messages correlates with lower sender trust scores.
  • Fixing this isn’t just about DNS — it’s about ensuring your infrastructure properly routes DKIM records for public domains. Use tools like the MailTester email checker to test individual addresses and verify DKIM configuration before mass sending.

Real-world example: Fixing DKIM alignment in a newsletter system

A marketing team sent newsletters using a DKIM 'd=' tag pointing to mail.newsletter.com, but their DNS zone only included the root domain newsletter.com. Since mail.newsletter.com wasn’t in the public suffix list (PSL), major inboxes like Gmail and Outlook rejected the DKIM signature as invalid. After using MailTester’s real-time API to diagnose the issue, they updated the DKIM record to use newsletter.com instead. Deliverability improved within 24 hours, with zero further DKIM validation failures.

Step-by-step: Diagnosing and fixing DKIM alignment

  1. Check the DKIM 'd=' tag in the email's header. The sender’s DKIM signature used d=mail.newsletter.com. This is the domain the receiving server uses to look up the DKIM public key in DNS. If the domain doesn’t exist or isn’t in the PSL, the lookup fails. You can find this in the raw email header using tools like MxToolbox or by enabling email logging in your ESP.
  2. Verify the domain in the PSL. Run the domain through a PSL checker. The PSL defines which domains can be used as authoritative zones. mail.newsletter.com is not in the list—only newsletter.com is. This means no valid DNS records can be published for mail.newsletter.com, breaking DKIM alignment. The Public Suffix List is the definitive source for these rules.
  3. Test using a real-time verification tool. They used MailTester’s real-time API to scan a sample of sent emails. The tool flagged the DKIM 'd=' domain as invalid because it was not in the PSL. This confirmed the root cause without guesswork.
  4. Update the DKIM record to use the correct domain. They modified the DKIM record in their DNS zone to use d=newsletter.com. This matches the public zone and passes PSL validation. The record now serves a valid public key under a domain that’s allowed to publish DNS entries.
  5. Monitor post-update deliverability. Within 24 hours, inbox placement reports from MailTester’s inbox placement tester showed no DKIM failures. Major providers like Gmail and Yahoo confirmed alignment. Bounce rates dropped, and open rates rose as messages landed in inboxes.

Why this matters beyond one fix

DKIM alignment failure isn’t just a technical glitch—it’s a signal of weak sender reputation. Inboxes treat unverifiable DKIM signatures as high-risk. If you’re using subdomains for email (like mail.yourbrand.com), make sure they’re in the PSL. Otherwise, your messages will be flagged or filtered. Always test DNS records before launching bulk campaigns. Even small misalignments like this can block delivery at scale.

Pro tip: Always align DKIM d= with your sending domain

You must set the DKIM d= tag to the domain you're sending from—like d=yourcompany.com—and ensure it appears in the Public Suffix List (PSL). Using a subdomain not explicitly allowed in the PSL (e.g., d=mail.yourcompany.com) causes validation failures, even if configured correctly. Always sign with a domain under your control and publicly listed.

Why the d= domain matters

  • DKIM d= specifies the signing domain — it must exactly match the domain in the From: header or mail header domain.
  • Mail receivers validate the d= domain against the Public Suffix List to ensure it's a legitimate, registrable domain.
  • If d= uses a subdomain not in the PSL (like newsletter.yourcompany.com), you’ll likely get a invalid signature error — even if DKIM is technically set up correctly.
  • Use only domains that are publicly known and controllable, such as yourcompany.com or mail.yourcompany.com if the latter is explicitly registered and listed.
  • Subdomains not in the PSL often get flagged during DMARC checks, reducing inbox placement and increasing spam risk.

How to avoid issues in practice

  • Use publicsuffix.org to confirm if a subdomain is recognized in the official PSL before using it in d=.
  • When sending from multiple subdomains (e.g., marketing, support), verify each is listed and valid. Otherwise, sign with the root domain (d=yourcompany.com) unless you’re certain the subdomain is PSL-compliant.
  • Test your DKIM setup using tools like MXToolbox or DNSStuff to catch misconfigurations early.
  • For high-volume senders, verify your entire list with a tool like MailTester's bulk verification — it checks for valid email structures, including DKIM alignment issues at scale.
  • Always verify the alignment of d= and sending domain during setup and after any infrastructure changes.

Summary: Fixing DKIM d= domain issues improves deliverability

The 'DKIM d= domain not in public suffix list' error disrupts validation, even when the domain technically exists. This commonly occurs when a subdomain is used in the d= tag, which violates DNS policy.

Always use only root domains in the d= tag—like example.com, not mail.example.com. Subdomains are not valid public suffixes and cause the signature to fail during verification.

Prevent delivery issues by validating your DKIM configuration. Use tools like MailTester to scan your DNS records and catch errors before they impact sender reputation or inbox placement.

Sources

Keep reading

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

Frequently asked questions

Does DKIM require the d= domain to be in the public suffix list?

Yes. DKIM validation fails if the 'd=' domain is not a valid public suffix, even if it resolves in DNS.

Can I use a subdomain like mail.company.com in my DKIM d= tag?

No — subdomains like 'mail.company.com' are not valid public suffixes. Use 'company.com' instead.

How do I check if a domain is in the public suffix list?

Go to https://publicsuffix.org and search for the domain. If it’s not listed, it can’t be used in DKIM's 'd=' tag.

Why does DKIM require public suffix alignment?

Public suffixes ensure that only domains with DNS authority can sign emails. This prevents spoofing and ensures validation integrity.

Can a domain fail DKIM validation even if its DNS record exists?

Yes. If the 'd=' domain isn't in the PSL, the DNS lookup fails during verification, even if the record exists.

What’s the difference between SPF and DKIM domain alignment?

SPF uses 'v=spf1' with 'from' domains, while DKIM uses 'd=' in the header. Both need proper domain alignment for full validation.

Will MailTester detect all DKIM configuration issues?

It checks for common failures including invalid 'd=' domains, missing DNS records, and PSL compliance, with 98.9% accuracy.

Is it safe to use a domain not in the public suffix list for DKIM?

No. Using such a domain will cause DKIM validation to fail. Use only published public suffixes.

How quickly does fixing the DKIM d= domain show in deliverability?

If only DKIM alignment is the issue, deliverability usually improves within 24 hours after correction.

What happens if I use a non-existent domain in DKIM d= tag?

The signature will fail validation. Even if the domain resolves, it must be in the PSL and have a valid DNS record.

Can DMARC help detect DKIM d= domain issues?

Only indirectly. DMARC reports can show DKIM failures, but only tools like MailTester can identify the root cause, like an invalid 'd=' domain.

Should I check DKIM alignment during email list verification?

Yes. MailTester checks DKIM alignment as part of list verification, flagging domains that fail public suffix validation.