DKIM

DKIM (DomainKeys Identified Mail) cryptographically signs outbound email so receivers can verify the message really came from your domain and was not altered in transit. The public key is published in DNS (TXT), while the private key stays on the sending server or mail service.

Unlike SPF, which checks the sending IP, DKIM checks a signature over headers/body. They complement each other, and DMARC uses both results for domain policy.

A Simple Analogy

DKIM is a wax seal on an envelope. The recipient has a sample of the official seal (the public key in DNS). If the seal is intact and matches, the contents are treated as untampered.

How It Works Briefly

1. The sending server builds a signature from parts of the message
2. The signature is inserted into email headers
3. The receiver fetches the public key from DNS (selector such as s1._domainkey)
4. Verification passes or fails

In panels you often see “Enable DKIM” under cPanel Email Deliverability, Google Workspace, Microsoft 365, or transactional SMTP providers.

When You Need It

• Business mail that should reach the inbox, not spam
• Store notifications (orders, password resets)
• Domains that send from several services (hosting + CRM + payments) — each sender needs correct setup
• After mail migrations when SPF exists but inbox placement is still weak

What to Watch For

• The DKIM selector must match between the mail panel and DNS
• Do not delete an old key record before cutover finishes if something still signs with it
• Occasional key rotation is good practice for larger orgs
• Forwarding can break DKIM verification; DMARC alignment then matters more
• Test by mailing yourself and reading dkim=pass in headers

FAQ