Before You Start
- Administrative access to your email platform (Microsoft 365, Google Workspace, or mail server)
- Access to your DNS hosting provider to create CNAME or TXT records
- SPF record already configured for your domain
- Understanding of public-key cryptography basics
Generate DKIM keys in your email platform
The process varies by platform. In Google Workspace, navigate to Admin Console, then Apps, then Gmail, then Authenticate Email, select your domain, and click Generate New Record. Choose a 2048-bit key for stronger security. Google will provide a TXT record name and value. In Microsoft 365, go to the Defender portal, navigate to Email and Collaboration, then Policies, then Threat Policies, then Email Authentication Settings, and select DKIM. Select your domain and Microsoft will display two CNAME records you need to publish. For self-hosted mail servers running Postfix or Exchange, use opendkim-genkey to create a public and private key pair with at least 2048 bits.
Publish the DKIM public key in DNS
Log in to your DNS provider and create the records your email platform specified. For Google Workspace, create a TXT record with the name google._domainkey.yourdomain.com and paste the public key value. For Microsoft 365, create two CNAME records pointing to the Microsoft-provided hostnames. For custom setups, create a TXT record at selector._domainkey.yourdomain.com where selector is a label you chose during key generation. The record value follows the format v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY. Set the TTL to 3600 seconds initially. Double-check for typos in the key value, as even a single wrong character will break DKIM verification.
Enable DKIM signing on your email platform
After DNS propagation, return to your email platform and enable signing. In Google Workspace, go back to the Authenticate Email page and click Start Authentication. Google will verify the DNS record is present before enabling signing. In Microsoft 365, toggle the Sign messages for this domain switch to enabled in the DKIM settings page. For Postfix with OpenDKIM, configure the signing table and key table in opendkim.conf, set the socket path, and restart both OpenDKIM and Postfix services. Signing is not retroactive, so only new outbound messages will carry DKIM signatures from this point forward.
Send test emails and verify DKIM signatures
Send test emails from your domain to an external address such as a Gmail account. Open the received email and view the full message headers. Look for the DKIM-Signature header, which should contain your domain in the d= tag and your selector in the s= tag. Check the Authentication-Results header for dkim=pass. If you see dkim=fail, the most common causes are a mismatch between the DNS record and the signing configuration, DNS propagation delay, or message modification by an intermediate mail relay. Use online tools like mail-tester.com or dkimvalidator.com to get a detailed breakdown of the signature verification process.
Configure DKIM for third-party senders
Each service that sends email on your behalf should also sign with DKIM. Most major platforms support custom DKIM. In SendGrid, navigate to Settings, then Sender Authentication, then Domain Authentication, and follow the wizard to publish their CNAME records. In Mailchimp, go to your verified domain settings and add the provided DKIM records. Each service uses its own selector, so there is no conflict with your primary DKIM record. Verify each third-party service by sending test messages and checking headers. Having DKIM aligned across all senders is essential for passing DMARC alignment checks, which require either SPF or DKIM to align with the From domain.
Rotate DKIM keys periodically
DKIM keys should be rotated every six to twelve months to limit exposure if a private key is compromised. The rotation process involves generating a new key pair with a new selector name, publishing the new public key in DNS, waiting for propagation, switching your mail server to sign with the new selector, and then removing the old DNS record after a grace period of one to two weeks. Using a date-based selector naming convention such as 202605 makes it easy to track which key is current. Automate this process where possible and document the rotation schedule. Never delete the old DNS record immediately, as emails signed with the old key may still be in transit.
Common Mistakes to Avoid
Using a 1024-bit key instead of 2048-bit, which is considered weak by modern standards
Forgetting to enable signing after publishing the DNS record, so emails go out unsigned
Not configuring DKIM for third-party senders, causing DMARC alignment failures
Deleting the old DKIM DNS record immediately during key rotation before in-flight emails are delivered
Get your Cyber Defense Score™ in 60 seconds.
100 tools. No installation. No credit card.
Get My Cyber Defense Score™ →