Free account

Keep your requests in reach

Create an account in under 30 seconds to keep 6 months of history, share saved requests, and trigger email or webhook alerts on every diff.

  • 6-month searchable history
  • Diff alerts via email & webhook
  • Latency spike monitoring
Create account

DKIM syntax checker

Understand how DKIM syntax works

DomainKeys Identified Mail (DKIM) adds a digital signature to outbound mail so that the recipient can prove it really comes from your infrastructure. The public key that enables verification lives inside a TXT record. This page explains how to read the syntax and how the checker interprets the fields returned by the API.

What sits inside a DKIM TXT record?

A DKIM record is a semicolon-separated list of tags. Each tag has a short name followed by an equals sign and its value. The validator trims whitespace, ignores the order, and tolerates folded lines as long as the syntax stays consistent.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Mandatory tags you must publish

  • v - the version indicator. DKIM1 is currently the only supported value.
  • k - the key type. RSA keys (rsa) remain the de facto standard. Ed25519 (ed25519) is emerging but still rare.
  • p - the base64 public key material. Removing whitespace and extra quotes is mandatory before publishing.

If any of these tags is missing, empty, or malformed, the signature cannot be validated. The tool highlights the exact issue, so you can regenerate the key or fix your DNS entry.

Optional tags that refine behaviour

  • h limits the hash algorithms that can verify the signature (sha256 is recommended, sha1 is deprecated).
  • t toggles flags such as y (test mode) or s (strict alignment on the selector name).
  • s defines the list of services for which this key is valid. Leaving it empty defaults to email.
  • g scopes the key to a specific user or sub-address when necessary.
  • n lets you leave operator notes for diagnostics.

You can omit any of these tags when you rely on defaults. The checker still exposes them in the “Record details” block if they exist, so you can verify what will be returned over DNS.

Common syntax pitfalls the validator detects

  1. Quoted values copied from DNS providers. Remove surrounding quotes and line breaks before submitting the record.
  2. Accidental smart quotes or extra semicolons. The parser expects ASCII quotes and a single ; separator between tags.
  3. Whitespace-only tags. Blank values are treated as empty and will cause warnings or errors depending on the field.
  4. Mixing different versions or key types. Stick to v=DKIM1 and one key type per record.
  5. Truncated public keys. Make sure the base64 block was not cut during copy/paste or by record length limits.

Each diagnostic returned by the API is mapped to the badge at the top of the results. Errors mean the record cannot be used; warnings flag risky but technically valid setups.

What the validator checks

  • Record shape — empty values, dangling quotes or malformed tag separators raise errors (empty_record, record_trailing_quote, invalid_tag_syntax).
  • Version and key type — missing or unsupported v/k tags (missing_version_tag, unsupported_version, missing_key_type, unsupported_key_type) block the record.
  • Public key integrity — absent or malformed p values (missing_p_tag, empty_p_tag, invalid_p_base64, public_key_parse_error) are surfaced explicitly.
  • Optional tags — the checker flags duplicate or unknown tags, restricted granularities (g=), deprecated or unknown hash algorithms, and weak key lengths below 2048 bits.
  • Selector resolution — upstream lookups without TXT, without DKIM data, or with CNAME answers generate lookup_no_txt, lookup_no_dkim, lookup_multiple_dkim and lookup_cname_alias diagnostics so you know which selectors need attention.

Good practices before publishing the record

  • Generate the key pair from a trusted server or your mail provider and store the private part securely.
  • Keep the selector name short and unique so that rotations are easier (selector2024._domainkey.example.com).
  • Set a TTL that matches your rotation policy. Shorter TTLs ease emergency revocations; longer TTLs limit DNS traffic once stable.
  • Document who owns the selector and when it was last rotated.

Running the syntax checker with the final value ensures the TXT record will parse correctly once published. Combine it with a DNS lookup to double-check propagation and with DMARC reports to monitor long-term signing quality.