How to Set Up DKIM Email Signing: Complete Guide
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email, letting receiving servers verify that the message genuinely came from your domain and was not tampered with in transit. Together with SPF and DMARC, DKIM forms the authentication stack that protects your domain from spoofing and improves deliverability. This guide walks you through the setup process from key generation to verification.
Verify your DKIM configuration instantly
Use our free DKIM Checker to look up your public key, validate the record syntax, and confirm signing is working.
Step 1: Generate Your DKIM Key Pair
DKIM uses public-key cryptography. You need a private key (kept secret on your mail server) and a public key (published in DNS). How you generate the key pair depends on your email provider:
- Google Workspace: Go to Admin Console > Apps > Google Workspace > Gmail > Authenticate Email. Google generates the key pair and gives you the DNS record to publish.
- Microsoft 365: Navigate to the Microsoft Defender portal > Email & Collaboration > Policies > Email Authentication > DKIM. Enable DKIM for your domain and copy the provided CNAME records.
- Self-hosted (Postfix, etc.): Use
opendkim-genkey -s selector -d yourdomain.com -b 2048to generate a 2048-bit RSA key pair. This creates two files: a private key and a TXT record file containing the public key.
Always use 2048-bit keys. While 1024-bit keys still work, they are considered weak and some providers may penalize them.
Step 2: Publish the Public Key in DNS
- Log in to your DNS provider or domain registrar.
- Create a new TXT record with the host set to
selector._domainkey(replaceselectorwith your chosen selector name, for examplegoogle._domainkey). - Paste the public key value. It will look like:
v=DKIM1; k=rsa; p=MIIBIjANBgkq... - Save the record. For Microsoft 365, you typically publish CNAME records instead of TXT records, pointing to Microsoft's DKIM key hosting.
Be careful not to introduce extra spaces or line breaks in the key value. If your key exceeds 255 characters (common with 2048-bit keys), most DNS providers split it into multiple quoted strings automatically. Verify with a TXT Lookup that the record resolves correctly.
Step 3: Enable DKIM Signing on Your Mail Server
Once the DNS record is published, activate DKIM signing in your email provider. Google Workspace requires you to click "Start Authentication" after DNS propagation. Microsoft 365 enables signing automatically once the CNAME records are detected. For self-hosted servers, configure OpenDKIM or rspamd to sign outgoing messages with your private key.
If you use multiple sending services (for example, Google Workspace for employee email and Mailchimp for newsletters), each service needs its own selector and key pair. Configure DKIM separately in each service and publish each public key under its respective selector in DNS.
Step 4: Test and Verify
- Run the DKIM Checker with your domain and selector to confirm the public key is accessible and valid.
- Send a test email and inspect the headers. Look for a
DKIM-Signatureheader and anAuthentication-Resultsheader showingdkim=pass. - Check your DMARC reports after a day or two to confirm DKIM alignment is passing for all sending sources.
For a deeper dive into how DKIM works under the hood, read our DKIM Setup Guide blog post and the DKIM glossary entry.
Frequently Asked Questions
What key size should I use for DKIM?
Use 2048-bit RSA keys. While 1024-bit keys still technically work, they are considered weak by modern standards. Most email providers and security guidelines now recommend 2048-bit as the minimum.
Can I use multiple DKIM selectors for one domain?
Yes. Each sending service should have its own selector and key pair. For example, you might use the selector "google" for Google Workspace and "s1" for SendGrid. Each selector's public key is published as a separate DNS record.
How do I rotate DKIM keys?
Generate a new key pair under a new selector, publish the new public key in DNS, update your mail server to sign with the new private key, and keep the old DNS record for a few days so in-transit messages can still be verified. Then remove the old record.