Proudly Canadian 
DKIM is one of those email authentication settings that is easy to overlook during a domain or email provider setup, and one that causes real deliverability problems when it is missing. Unlike SPF, which simply lists authorized sending servers, DKIM works by attaching a verifiable cryptographic signature to every outgoing message. Receiving servers use this signature to confirm that the message came from where it claims to come from and that nothing about it was changed in transit.
The setup process differs slightly depending on which email provider you are using, but the underlying logic is always the same: generate a key pair on the sending side, publish the public key in your DNS, and activate signing. This guide walks through the process for the most common platforms and explains enough about how DKIM works that you can troubleshoot it if something does not go as expected.
Quick Summary
- DKIM adds a cryptographic signature to outgoing messages that receiving servers can verify
- Setup involves generating a key in your email provider, publishing a TXT record in DNS, then activating signing
- Google Workspace, Microsoft 365, cPanel, and third-party services each have their own setup process
- After setup, verify by checking email headers for dkim=pass
- Every service sending email on behalf of your domain needs its own DKIM configuration
How DKIM Works
DKIM uses a public and private key pair. Your mail server holds the private key and uses it to generate a unique cryptographic signature for each outgoing message. The signature is added to the message as a header. When the message arrives at its destination, the receiving server looks up your domain's public key in DNS, then uses it to verify the signature. If the signature is valid, DKIM passes. If the message was altered in transit or the signature cannot be verified, DKIM fails.
The signature covers specific parts of the message, typically the body and certain headers, and is recalculated each time a message is sent. This means even a single character change to the message after signing will invalidate the signature. This is what makes DKIM effective at detecting tampering and what distinguishes it from SPF, which only verifies whether the sending server was authorized, not whether the message itself is intact.
One important practical advantage of DKIM over SPF is that DKIM signatures survive email forwarding. When a message is forwarded through another mail server, the sending IP changes and SPF will often fail for the forwarded message. The DKIM signature, however, is embedded in the message headers and travels with it regardless of how many servers it passes through. As long as the message content is not modified during forwarding, the original DKIM signature remains valid. This makes DKIM the more reliable authentication signal for messages that pass through mailing lists, forwarding addresses, or relay servers.
The DNS record for DKIM is published at a specific address that combines a selector and your domain. If your selector is google and your domain is example.com, the public key lives at google._domainkey.example.com. The selector name is chosen when you generate the key and is embedded in the DKIM signature header of every message, so the receiving server knows exactly where to look in DNS for the corresponding public key.
Setting Up DKIM in Google Workspace
Google Workspace does not enable DKIM automatically. If you set up Google Workspace without following the DKIM configuration step, your emails have been sending without a DKIM signature the entire time.
To set up DKIM in Google Workspace, sign in to the Admin Console at admin.google.com. Navigate to Apps, then Google Workspace, then Gmail, then Authenticate email. If you manage multiple domains, select the domain you want to configure from the dropdown menu. Click Generate new record.
You will be asked to choose a key length. Select 2048 bits if the option is available, which it is for most modern domain configurations. Google will generate a key pair and display the DNS record you need to publish. The record consists of a host name and a value. The host name will look like google._domainkey and the value will be a long string beginning with v=DKIM1; k=rsa; p= followed by the encoded public key.
Copy both the host name and the value exactly as shown. Log into your DNS management panel, which may be your domain registrar, your hosting control panel, or your WHMCS client area, and add a new TXT record. Set the host or name field to google._domainkey and set the value to the string Google provided. Save the record.
DNS propagation takes anywhere from a few minutes to 48 hours depending on your provider and the TTL of your records. You can check whether the record is publicly visible using MXToolbox's DKIM lookup tool. Once the record is visible, return to the Google Admin Console and click Start authentication. Google will verify that it can find the DNS record and activate DKIM signing.
If you see an error saying the record was not found, wait a few more hours and try again. Do not click Start authentication until MXToolbox confirms the record is publicly visible, since premature activation attempts can sometimes cause the interface to show a persistent failure state even after the record propagates.
Setting Up DKIM in cPanel
cPanel servers running Exim as the mail transfer agent typically generate DKIM keys automatically for each domain hosted on the account. Whether they are active depends on your hosting provider's configuration. To check and manage DKIM in cPanel, navigate to the Email section of your cPanel dashboard and look for Email Deliverability.
The Email Deliverability tool shows the current status of SPF, DKIM, and DMARC for each domain on your account. If DKIM shows as invalid or not configured, click Repair or Manage to generate a new key and publish the DNS record. If your domain's DNS is managed through cPanel's own nameservers, cPanel can publish the record automatically. If your DNS is managed elsewhere, such as through Cloudflare or your registrar, cPanel will show you the record value to copy and add manually.
If you are a server administrator with WHM access, DKIM can also be managed at the server level under Email in WHM. The Generate a DKIM Private Key option in the Email section of WHM allows you to generate keys for any domain on the server.
After enabling DKIM through cPanel, verify it is working by sending a test email and checking the headers for a DKIM-Signature header and for dkim=pass in the Authentication-Results line.
Setting Up DKIM in Microsoft 365
Microsoft 365 has DKIM disabled by default for custom domains. The platform does apply a default DKIM signature using Microsoft's own domain, but this does not satisfy DMARC alignment requirements for your custom domain. You need to enable DKIM specifically for each custom domain in your tenant.
To enable DKIM in Microsoft 365, open the Microsoft Defender portal at security.microsoft.com. Navigate to Email and Collaboration, then Policies and Rules, then Threat Policies, then DKIM. Select your domain from the list.
If DKIM has not been set up for your domain before, you will need to publish two CNAME records in your DNS before you can enable signing. Microsoft will show you the exact CNAME records to create. Add them to your DNS management panel and wait for propagation. Once the records are in place, return to the DKIM settings for your domain and toggle signing to enabled.
Microsoft uses CNAME records rather than TXT records so they can manage key rotation on their end without requiring you to update your DNS each time. When Microsoft rotates the key, the CNAME still points to their updated record automatically.
Setting Up DKIM for Third-Party Sending Services
If you use any service other than your primary email provider to send messages on behalf of your domain, whether that is a marketing platform, a transactional email service, a CRM, or a support tool, each of those services needs its own DKIM configuration. Without it, messages from those services will not carry a valid DKIM signature for your domain, which means DKIM fails for those messages and DMARC alignment becomes harder to achieve.
Most major sending services provide their own DKIM records that you publish in your DNS. The process is typically: log into the service's settings, find the domain authentication or sender verification section, and follow the prompts to generate a DNS record. The service will give you a TXT or CNAME record to add to your DNS, which allows their servers to sign outgoing messages with a key that is associated with your domain.
Because each service uses a different selector, multiple DKIM keys for the same domain can coexist in DNS without conflict. A domain might have google._domainkey for Google Workspace, k1._domainkey for Mailchimp, s1._domainkey for SendGrid, and so on. Each service's outgoing messages carry the signature corresponding to their own selector, and receiving servers look up each one independently.
Common services and where to find their DKIM setup documentation:
- Mailchimp: Account settings, Domains, then Authenticate your email domain
- SendGrid: Settings, Sender Authentication, then Domain Authentication
- Mailgun: Sending, Domains, then click your domain and look at DNS Records
- HubSpot: Settings, Website, Domains and URLs, then Email Sending Domain
- Zendesk: Admin Center, Channels, Email, then Domain ownership verification
Publishing the DKIM DNS Record
Regardless of which provider you are setting up, the DNS record you publish follows the same structure. It is a TXT record with a host name in the format selector._domainkey.yourdomain.com and a value that contains the public key in a defined format.
A typical DKIM TXT record value looks like this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
The v=DKIM1 tag identifies this as a DKIM record. The k=rsa tag specifies the key type. The p= value is the base64-encoded public key itself.
When entering this in your DNS panel, be careful about how your registrar handles long TXT record values. Some panels truncate the value at a certain character count. If the key is being truncated, you may need to split it into multiple quoted strings within the same TXT record, which is a standard DNS technique for handling long values. Check your registrar's documentation if you encounter this issue.
If your DNS is managed through your WHMCS client area, navigate to My Domains, click Manage next to the relevant domain, then select DNS Management. Add a new TXT record using the host name and value provided by your email provider.
Verifying That DKIM Is Working
After publishing the DNS record and activating signing in your email provider, you should verify that DKIM is functioning correctly before relying on it for your business mail.
The most direct verification method is to send a test email from the configured account to a Gmail address you control. Open the message in Gmail, click the three-dot menu in the top right of the message, and select Show Original. In the raw headers, look for two things.
First, look for a DKIM-Signature header near the top. If this header is absent, your mail server is not signing messages yet, which means signing is not active regardless of whether the DNS record is in place.
Second, look for the Authentication-Results header. This will contain a line starting with dkim= followed by the result. You want to see dkim=pass along with the domain that was matched. If you see dkim=fail, the signature is present but invalid, which typically means the DNS record does not match the private key being used. If you see no dkim= line at all, the receiving server did not find a DKIM signature in the message.
You can also use MXToolbox's DKIM lookup tool to verify the record is published correctly by entering your domain and selector. This confirms what the receiving server would find when it looks up your public key.
A third option is to send a test message to mail-tester.com, which provides a detailed breakdown of your authentication setup including DKIM pass or fail status, the selector used, and whether the signing domain aligns with your From address.
Common DKIM Problems and How to Fix Them
If DKIM is showing as fail rather than pass, the most common cause is a mismatch between the private key on the sending server and the public key published in DNS. This can happen if the key was regenerated on the sending side without updating the DNS record, or if the DNS record was entered incorrectly. The fix is to generate a new key pair, publish the new public key in DNS, and then activate signing with the new key.
If the DKIM-Signature header is present but the domain in the d= tag does not match your From address domain, DMARC alignment will fail even though the DKIM signature itself is valid. This happens when a third-party service signs messages with its own domain rather than yours. The solution is to configure custom domain DKIM signing in that service, which requires publishing their provided DNS records.
If you cannot find a DKIM-Signature header at all, signing has not been activated on the sending server. Return to the email provider's admin interface and confirm that signing is enabled. In Google Workspace, the button in the Admin Console should show Turn off email signing if signing is active, and Turn on email signing if it is not.
If Google Workspace shows that it cannot verify your DNS record when you try to activate signing, confirm the record is publicly visible using MXToolbox before trying again. If MXToolbox confirms the record exists but Google still cannot find it, try clearing the form and re-entering the activation, since the Google Admin Console interface occasionally needs a hard refresh to pick up recently propagated DNS records.
DKIM, SPF, and DMARC Together
DKIM is most effective when it works alongside SPF and DMARC. SPF authorizes the sending server. DKIM verifies the message content and origin. DMARC ties both together by requiring that at least one of them is aligned with the visible From address, and it gives you reporting so you can see how authentication is performing across all your sending sources.
A passing DKIM signature on its own does not fully protect your domain's reputation or guarantee inbox placement. But DKIM passing consistently across all your sending sources is a prerequisite for moving your DMARC policy from monitoring mode to enforcement. If DKIM is failing for any of your sending services, addressing those failures should be a priority before tightening your DMARC policy.
If you have DKIM set up and want to complete your authentication configuration, the next step is ensuring your DMARC record is in place and reviewing the aggregate reports it generates. Our DMARC configuration guide covers this in detail.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.