Fixing DKIM Public Key Not Available: DNS Selector and Syntax Troubleshooting

DomainKeys Identified Mail (DKIM), standardized in RFC 6376, provides cryptographic authentication for email messages. When an outgoing mail server sends a message, it calculates a digital signature across designated header fields and the message body hash using an asymmetric private key, embedding the result in the DKIM-Signature: header. Receiving Mail Transfer Agents (MTAs) extract the selector and domain name, fetch the corresponding public key from a DNS TXT record, and verify the cryptographic signature.

When a receiving server fails to retrieve the key, it logs authentication results such as dkim=temperror (key not available) or dkim=permerror (no key for signature). Under strict DMARC policies (p=reject or p=quarantine), this failure causes legitimate corporate communications to be discarded or routed into spam filters.

The DKIM DNS Lookup Namespace (RFC 6376 Section 3.6.2)

DKIM segregates public keys into a dedicated DNS namespace using selectors. The fully qualified domain name (FQDN) for a DKIM record is structured strictly as:

<selector>._domainkey.<domain.com>

The label _domainkey is a reserved literal prefix required by RFC 6376. The <selector> is an arbitrary string chosen by the sending mail system (e.g., google, k1, s202610, smtp). This allows a single organization to support multiple sending vendors, distinct departmental mail streams, and seamless key rotation simultaneously without namespace collisions.

Error Classification: PermError vs TempError

Cause 1: The Double-Domain Appending Bug

The single most common mistake when adding DKIM records occurs in registrar DNS dashboards like GoDaddy, Namecheap, and cPanel. Many management interfaces automatically append your root domain to whatever text you type in the 'Host' or 'Name' field.

If your email vendor instructs you to create a record for k1._domainkey.example.com, and you paste that entire string into the Host input field, the provider may publish k1._domainkey.example.com.example.com. Receiving MTAs querying k1._domainkey.example.com receive NXDOMAIN, resulting in dkim=permerror (no key for signature).

Cause 2: 2048-Bit RSA Key Truncation (The 255-Octet Limit)

In accordance with standard DNS protocol rules in RFC 1035 Section 3.3.14, a single text string within a TXT record cannot exceed 255 octets (bytes). A secure 2048-bit RSA public key, when encoded in Base64, requires approximately 392 characters—far exceeding the single-string limit.

RFC 4408 and RFC 6376 specify that longer records must be split into multiple contiguous strings enclosed in parentheses. Compliant recursive resolvers concatenate these contiguous strings in memory before decoding:

k1._domainkey.example.com. IN TXT (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzV5L"
    "3jVq8wFq8zYyK3mN7bQ8xL1w9...[rest of 392-character key]...IDQAB" )

Older DNS hosting web interfaces fail to handle multi-string concatenation. When users paste a 392-character string into a single form input, the software silently truncates the key at character 255. When a receiving MTA attempts to decode the truncated base64 string, RSA key parsing fails.

Cause 3: Malformed Syntax and Missing Tags

RFC 6376 Section 3.6.1 establishes strict syntax rules for DKIM TXT records:

• v=DKIM1;: The version tag. It must appear first if present, and must be uppercase. If a record begins with lowercase v=dkim1;, some strict mail receivers will reject it.
• k=rsa;: The key type tag. Defaults to RSA if omitted. Modern deployments also support k=ed25519; for elliptic curve cryptography.
• p=<base64>: The public key data. If the p= tag is completely empty (p=;), RFC 6376 explicitly defines this as a revoked key. An empty public key instructs mail servers that the selector has been permanently compromised or retired.

Direct Command-Line Verification Workflow

To determine why receiving servers cannot retrieve your public key, perform direct CLI inspection using dig and OpenSSL:

# 1. Query the exact selector FQDN:
$ dig TXT k1._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzV..."

# 2. Check if double-domain bug occurred:
$ dig TXT k1._domainkey.example.com.example.com +short

# 3. Validate base64 structure using OpenSSL:
$ echo "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzV..." | base64 -d | openssl rsa -pubin -inform DER -text -noout

OpenDKIM and Postfix MTA Configuration and Local Key Validation

For self-hosted Linux mail servers running Postfix or Exim with OpenDKIM, 'key not available' errors frequently originate from mismatched permissions or misconfigured table references between the local filesystem and the DNS namespace.

# /etc/opendkim/KeyTable format: <key-name> <domain>:<selector>:<path-to-private-key>
k1._domainkey.example.com example.com:k1:/etc/opendkim/keys/example.com/k1.private

# /etc/opendkim/SigningTable format: <sender-pattern> <key-name>
*@example.com k1._domainkey.example.com

# File permissions must restrict read access strictly to opendkim user:
# chown -R opendkim:opendkim /etc/opendkim/keys
# chmod 600 /etc/opendkim/keys/example.com/k1.private

Before relying on external email delivery tests, use the OpenDKIM key testing utility directly on your mail server. It queries public DNS resolvers and compares the cryptographic public key discovered in DNS against your local private key:

$ opendkim-testkey -d example.com -s k1 -k /etc/opendkim/keys/example.com/k1.private -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'k1._domainkey.example.com'
opendkim-testkey: key secure
opendkim-testkey: key OK

If opendkim-testkey returns key not secure, DNSSEC is not protecting your zone (which is non-fatal for basic delivery), but if it returns key not found or query failed, your DNS authoritative server is dropping queries or responding with NXDOMAIN.

SaaS Email Services: CNAME Delegation Chains and Key Flattening

When sending transactional email through third-party services like SendGrid, Mailgun, or Amazon SES, providers instruct you to create CNAME records rather than direct TXT records. For instance, s1._domainkey.example.com points to s1.domainkey.u123456.wl.sendgrid.net.

Under RFC 1034 Section 3.6.2, when a resolver queries a CNAME, it restarts the lookup using the canonical name target. However, if your DNS management provider enforces CNAME flattening at subdomains or your intermediate DNS zone fails to sign the delegation, receiving mail servers will fail to retrieve the public key. Always trace the complete CNAME chain with dig CNAME +trace to verify that every intermediate canonical name resolves cleanly.

Check your result and continue troubleshooting

Use the dkim lookup tool to inspect the public DNS data relevant to this guide. Record the hostname, query type, resolver and time so you can compare results after a change. This is a DNS check, not a guarantee of worldwide propagation or successful application delivery.

For the underlying behavior and current configuration guidance, consult the official reference. Provider dashboards can change; use the values shown for your own domain rather than copying an example into production.