Last updated: July 2026
In short: A DKIM key record is a DNS TXT record that publishes your public key along with protocol control tags (
v=,k=,p=,s=, andt=). These parameters tell receiving mail servers how to process and validate your cryptographic signatures.
To enable receiving servers to verify a DomainKeys Identified Mail (DKIM) signature, a domain must publish its public key in DNS. This entry is published as a TXT record under the subdomain <selector>._domainkey.<domain> and consists of a semicolon-separated list of tag=value pairs.
A standard DKIM key record looks like this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Core tags explained
According to RFC 6376, each tag defines a specific operational property of the published key:
The version tag (v=)
The v= tag declares the version of the DKIM key record (v= Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1")).
If specified, this tag must be set to DKIM1 and must be positioned at the very beginning of the string. Under RFC 6376: “If specified, this tag MUST be set to "DKIM1" (without the quotes). This tag MUST be the first tag in the record. Records beginning with a "v=" tag with any other value MUST be discarded.”
The key type tag (k=)
The k= tag identifies the cryptographic algorithm used to generate the key (k= Key type (plain-text; OPTIONAL, default is "rsa")).
If omitted, receiving servers assume the default rsa algorithm. The standard mandates broad compatibility across all implementations: “Signers and Verifiers MUST support the "rsa" key type.”
The public key data tag (p=)
The p= tag carries the actual base64-encoded public key (p= Public-key data (base64; REQUIRED)).
A critical feature of this tag is key revocation: when published with an empty value (An empty value means that this public key has been revoked.), it instructs verifiers that the key is permanently compromised or retired and must not be treated as valid. A revoked key record is published as:
v=DKIM1; p=
The service type tag (s=)
The optional s= tag restricts the scope of the key (s= Service Type (plain-text; OPTIONAL; default is "*")). It accepts a colon-separated list of service types to which the record applies. To restrict a public key so that it is only valid for email authentication, set s=email:
v=DKIM1; k=rsa; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
The flags tag (t=)
The t= tag holds operational flags (t= Flags, represented as a colon-separated list of names (plain-text; OPTIONAL, default is no flags set)). If a verifier encounters unrecognized flags, the standard requires them to be ignored (Unrecognized flags MUST be ignored.).
During initial deployment, administrators often use the y flag to enable testing mode (y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify.). A testing record looks like:
v=DKIM1; k=rsa; t=y; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Verifying your configuration
To check whether your tags are formatted cleanly and confirm that your base64 public key parses without truncation, inspect your domain using the free MXAudit scanner.
For more technical guidance on key management and provider-specific configurations, explore the DKIM hub and practical walkthroughs like IONOS DKIM setup.
Further reading
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures (retrieved: July 16, 2026)