DKIM (DomainKeys Identified Mail): The Complete Guide
Everything you need to know about DKIM signatures to authenticate your emails and ensure they haven't been tampered with in transit.
What is DKIM?
DKIM (DomainKeys Identified Mail) is an email authentication protocol defined in RFC 6376. It allows you to cryptographically sign outgoing emails to prove two things: that the email genuinely comes from the claimed domain, and that its content has not been altered during transport.
DKIM uses an asymmetric cryptography system (public key / private key). The sending server signs each email with a private key, and the corresponding public key is published in a DNS record. The receiving server can then verify the signature by comparing the two.
Unlike SPF which only verifies the sender's IP address, DKIM guarantees the integrity of the message itself. Even if an email is relayed through multiple servers, the DKIM signature proves that the content has not been modified.
DKIM is an essential component of email security. Combined with SPF and DMARC, it forms the foundational trio for protecting a domain against email spoofing.
How does DKIM work?
The DKIM process unfolds in two phases: signing at sending time and verification at reception.
Signing phase (sending)
- Header selection — The sending server chooses which headers to include in the signature (From, To, Subject, Date, etc.).
- Content hashing — The message body and selected headers are hashed (typically using SHA-256).
- Cryptographic signing — The hash is encrypted with the domain's DKIM private key, creating the digital signature.
- Header insertion — The signature is added to the email via the
DKIM-Signatureheader.
Verification phase (receiving)
- Signature extraction — The receiving server extracts the
DKIM-Signatureheader and identifies the domain and selector. - DNS lookup — It queries DNS to obtain the public key at
selector._domainkey.domain.com. - Verification — It decrypts the signature with the public key and compares the result to the recalculated hash of the received message.
- Verdict — If the hashes match, the signature is valid: the email is authentic and intact.
A DKIM-Signature header looks like this:
And the corresponding DNS record (TXT type):
How to configure DKIM step by step
Step 1: Generate DKIM keys
Most email providers (Google Workspace, Microsoft 365, etc.) automatically generate DKIM keys. You just need to enable the feature in the admin console. If you manage your own server, you can generate keys with OpenSSL:
Step 2: Publish the public key in DNS
Create a TXT record in your DNS zone with the name selector._domainkey.yourdomain.com. The selector is a free-form identifier (e.g., "google", "selector1", "mail"):
- Type: TXT
- Name: selector1._domainkey
- Value: v=DKIM1; k=rsa; p=your_base64_public_key
Step 3: Configure the sending server
Configure your mail server or sending service to sign outgoing emails with the private key. With cloud providers, this step usually comes down to an "Enable DKIM" button in the admin console.
Step 4: Verify the configuration
Send a test email and check the headers to confirm the presence of a valid DKIM-Signature header. Use our free verification tool to validate that the DNS record is correctly published.
Step 5: Configure DKIM for each sending service
If you use multiple services (main email, newsletter, transactional emails), each one must have its own DKIM configuration with a distinct selector. For example: google._domainkey for Google Workspace and brevo._domainkey for Brevo.
Common mistakes to avoid
1. Using RSA keys that are too short
1024-bit RSA keys are now considered weak. Use keys of 2048 bits minimum. Most modern providers already use this size by default.
2. Not rotating keys regularly
DKIM keys should be changed (rotated) at least every 6 to 12 months. Keep the old public key in DNS for a few days after rotation so that emails in transit can still be verified.
3. Public key formatting errors
Some registrars truncate long TXT records. Make sure your public key is complete and properly formatted. The value must not contain any unwanted spaces or line breaks.
4. Forgetting to configure DKIM for third-party services
Every service that sends emails on your behalf (newsletter, CRM, support) must have its own DKIM record. Without it, their emails will fail DMARC verification.
5. Not testing after configuration
An error in the DNS record or server configuration can render DKIM non-functional without you noticing. Always test systematically with a verification email.
Frequently asked questions about DKIM
What is the difference between SPF and DKIM?
SPF verifies that the sending server is authorized to send on behalf of your domain (IP verification). DKIM verifies that the email content has not been modified and that it is genuinely signed by your domain (cryptographic verification). The two are complementary: SPF authenticates the server, DKIM authenticates the message.
Can you have multiple DKIM records?
Yes, unlike SPF which only allows a single record, you can have as many DKIM records as needed. Each sending service uses a different selector, creating distinct DNS records. This is the recommended practice.
Does DKIM slow down email sending?
The performance impact is negligible. Cryptographic signing takes only a few milliseconds per email. On the receiving side, DKIM verification adds a DNS lookup and a hash calculation, but this has no perceptible impact for the end user. The benefits in terms of deliverability and security far outweigh this minimal cost.
Check your domain for free
Test your SPF, DKIM, and DMARC configuration in one click. Our tool analyzes your domain and tells you exactly what needs to be fixed.
Test my domain