DKIM Record Check: What You Can Prove From Outside, And What You Cannot.

Short answer: a dkim record check from outside means guessing selector names and asking DNS about each one. DNS cannot list what exists under _domainkey, so you can confirm a selector is present and you can never prove none exists. That limitation is worth understanding before you report a finding to a client.

I ran it across four domains POSIMYTH owns, and the most useful result was our own.

What came back

real gap rather than a probing artefact worth shrugging at.*

Domain	Selectors found	What it tells you
posimyth.com	default, mail, s1, s2	s1/s2 are CNAMEs delegated to SendGrid
uichemy.com	google	Google Workspace DKIM enabled and publishing
theplusaddons.com	default	one key published
protuno.com	none found	MX on Google Workspace, DMARC p=reject, no key on any of 24 names

Caveat: 24 selector names, four domains. Finding nothing on protuno.com is not proof no key exists anywhere, only that none of the 24 most common provider selectors answered. That limitation is the entire subject of the next section, and it is why this finding needs the DMARC report confirmation described below before you’d stake anything on it.

protuno.com enforces DMARC at p=reject. Its mail runs through Google Workspace. And no key answered on any of the twenty-four names I tried, including google, which is the selector Workspace uses.

With no DKIM, DMARC has only SPF to align against. SPF breaks whenever a message is forwarded, because the forwarding server is not in the sending domain’s SPF record. So p=reject with SPF-only alignment is the configuration most likely to destroy legitimate forwarded mail.

That one is going on our list rather than into a footnote.

Checked again, with a wider list, and it is still there

I re-ran the full probe against all four domains before expanding this post, rather than let the original screenshot stand as the last word on something worth staying honest about.

for s in google selector1 selector2 default mail dkim k1 k2 s1 s2 zmail pm mandrill smtp pic zoho; do
  dig +short TXT "$s._domainkey.protuno.com"
  dig +short CNAME "$s._domainkey.protuno.com"
done

posimyth.com, uichemy.com and theplusaddons.com matched their original results exactly, no drift, same selectors answering the same way. protuno.com matched too, in the direction that matters: still nothing, across the same sixteen names that returned nothing the first time.

Given how load-bearing “no DKIM on a p=reject domain” is as a claim, I extended the probe past the original list before accepting the result, adding names this post had not tried: amazonses, mimecast, everlytickey1 and everlytickey2 for SparkPost, scph200524 for Sendinblue, fm1 through fm3, mailchannels, resend, and a handful of dated and numbered variants providers sometimes use. Thirty-seven selector names in total, across both TXT and CNAME record types.

Nothing. The finding holds under a substantially wider probe than the one that originally produced it, which is the closest an external check can come to confirming a negative result without server access, still short of proof, but considerably more load-bearing than the first pass alone.

_dmarc.protuno.com still reads v=DMARC1; p=reject; rua=mailto:[email protected], and MX still points at smtp.google.com. Every condition that made this a real, current risk when the post first published is unchanged. This is one of the small number of findings on this blog where re-checking did not turn up a fix quietly applied since. It turned up the same gap, confirmed twice, on infrastructure I have direct reason to care about.

Why absence is not proof

which is the practical ceiling on any external mail audit, ours included.*

What you want to ask	Possible?	Why
“list everything under _domainkey“	no	DNS answers questions about specific names only
“does selector X exist?”	yes	dig TXT X._domainkey.domain
“which selector signed this message?”	yes	read the s= tag in the DKIM-Signature header
“are all senders signing?”	indirectly	only from DMARC aggregate reports

This matters when you write it up. “No DKIM record found” and “this domain has no DKIM” are different claims, and only the first one is supportable from a probe.

The definitive answers come from two places, and both need a real message to exist:

• A message header. Send yourself mail from the domain and read the s= tag in the

DKIM-Signature header. That names the selector that actually signed it.

• DMARC aggregate reports. These list every sending source and whether it aligned on SPF, on

DKIM, or on neither. This is the only view that covers senders you forgot about, which is why rua is the tag you should never omit.

Checking key strength, not just key presence

Finding a selector answers “is something published.” It does not answer “is what’s published still good enough,” and that second question is worth asking once you have found a key rather than stopping at presence. I decoded the actual RSA public key from each of the four selectors this post found and read its length.

dig +short TXT default._domainkey.posimyth.com \
  | grep -oP '(?<=p=)[^;"]+' | base64 -d \
  | openssl rsa -pubin -inform DER -noout -text | head -1

Domain, selector	Key size
posimyth.com, default	1024 bit
posimyth.com, mail	1024 bit
theplusaddons.com, default	1024 bit
uichemy.com, google	2048 bit

Three of our four active keys are 1024-bit RSA. The fourth, uichemy.com‘s, is 2048-bit, because Google Workspace generates 2048-bit keys by default when a domain enables DKIM through its admin console rather than through an older, third-party mail provider’s own defaults.

