DKIM in Plain Language: Signing the Mail You Send
When you send an email, how can the receiving mail server verify that it was genuinely signed by an authorized sending system and that important parts of the message have not been altered?
One answer is DomainKeys Identified Mail (DKIM).
DKIM uses cryptographic signatures to help receiving mail servers verify the authenticity of an email. It works alongside SPF and DMARC to strengthen email authentication, reduce certain forms of spoofing and support reliable business communication.
For businesses sending invoices, quotations, password resets and customer notifications, correctly configured DKIM is an important part of a dependable email setup.
1. What Is DKIM and Why Does It Matter?
SPF and DKIM solve related but different problems.
SPF identifies which sending servers are authorized for a domain used during the email delivery process.
DKIM lets a receiving server verify a cryptographic signature associated with the sending domain.
DMARC checks whether SPF or DKIM passes with the required alignment to the domain in the visible From address and provides a policy for handling failures.
DKIM is particularly useful because its signature travels with the message. Unlike SPF, which checks the sending infrastructure, DKIM allows a receiver to verify the signature even when the message passes through certain forwarding systems.
However, DKIM does not encrypt the email, guarantee that its contents are harmless or prove that the person who sent it is trustworthy. It verifies a signature associated with a domain and the integrity of the signed message components.
2. How DKIM Works Behind the Scenes
DKIM uses a public-private key pair to create and verify email signatures.
Here is the process in simple terms.
Step 1: Your Sending System Signs the Message
When an email is sent, the configured mail server or email service creates a cryptographic signature using a private key.
The signature covers selected message headers and a hash of the message body. The private key should remain protected within the sending system and should not be published in DNS.
Step 2: The Signature Is Added to the Email
The sending system inserts a DKIM-Signature header into the message. This header contains information such as the signing domain, selector, algorithm and signature data.
For example, a simplified header might contain:
DKIM-Signature: v=1; d=example.com; s=mail2026; ...The d tag identifies the signing domain, while the s tag identifies the selector used to locate the corresponding public key.
Step 3: The Receiving Server Retrieves the Public Key
The receiving mail server uses the signing domain and selector to look up the public key in DNS.
For the example above, the lookup name would be:
mail2026._domainkey.example.comThe public key is commonly published as a DNS TXT record, although DKIM key retrieval can support other DNS record arrangements under the standard.
Step 4: The Receiving Server Verifies the Signature
The receiving server uses the public key to check the signature and the signed content.
If verification succeeds, the server can establish that the signature is valid for the signing domain and that the signed portions of the message have not changed in a way that invalidates the signature.
If verification fails, the message may have been modified, the signature may be incorrect, or the DNS key and sending configuration may not match.
A DKIM pass does not automatically mean the email is legitimate in every respect. Receiving systems also consider other authentication results, sender reputation and message characteristics.
3. Why DKIM Is Useful When Emails Are Forwarded
Email forwarding can complicate authentication.
Suppose an employee receives a message at their company address and forwards it to a personal Gmail account. The forwarding server may use an IP address that is not authorized by the original sender's SPF record. As a result, SPF can fail.
A DKIM signature may still pass because it was applied by the original sending system and can remain valid when the message is forwarded.
This depends on how the forwarding system handles the message. Changes to signed headers or the body can invalidate the signature, so DKIM is not guaranteed to survive every forwarding scenario.
For businesses, correctly configured DKIM provides an additional authentication mechanism that complements SPF and helps DMARC pass when SPF is disrupted by forwarding.
This is especially relevant when customers forward invoices, employees use forwarding rules or messages pass through mailing systems before reaching their final destination.
4. Understanding DKIM Selectors and DNS Records
A DKIM selector identifies the public key that corresponds to a particular signing configuration.
It allows a domain to publish multiple DKIM keys for different sending systems or key rotations without requiring every service to use the same key.
For example, a business might use separate selectors for:
Employee business email.
An invoicing platform.
A marketing email service.
An application sending transactional notifications.
The exact selector names and DNS records depend on the provider.
A simplified DKIM DNS record might look like this:
Type: TXT
Host: mail2026._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUEThe p value represents the public key and is shortened here for illustration. Use the exact record supplied by your email provider rather than copying this example into production.
Why Separate Selectors Can Help
Using separate selectors can make key rotation and troubleshooting easier. For example, if a newsletter platform has a signing problem, its selector can be investigated independently of the selector used by the business mailbox provider.
However, separate selectors do not automatically isolate a security compromise. The sending systems, their private keys and access permissions must also be secured.
5. What DKIM Key Length Should You Use?
The strength of DKIM depends partly on the cryptographic algorithm and key configuration.
For RSA-based DKIM, 2048-bit keys are a widely recommended choice where the email provider and DNS environment support them. Older 1024-bit keys are still encountered, but stronger keys are generally preferred for new configurations.
Key length is not the only security consideration. Protecting the private key, using supported algorithms and following the provider's configuration guidance are also important.
Businesses should not change key lengths or algorithms blindly. Confirm that the receiving systems and sending platform support the proposed configuration.
6. How to Set Up DKIM for Your Business Domain
The exact setup process varies by email provider, but the general steps are similar.
Step 1: Open Your Email Provider's Domain Settings
Find the email authentication or domain configuration section in your hosting control panel or email service dashboard.
Look for the DKIM settings for the domain used in your visible From address.
Step 2: Generate or Retrieve the DKIM Configuration
Your provider may generate the key pair automatically or supply the DNS record you need to publish.
Some services require you to add a custom sending domain before DKIM signing can be enabled.
Step 3: Publish the DNS Record
Add the supplied record to the authoritative DNS zone for your domain. Confirm the record type, hostname and value carefully.
If another provider manages your DNS, make the change there rather than assuming that editing a hosting control panel will update the authoritative records.
Step 4: Enable DKIM Signing
Publishing a public key alone does not guarantee that outgoing messages will be signed. Confirm that the sending system is configured to use the matching private key and selector.
Step 5: Send a Test Email
Send a message to an external mailbox you control. Inspect the original message headers and locate the DKIM authentication result.
In Gmail, open the message, select the three-dot menu and choose Show original. Look for the authentication summary and confirm that DKIM passes.
Repeat the test for other systems that send email using your domain. A successful test from your employee mailbox does not prove that your invoicing software or website notifications are configured correctly.
7. How to Troubleshoot Common DKIM Failures
A DKIM failure can result from a DNS problem, an incorrect key, a signing configuration issue or changes to the message after signing.
Symptom | Possible cause | What to check |
|---|---|---|
DKIM record cannot be found | Incorrect hostname or DNS record not published | Verify the selector and authoritative DNS zone |
DKIM authentication fails | Public key does not match the signing key | Compare the DNS record with the provider's current configuration |
No DKIM signature appears | Signing is disabled or the message uses a different sending route | Check the settings of the system that sent the message |
One service passes but another fails | Different services use different selectors or signing domains | Test each sending source separately |
DKIM fails after forwarding | The message or signed headers may have been modified | Compare the original and forwarded message where possible |
DKIM passes but DMARC fails | The signing domain may not align with the visible From domain, and SPF may not provide aligned authentication | Review the |
When troubleshooting, change one setting at a time and test again. DNS changes may take time to become visible because of caching and TTL settings.
For additional help, consult the SPF Records Explained: Stop Email Spoofing guide and review your DMARC configuration to confirm that authentication and alignment are both working.
8. DKIM Key Rotation and Security Best Practices
DKIM should be maintained after the initial setup. A key that was configured correctly months ago may need attention after a provider change, suspected compromise or infrastructure migration.
Follow these practices to keep your signing configuration reliable:
Protect private keys. Restrict access to the systems and administrators that need them. Never publish a private key in DNS or share it in public documentation.
Follow a rotation policy. Rotate keys according to your provider's guidance and your security requirements, especially after a suspected compromise.
Use clear selectors. Naming selectors by provider or rotation period can simplify investigations.
Document sending services. Keep a record of which platform uses each selector and signing domain.
Remove obsolete records carefully. Confirm that no active sending system still depends on an old key before removing its public DNS record.
Test after changes. Send new messages and inspect their authentication results after changing keys, selectors, DNS or email providers.
Use DKIM with SPF and DMARC. Multiple complementary authentication mechanisms provide a stronger foundation than relying on one alone.
9. DKIM, SPF and DMARC: How They Work Together
Each mechanism addresses a different part of email authentication.
Feature | SPF | DKIM | DMARC |
|---|---|---|---|
Main purpose | Authorizes sending servers for a domain | Verifies a cryptographic signature | Applies alignment rules and publishes a handling policy |
Uses DNS | Yes | Yes | Yes |
Supports authentication reporting | Not by itself in the same way as DMARC | Not by itself in the same way as DMARC | Supports aggregate reporting |
Can be affected by forwarding | Often, because the forwarding server may not be authorized | May survive if signed content remains intact | Evaluates aligned SPF or DKIM results |
Main limitation | Does not authenticate the visible From domain by itself | Does not guarantee that the message or sender is trustworthy | Depends on correct configuration and receiver handling |
For a robust setup, configure SPF and DKIM for all legitimate sending sources, then publish a DMARC policy that matches your readiness to enforce authentication.
Start with monitoring if you need to discover sending sources, correct alignment failures, and move towards stricter enforcement only when the evidence supports it.
Frequently Asked Questions
Does DKIM Prevent Email Spoofing?
DKIM helps receiving servers verify a signature associated with a domain. It can make certain forms of impersonation harder, but it does not prevent all spoofing or phishing. DMARC adds alignment and policy handling to strengthen protection for the visible From domain.
Does DKIM Encrypt Emails?
No. DKIM signs messages for authentication and integrity checking. It does not hide the email's contents. Email encryption requires separate technologies.
Is DKIM Better Than SPF?
Neither mechanism replaces the other. SPF authorizes sending infrastructure, while DKIM verifies a signature. Using both helps improve authentication resilience, particularly when forwarding affects SPF.
Can DKIM Pass While DMARC Fails?
Yes. A DKIM signature can pass but fail to satisfy DMARC if its signing domain does not align with the visible From domain and there is no aligned SPF pass.
Does Every Email Provider Support Automatic DKIM Setup?
No. Many providers generate DKIM records or configure signing automatically, while others require customers to publish DNS records and enable signing manually. Confirm the setup process with your specific provider.
Conclusion
DKIM provides an important layer of email authentication by allowing receiving mail servers to verify a cryptographic signature associated with your sending domain.
Its value comes from correct implementation: publish the right public key, protect the private key, enable signing for each sending service and test actual messages rather than assuming the configuration is working.
Combined with SPF and DMARC, DKIM helps businesses build a more trustworthy email setup, reduce certain spoofing risks and diagnose authentication failures more effectively.
If your business uses SteboHost business email hosting, review the available domain authentication settings and confirm which parts of DKIM configuration are automated. For other sending platforms, follow their specific DNS and signing instructions.
A valid DKIM signature is not a guarantee of inbox delivery, but it is an important step towards making your business email verifiable and more reliable.
Written by Mercy Chepkemoi
SteboHost engineering and operations team. We write practical guides on hosting, domains, email and security for African businesses — based on what we see in the field, not marketing copy.
Ready to get started?
Browse our hosting plans or contact our team for help choosing the right one.