Truvo Free Tools

DKIM record checker

DKIM lets receiving mail servers verify that a message was signed by a key your domain published in DNS. This checker looks up the public key at selector._domainkey.yourdomain.com, validates the record and the key, flags weak or revoked keys and test mode, and names the SOC 2 and ISO 27001 controls the result affects.

SOC 2 CC6.1SOC 2 CC6.7SOC 2 CC7.2ISO 27001 A.5.14ISO 27001 A.8.20
Ali Aleali

Ali Aleali, CISSP, CCSP

Co-Founder & Principal Consultant

Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure. These tools come out of that work.

Connect on LinkedIn

How the DKIM record checker works

The check is passive: it reads the public TXT record at selector._domainkey.yourdomain.com through DNS over HTTPS, without sending any email.

01

Query

You enter a domain and a selector. The tool asks a public DNS over HTTPS resolver for the TXT record at ._domainkey., following one CNAME hop when a provider delegates the selector. Nothing is sent to your mail servers.

02

Validate

The record is parsed tag by tag: v=DKIM1, the key type in k, the public key in p, and the flags in t. The key is decoded to confirm it is a real RSA or Ed25519 key and to measure its length. Empty p (revoked), keys under 2048 bits, and the t=y test flag are flagged.

03

Map

Each finding names the controls it speaks to: SOC 2 CC6.1, CC6.7 and CC7.2, and ISO 27001:2022 A.5.14 (information transfer) and A.8.20 (networks security). A valid 2048-bit key with no test flag is evidence; a missing or weak key is a gap to close.

Weak or missing DKIM? We fix it for you.

Truvo's security engineers set up signing, rotate keys, tighten DMARC and hand you the evidence an auditor asks for. Tell us the domain and we will scope the fix.

Contact us

  • DKIM signing and rotation

  • SPF under 10 lookups

  • DMARC to reject

  • Report monitoring

  • Audit evidence

  • Fixed-price scope

DKIM checker: frequently asked questions

A selector is the label in front of ._domainkey in the DNS name, and it lets one domain publish several keys at once. Every signed message names its selector in the s= tag of the DKIM-Signature header, so open a message you sent and read it from there. Common defaults are google for Google Workspace, selector1 and selector2 for Microsoft 365, and k1 for Mailchimp.

It looks up the TXT record at ._domainkey., confirms it carries v=DKIM1, decodes the public key in the p tag, measures the key length, and reads the flags. It reports a missing record, a revoked key (empty p), a key shorter than 2048 bits, and the t=y test flag that tells receivers to treat signatures as unsigned.

Usually the selector is wrong. The record only exists at the exact selector name your sending platform uses, so check the s= tag in a real message header. Some platforms also publish the key behind a CNAME; the checker follows one hop, but a broken CNAME target will still show as missing.

It verifies, but RFC 8301 recommends 2048 bits and several receivers and auditors treat 1024 as weak. Rotate by publishing a new selector with a 2048-bit key, switching signing to it, then retiring the old one. The DKIM record generator on this site builds the new key pair in your browser.

Truvo maps DKIM findings to SOC 2 CC6.1, CC6.7 and CC7.2, and to ISO 27001:2022 Annex A controls A.5.14 (information transfer) and A.8.20 (networks security). The mapping is advisory: it shows which control a finding gives evidence for or signals a gap against. It is not a substitute for an audit.

DomainKeys Identified Mail, defined in RFC 6376, signs outbound messages with a private key and publishes the matching public key in DNS at selector._domainkey.yourdomain.com. Receiving servers verify the signature, which proves the message came from a system holding your key and was not altered in transit. Unlike SPF, the signature survives forwarding, which is why DMARC at reject usually relies on DKIM.