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.

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.