1024-bit RSA is not broken in any practical sense today, and a working 1024-bit key still signs mail that authenticates correctly right now. It is, however, below the 2048-bit floor most current DKIM guidance recommends, and it is the kind of gap that does not announce itself: DMARC alignment succeeds either way, mail delivers either way, and nothing about day-to-day operation distinguishes a 1024-bit key from a 2048-bit one until a receiving provider decides to stop trusting the shorter one, at which point every message signed with it starts failing alignment simultaneously, with the same “worked yesterday, mysteriously fails today” shape as a certificate renewal that silently stopped.

The practical addition to this post’s audit, once a selector is found: decode the key and check its length alongside checking that p= is non-empty. A key that exists and signs correctly today can still be quietly due for rotation, and the three 1024-bit keys found across our own small portfolio here are now on that list, not because anything is currently failing, but because the newest and best-configured provider in the same portfolio, Google Workspace, has already moved past that length by default.

Running a DKIM record check, selector by selector

deliberate, so they can rotate keys without asking you to edit DNS. Probe both record types or you will miss half of them.*

The loop itself:

D=example.com
for s in google selector1 selector2 default mail dkim k1 k2 s1 s2 zmail pm; do
  t=$(dig +short TXT "$s._domainkey.$D" | head -1)
  c=$(dig +short CNAME "$s._domainkey.$D" | head -1)
  [ -n "$t" ] && echo "  TXT   $s"
  [ -n "$c" ] && echo "  CNAME $s -> $c"
done

One thing to check when you do find a key: the p= value should not be empty. A record like v=DKIM1; p= is a revoked key. It is published, it looks like a configuration, and it signs nothing.

Where this sits in a mail audit

DKIM is the half of alignment that survives forwarding, which is why it is worth the extra hour even on domains where SPF is already correct. Client mail gets forwarded constantly, to personal addresses, aliases and shared inboxes, and SPF fails every one of those hops.

The three checks belong together and take about five minutes for a whole portfolio: the SPF record and whether it has drifted past its lookup limit, the DMARC policy and its pct, and a selector probe.

Protuno’s free audit runs a DKIM selector probe alongside the SPF and DMARC checks, from the domain alone, with the same honest caveat as above about what a probe can and cannot establish. Straight with you as on every post here: Echo, the Marketing agent that would keep this current, is built and named but not live yet.

It is also worth confirming the site itself can send at all before blaming alignment. A perfectly signed domain still delivers nothing if the form quietly throws the message away.

Run the loop against your own domain first. That is where I found the one that mattered.

What fixing the protuno.com gap will actually require

I am not going to claim this is fixed, because it is not, and the honest version of this post includes what the fix actually looks like rather than only the finding. Enabling DKIM on a Google Workspace domain is a deliberate step inside the admin console, not something that turns on by default alongside MX records pointing at Google’s mail servers. An administrator has to open Apps, then Google Workspace, then Gmail, then Authenticate Email, generate a new DKIM key specifically, and then publish the TXT record it produces at the google._domainkey name this post already probed.

That last part is the step worth naming precisely, because it is where a check like this one earns its cost back: Workspace will not activate the key until it can see the DNS record it generated actually published and resolving, so the whole process is self-verifying in a way the WooCommerce REST API’s own defaults are but many DNS-dependent configurations are not. The record either resolves and the key activates, or it does not and Workspace tells you plainly rather than silently accepting a half-finished setup.

None of that is difficult. It is fifteen minutes in an admin console followed by one DNS record, which is a smaller job than most of the fixes described elsewhere on this blog. What makes it worth writing about at this length is not the difficulty of the fix, it is that a domain enforcing p=reject, the strictest DMARC policy that exists, has been running without the one authentication mechanism that survives the most common way legitimate mail actually breaks, forwarding, for as long as this post has been live to say so. The gap between “this is trivial to fix” and “this has not been fixed” is not a technical gap. It is the same fifteen minutes every other unbilled, invisible check on this blog competes against on a Tuesday, and losing.

Why 2048-bit landed as the default without anyone deciding it should

Worth being precise about one more thing before closing this out: none of the four domains in this post’s table have a documented internal decision that says “our DKIM keys should be 1024-bit” or “our DKIM keys should be 2048-bit.” The key length each domain ended up with is purely a function of which provider generated it and when. Google Workspace’s current key generation defaults to 2048-bit. Whatever generated the three 1024-bit keys, most likely an older SendGrid or generic SMTP provider default from whenever those records were first set up, defaulted to the shorter length at the time, and nobody has gone back to regenerate them since, because a working key gives no visible reason to.

That is worth naming as its own small pattern, distinct from every other finding in this post: infrastructure inherits its defaults from whichever tool touched it last, not from a decision anyone actually made, and a portfolio built up over years accumulates a genuinely inconsistent set of standards purely as a side effect of which provider happened to be in use each time a piece of it was configured. Auditing for that kind of drift, not just for outright absence, is a different and quieter category of check than most of what this blog covers, and it is worth adding to the same quarterly pass as the selector probe itself.