DKIM

DKIM, DomainKeys Identified Mail, is an email authentication method that allows the sending domain to associate a cryptographic signature with a message. The system signs certain message headers and body content using a private key controlled by the sending service. The recipient can retrieve the public key published in the domain's DNS and verify that the signature matches. If verification succeeds, the message has not been altered in the signed components after signing, and the domain listed in the DKIM field has authorized the use of its corresponding key. This does not confirm that the content is legitimate or that the sender in the "From" field is who they claim to be.

The configuration uses a selector that indicates which public key to look up in DNS. The selector appears in the DKIM-Signature header of the email and forms the name of the TXT record consulted by the recipient. Organizations can use different selectors for various email services, time periods, or environments, facilitating key rotation. The private key must remain under the control of the sending system and should not be published in DNS, repositories, or tickets. The public key, however, is intentionally exposed to enable verification. If a private key is compromised, the domain should stop using it, rotate it, and update the public records accordingly.

What It Protects and What It Doesn’t

DKIM helps verify the integrity of parts of the message and confirms that the signature is associated with a domain. Some recipients use this result along with other signals to assess authenticity and reputation. The signature can survive multiple forwarding steps, but changes to the signed body or headers may invalidate it. A service that rewrites newsletters, adds banners, or modifies content can interfere with verification. Senders should test the actual delivery path, not just confirm that the TXT record exists. The presence of a DKIM record does not mean every email from the domain is correctly signed or that all signatures are evaluated uniformly.

DKIM does not encrypt email. Message content remains readable to systems handling or archiving it unless separate encryption technologies are used. It is also not a universal spam filter: a malicious message can have a valid signature if the sender controls the domain or an authorized account. The signature does not verify the truthfulness of statements, attachment security, or business legitimacy. Therefore, verification should be considered a limited technical signal, not an absolute badge of trust.

Configuration and Controls

To enable DKIM, the email provider supplies one or more DNS records and instructions to activate signing. The administrator must verify the exact name, record type, key, propagation, and delivery test. Errors in quotes, TXT segmentation, or selector names can prevent verification. If multiple services send emails for the same domain, each may require a distinct key or configuration. It is useful to maintain an inventory of authorized systems, active selectors, and rotation dates, removing records only after confirming no traffic uses them.

DKIM often works alongside SPF and DMARC. SPF checks whether the sending infrastructure is authorized for the SMTP sender domain; DKIM verifies the signature associated with the domain; DMARC enforces a policy and checks alignment with the visible From header domain. Alignment and policies require consistent configuration. In summary, DKIM adds a verifiable DNS-based signature to an email message, providing evidence of integrity and signer domain authorization, but it does not encrypt the message or guarantee its safety or truthfulness.