Understanding DKIM Records and Email Authentication
DomainKeys Identified Mail (DKIM) is a foundational email authentication method that allows a domain owner to cryptographically sign outgoing messages. Mail receivers use the sender's public DKIM key, published in the domain's DNS records, to verify the signature. This verification confirms that the email genuinely originated from the claimed domain and that the message content was not altered during transit.
A DKIM record is published as a DNS TXT record containing a specific list of semicolon-separated tags and values. If this record contains formatting errors, weak keys, or unsupported algorithms, receiving mail servers may fail to validate the signature, leading to delivery issues or messages being marked as spam.
Local Record Analysis vs. DNS Queries
The DKIM Record Checker is designed for email domain administrators who have a DKIM TXT record and want to check its format, segmentation, public key presentation, and obvious risks before publishing, as well as those troubleshooting existing DKIM issues.
This tool performs a local record-text check. It processes the pasted record entirely within your browser without querying DNS or verifying actual email signatures. Your DKIM record stays in your browser; BroBroGo does not upload or save it.
Because this is a static text analysis, a clean result does not prove that your live DNS configuration is correct, that your selector is active, or that mail receivers can successfully retrieve the record. It serves as a configuration review rather than delivery proof.
DNS TXT Record Limitations and Chunking
A DNS TXT record can contain several character strings, with each individual string limited to 255 bytes. When a DKIM public key is long—which is common with secure key sizes—the entire record often exceeds this 255-byte limit.
To accommodate this restriction, administrators must split the record into multiple quoted strings within the DNS zone file. DNS servers join these strings in order, meaning all chunks must remain inside one TXT record. The tool accepts and joins quoted TXT chunks and zone-file parentheses up to an input limit of 20,000 characters.
Key Types, Sizes, and Cryptographic Rules
The public key is the core component of a DKIM record, defined by the p tag. The tool recognizes RSA and Ed25519 public keys, validating their Base64 structure and checking for specific cryptographic constraints:
- RSA Keys: RSA is the most common key type. The tool checks the key size to ensure adequate security. RSA keys below 1024 bits are reported as invalid because they are cryptographically vulnerable. RSA keys below 2048 bits are reported as weaker than recommended, as modern standards recommend 2048 bits or more for robust security.
- Ed25519 Keys: This modern elliptic-curve key type is highly secure and compact. The tool validates that the decoded Ed25519 public key is exactly 32 bytes in length.
- Revoked Keys: If the
pvalue is empty (e.g.,p=), it indicates that the public key has been revoked, signaling to receivers that any signatures associated with this selector are no longer valid.
Common DKIM Record Errors and Warnings
When analyzing a pasted record, the tool parses each tag and evaluates it against standard DKIM specifications. Below are the key rules and potential issues identified during analysis:
Version and Key Type Constraints
- Version (
v): Thev=DKIM1tag must be the first tag when it is present in the record. Additionally, the version tag must be exactlyDKIM1, not any other value. - Key Type (
k): The key type tag must specify eitherrsaored25519. Other key types are not supported.
Service and Hash Restrictions
- Services (
s): The service type tag restricts the utility of the key. The value must containemailor*(which represents all services). - Hash Algorithms (
h): The hash tag defines which algorithms are permitted. The record must allowsha256for current DKIM signatures. Conversely,sha1is obsolete for DKIM signatures and must not be used due to security vulnerabilities.
Syntax and Structural Issues
- Missing Public Key: The required
ppublic-key tag must be present unless the key is intentionally revoked. - Duplicate Tags: Each tag (such as
v,k, orp) must appear only once in the record. - Malformed Fields: Every field must contain an equals sign separating the tag name from its value, and the tag names must conform to valid alphanumeric formats.
Parsed Fields and Output Structure
When you paste a record and run the check, the tool generates a structured breakdown of the record:
- DKIM summary: Displays the parsed Version, Key type, Key size, and allowed Services.
- Parsed fields: A table showing each Tag alongside its corresponding Value.
- Record notes: Displays technical details such as the number of TXT chunks, whether a value is a Default or a Revoked key, or if the key size is Unknown.
- Validation Status: If the record is clean, the tool displays: "No record error or key warning was found in the pasted value.". Otherwise, it provides a summary line: "Checked
‹fields›fields:‹errors›errors and‹warnings›warnings." along with specific error messages.
Frequently Asked Questions
Why are long DKIM records split into quoted strings?
A DNS TXT record can contain several character strings, with each string limited to 255 bytes. DNS joins the strings in order, so all chunks must remain inside one TXT record.
Which DKIM key types does this checker recognize?
It recognizes RSA and Ed25519 public keys, checks their Base64 form, and reports RSA keys below 1024 bits as invalid and keys below 2048 bits as weaker than recommended.
Does a clean result prove DKIM is working?
No. This page checks only the record text you paste. It does not query DNS, verify a message signature, confirm the selector name or prove that mail receivers can retrieve the record.
What does an empty "p" tag mean in a DKIM record?
An empty p value publishes a revoked DKIM key. This tells receiving mail servers that the key is no longer active and any emails signed with it should not be validated.