This chapter explains what a DNS record can tell you, which details you need from an actual message, and how to assess selectors, key changes and failed verification.
What DKIM can establish
DomainKeys Identified Mail associates a signature with the domain in the d= parameter. The s= parameter identifies the selector under which the recipient looks for the matching public key. Together, these two values form the key's DNS name.
A successful DKIM verification applies to the signed header fields and the covered message body. Canonicalisation rules apply: depending on the chosen method, certain changes in the representation of whitespace may be harmless. Unsigned header fields and any uncovered part of the body are not protected by this signature.
On narrow screens, scroll the table sideways.
| What is examined | What it can tell you |
|---|---|
A message's d= and s= | Which signing domain and selector are used for this signature. |
| Public DNS key | Which key is published at the queried name at the time of retrieval. |
| Successful signature verification | The checked signature is valid for the covered message parts under the DKIM rules applied. |
DKIM does not confirm a natural person's identity or their business authority. A valid signature does not establish that the content is harmless. It does not encrypt a message either. A compromised signing environment can continue to create valid signatures for its domain.
The visible From: domain need not be identical to d=. DMARC checks this relationship through alignment. In general, a successful aligned SPF path or a successful aligned DKIM signature is sufficient for a DMARC pass. Operating with p=reject involves stricter requirements, explained separately in the DMARC chapter.
From the private key to verification at the recipient
Schematic explanation · not a measurement
Sign at the sender, verify at the recipient
- Sending service · sign: The sending service prepares the header fields to be signed and the message body according to the chosen canonicalisation rules. It creates the DKIM signature using the private key.
- Sending service · send: The message receives a
DKIM-Signatureheader field. This includes the signing domaind=, selectors=, algorithm and signature data. - Recipient · query the key in DNS: The recipient combines
s=andd=to form the name under_domainkey, then queries DNS for the public key. Withs=mail202609andd=example.com, the name ismail202609._domainkey.example.com. - Recipient · verify: The recipient checks, among other things, syntax, a usable key, the body hash and the signature. Only this evaluation can confirm a valid signature. DNS or configuration errors are other possible outcomes.
Canonicalisation and the message parts covered limit the conclusion. A DNS finding does not prove a valid signature. This is not an email tested here. The private key stays with the sender; DNS is used to retrieve the public key.
Without DKIM, this signature evidence is absent. SPF and other receiving checks remain possible, and an aligned SPF pass can satisfy the general DMARC pass criterion. With DKIM, a signature may survive forwarding if the relevant message parts are preserved under the chosen canonicalisation. Unlike SPF, this check does not depend on authorising the current connecting IP address. This does not mean that a forwarded message automatically passes DKIM or DMARC.
The technical foundations are described in RFC 6376, sections 3 and 6.
RSA, Ed25519 and DNS record size
For RSA, the standard distinguishes a minimum requirement from a recommendation. RFC 8301 requires signers to use at least 1024 bits and recommends at least 2048 bits. Verifiers must support keys from 1024 to 4096 bits. A local recipient may impose additional requirements on accepted signatures.
On narrow screens, scroll the table sideways.
| Key type | Protocol status | Practical interpretation |
|---|---|---|
| RSA 1024 bits | Minimum size under RFC 8301 | Less security margin than larger RSA keys; consider moving to at least 2048 bits. Do not automatically equate this size with “already broken”. |
| RSA 2048 bits | Meets the recommendation of at least 2048 bits | A suitable starting point if the sending service and DNS administration support it. |
| RSA 4096 bits | Verification of this size is required | A larger key and DNS record; the higher number alone does not make it necessary for every service. |
| Ed25519 | Additional algorithm under RFC 8463 | A separate algorithm with short keys; its bit count is not directly comparable with RSA. |
Signatures using RSA keys shorter than 1024 bits must not be considered valid. rsa-sha1 must be used for neither signing nor verification. The RSA requirements are set out in RFC 8301, section 3.
Ed25519 needs the correct format and operational support
RFC 8463 adds ed25519-sha256. In the public key record, k=ed25519 identifies the type. Its p= value contains the 32 raw key bytes encoded as Base64, giving 44 characters. An ASN.1/SPKI wrapper does not belong in this value for this algorithm.
The standard requires Ed25519 support in verifiers and recommends it for signers. What a specific installation offers still depends on its software, version, cryptographic library and sending service. Publishing an Ed25519 key does not confirm that outgoing messages are signed with it.
If your service supports several signatures, it can use RSA and Ed25519 with different selectors. Two DNS keys alone do not prove this dual signing. Check the signatures actually produced on a message.
Long TXT values are not separate key records
A DNS TXT record can contain several character strings of up to 255 bytes each. DKIM joins them without additional spaces. This matters for longer RSA keys, including common 2048-bit configurations. Do not turn these strings into separate key records.
Publish only the public value generated for DNS by your signer or provider. A private key belongs neither in DNS nor in a public check report.
Find selectors and change keys
A selector is a name for a key within a signing domain. Several selectors may represent different sending services, an old key or a planned change. Their number alone does not prove regular rotation.
For a particular message, read s= and d= together from DKIM-Signature. A typical provider name or the visible sender alone is not enough to derive the correct DNS name.
Examples from provider documentation
This table offers orientation, not a complete setup template. Documentation checked: 12 September 2026. Obtain the current values from the administration interface of the product actually in use.
On narrow screens, scroll the table sideways.
| Service | Documented selectors | DNS record | Limit |
|---|---|---|---|
| Microsoft 365 | selector1, selector2 | CNAME | Use the target values from your own configuration; different target name formats exist. |
| Google Workspace | google or a chosen prefix | TXT | The Admin Console supplies the value generated for the domain. |
| IONOS | s1-ionos, s2-ionos, s42582890 | CNAME | The source concerns IONOS mailboxes; it specifies the same three records for externally managed DNS. |
| STRATO | strato-dkim-0002, strato-dkim-0003 | CNAME | The provider notes that selectors may change. |
| Netcup Webhosting | key1, key2 | CNAME | Both documented records belong to this product; the source excludes alternative routes such as external SMTP sending or mail sent by the web server. |
| Your own signer | A name of your choice, such as mail202609 | TXT | Operate and document key use and rotation yourself. |
Operational procedure · no fixed waiting period
Planned rotation with overlap
During a regular rotation, the previous public key should initially remain retrievable for messages still in transit. The selector rules in RFC 6376 allow this transition.
- Generate a new key. Use a new selector, such as
mail202609, instead of overwriting the existing name with a different key. - Publish the new public key. Account for existing DNS cache lifetimes and any cached negative responses for the new name.
- Switch the signer. Enable signing with the new private key and selector. A DNS record does not reconfigure the mail server by itself.
- Check the transition. Use outgoing messages to establish which selector is used. Retain the old public key for messages still in transit. The period depends on your operation and its delays, not on a universal calendar interval.
- Retire the old key. An empty
p=value, such asv=DKIM1; p=, indicates revocation. Removing the key record also prevents successful verification with that key; DNS caches may delay the change.
Why DKIM verification can fail
DKIM is calculated over defined message parts, not over the meaning of text visible to a person. Two messages can look the same in a mail client yet contain different signed bytes. Conversely, the selected canonicalisation rules can accommodate certain whitespace changes.
On narrow screens, scroll the table sideways.
| Change in transit | When it matters to the signature |
|---|---|
| Appending a footer or disclaimer | If the change alters the signed body after canonicalisation. An l= value can limit the covered body; a valid result then does not automatically authenticate content appended later. |
Adding [LISTNAME], [SPAM] or [EXTERN] to the subject | If the affected Subject field is signed. relaxed does not simply undo a change to the subject's content. |
| Rewriting URLs | If a rewritten URL is part of the signed body and changes it under canonicalisation. |
| Changing character set or MIME encoding | If, for example, re-encoding between UTF-8 and ISO-8859-1 changes the covered bytes; the same visible text is not enough. |
| Rewrapping lines | If the change is not accommodated by the chosen canonicalisation. Message lines are also subject to the RFC 5322 format limit: no more than 998 characters, excluding the terminating CRLF. |
Canonicalisation is described in RFC 6376, section 3.4; line length in RFC 5322, section 2.1.1.
Investigating “body hash did not verify”
This finding means that the verifier's calculated body hash does not match the value in bh=. It is not merely a sign of a missing DNS key. First check whether the message being examined is complete and in its original form. Then compare the processing steps after signing: footers, URL rewriting, MIME conversion and canonicalisation are possible starting points. The error message alone does not prove which service caused the change. RFC 6376, section 6.1.3
Sign your own outgoing messages after the content changes you intend to make. If a gateway changes other parties' messages, it should check existing authentication first. ARC can document earlier authentication results across intermediaries. ARC does not repair an invalid DKIM signature or oblige the final recipient to accept the message.
Check DNS configuration and the message separately
- Identify the signature details. Read the signing domain
d=, selectors=and algorithma=from a specific message. Examine each signature separately if there are several. - Query the exact key. For the example combination
s=mail202609andd=example.com, a DNS query is:
dig TXT mail202609._domainkey.example.com- Interpret the response. Distinguish a published key, a CNAME reference, a missing record and a temporary DNS error. Check whether the key material matches the specified algorithm. This command is only an unexecuted read example here.
- Trace the signature verification. You need the actual message and a suitable verifier, or the result from a trusted receiving system. An arbitrary
Authentication-Resultsheader of uncertain origin is insufficient. The section on header findings explains this trust boundary. - Assess DMARC separately. Only once a signature passes, check the alignment of its
d=domain with the visibleFrom:domain. A DKIM pass for an unaligned domain does not provide a DMARC pass by itself.
The Email Security Check examines publicly accessible DNS configuration. Its finding may suffice for the initial question about a known selector. It does not confirm a real message's signature, regular key rotation or complete coverage of all selectors or sending services.
DKIM as a documented technical measure
Document which service signs with which domain, who protects the private key, and who is responsible for DNS and rotation. These operational details differ from a single DNS finding. They help make changes and handovers traceable.
The following legal references concern Germany and the EU:
- Germany: section 30 BSIG requires appropriate and proportionate risk management measures for entities in scope, including the use of cryptography. A DKIM key alone neither meets nor demonstrates these requirements; the provision does not impose DKIM on every domain.
- Technical guidelines: BSI TR-03182 concerns email authentication. The complementary TR-03108 concerns secure email transport. A DKIM signature does not demonstrate conformity with an entire guideline.
- European Union: Article 32 GDPR requires technical and organisational measures appropriate to the risk. DKIM can make a limited contribution to integrity and authentication; it replaces neither confidentiality protection nor access controls.
Successful DKIM verification is not a certificate, proof of compliance or a delivery promise.
The sections on email spoofing and phishing explain further attack routes. A valid signature does not replace assessment of the content.
A guide for your signing service
The available guides explain the respective setup. Choose the sending service actually in use; the DNS provider and signer need not be the same service.
Frequently asked questions
What is DKIM?
DKIM is a method for cryptographic email signatures associated with a signing domain. The recipient checks the covered message parts using the public DNS key corresponding to d= and s=. DKIM does not encrypt the message or confirm a natural person's identity.
How do SPF and DKIM differ?
SPF compares a connecting IP address with the DNS policy for an SMTP identity. DKIM verifies a signature on an actual message. DMARC can connect a successful aligned path from either method with the visible sender domain.
Which DKIM key should I use?
For RSA, RFC 8301 recommends at least 2048 bits; 1024 bits is the protocol minimum, not the general recommendation for a new setup. Ed25519 is a separate algorithm with a different key format. Use the methods supported by your service and check the signatures actually produced.
How often must I rotate DKIM keys?
DKIM does not specify one universal calendar interval for every installation. Plan changes according to your operation, handling of private keys and provider requirements. Regular rotation needs a traceable transition; compromise requires a separate response. Two published selectors do not prove that a change has taken place.
Which changes can invalidate DKIM?
Changes to covered message parts that remain after the chosen canonicalisation. Examples include appended footers, rewritten URLs or a changed signed subject. An unsigned header field or a whitespace change accommodated by canonicalisation needs a different assessment.
How do I check whether DKIM works?
DNS shows whether a key is published at the specific selector name. Whether DKIM works on a message is established only by verifying its actual signature. Use that message's d= and s=, distinguish individual signatures and also check DMARC alignment if that is your question.
Sources and next steps
RFC 6376 is the DKIM Internet Standard STD 76. It is updated by RFC 8301, RFC 8463, RFC 8553 and RFC 8616. Sources checked: 12 September 2026. The DKIM errata and errata for the cryptographic updates used here were checked for relevant limitations. An erratum that has only been reported is not an accepted change to the standard.