DKIM explained

How DKIM signing works, what a selector is, why it survives forwarding when SPF does not, and what breaks a signature.

In short

  • DKIM adds a cryptographic signature to every message, and receivers verify it against a public key in your DNS.
  • The signature proves the message was authorized by your domain and was not altered in transit.
  • Unlike SPF, DKIM survives forwarding, which makes it the more reliable half of authentication.
  • Publish the key as a TXT record at selector._domainkey.yourdomain.com, not as a CNAME.

What DKIM is

DKIM, DomainKeys Identified Mail (RFC 6376), attaches a digital signature to each message you send. The receiving server fetches your public key from DNS, checks the signature, and learns two things: your domain authorized this message, and the signed parts of it were not modified on the way.

Where SPF authorizes a server, DKIM authorizes a message. That difference is why you need both.

How it works

When Mailverick sends your email, it hashes the body plus a set of headers and signs that hash with a private key. The result travels with the message in a DKIM-Signature header, which looks roughly like this:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mv1;
  h=from:to:subject:date; bh=<body hash>; b=<signature>

The two tags that matter to you:

TagMeaning
d=The signing domain. For DMARC to pass on DKIM, this must match your visible From: domain.
s=The selector, a label that tells the receiver which key to fetch.

The receiver combines them into a DNS lookup at <selector>._domainkey.<domain>, retrieves the public key, and verifies the signature. A selector exists so one domain can hold several keys at once, which is what makes rotation possible without downtime.

Why DKIM survives forwarding

An SPF check fails the moment a message is relayed by a server you never authorized, which is exactly what happens on auto-forwarding. DKIM, by contrast, does not care which server delivered the message, only that the content still matches the signature.

So a forwarded message keeps authenticating. A DMARC policy that would otherwise reject that forwarded mail passes on DKIM alone.

This is the main reason not to treat DKIM as optional once SPF is in place.

How to set it up

  1. Get the record from your provider. The key is generated for you; you never handle the private half.
  2. Create a TXT record whose name is the full selector host, for example mv1._domainkey.yourdomain.com. Some DNS interfaces append your domain automatically, so entering the full name results in a doubled domain. Check what the provider shows after saving.
  3. Paste the value exactly, including v=DKIM1; k=rsa; p=. It is long, and a truncated key fails silently.
  4. Verify, then send a test message and inspect the headers for dkim=pass.

In Mailverick

Mailverick generates the key pair when you add a domain, and shows the exact TXT record in the Domains section of the portal. The full setup is walked through in Getting Started. Key generation and rotation are handled for you.

Both SPF and DKIM must show as valid before your domain can send. Check DNS in the portal reports what it found against what it expected, so a mangled or truncated key is visible rather than a mystery.

Common mistakes

Creating a CNAME instead of a TXT record. Some providers hand out DKIM as a CNAME pointing at their own zone. Mailverick publishes the key directly, so the record type is TXT. Creating the wrong type leaves DKIM unverified with no error anywhere except the DNS check.

Letting the DNS provider double the domain. Entering mv1._domainkey.yourdomain.com in an interface that already appends the zone produces mv1._domainkey.yourdomain.com.yourdomain.com. Always read back the saved record.

Truncating the key. A DKIM public key exceeds the 255-character limit of a single TXT string. It must be split into multiple quoted strings inside one record, which most providers do automatically. Pasting into an interface that silently cuts the value gives you a record that exists and never verifies.

Signing with the wrong domain. If a third-party tool signs with its own domain in d=, DKIM passes but does not align with your From: domain, so DMARC still fails. Alignment, not just a passing signature, is what DMARC checks.

Expecting a signature to survive edits. Mailing lists that append a footer or rewrite the subject break the body hash, and DKIM fails afterwards. That is the signature working as designed, not a misconfiguration.

Leaving a 1024-bit key in place. 2048-bit is the current expectation. If you inherited a short key from an old setup, replace it.

FAQ

Does DKIM encrypt my email?

No. It signs it. Anyone can read a DKIM-signed message; the signature only proves origin and integrity. Encryption in transit is TLS, which is a separate mechanism.

What is a selector, and can I choose it?

A selector is just a label that points at one specific key in your DNS, which lets a domain hold several keys at once. Mailverick assigns one, and you do not need to manage it.

Do I still need SPF if DKIM is working?

Yes. Major receivers expect both, and each covers a case the other misses: SPF authorizes the connecting server, DKIM authorizes the message and survives forwarding.

Why does DKIM pass but DMARC fail?

Almost always alignment. The signing domain in d= must match the domain in your visible From: header. A valid signature from an unrelated domain gives DMARC nothing to work with.

How often should keys be rotated?

Every six to twelve months is a reasonable rhythm, and Mailverick handles it. Rotation is safe because the old and new selectors can be published at the same time, so messages already sent still verify.

Last updated: May 2026