Close-up of a secure lock icon on a digital screen symbolizing DKIM email signatures and cryptographic protection for domain messages

DKIM Records: How Email Signatures Prove Your Messages Are Genuine

When an email lands in someone’s inbox, their provider has to decide whether to trust it. Is this message really from your domain, or did someone fake the “From” address? DKIM is one of the main tools mail systems use to answer that question.

DKIM adds a kind of digital signature to your outgoing messages. Receiving servers check that signature against a DKIM DNS record on your domain. If everything matches, your email looks much more trustworthy.

What Is DKIM in Simple Terms?

DKIM stands for DomainKeys Identified Mail. It is a system that lets the owner of a domain sign outgoing emails using cryptography. The signature is attached to the email headers, and the matching public key is published as a TXT record in DNS.

In everyday language:

  • Your mail server signs the email with a private key that only it knows.
  • Your domain publishes a public key in DNS (a DKIM record).
  • Receiving servers use that public key to check the signature.

If the signature is valid, the receiver knows that the message has not been modified in transit and that it was approved by a server allowed to send on behalf of your domain.

What Problem Does DKIM Solve?

Without DKIM, it is fairly easy to forge an email that looks like it came from your domain. Attackers can:

  • Fake the “From” address to trick customers.
  • Modify parts of a message while it travels across servers.
  • Send phishing emails that appear to come from your brand.

DKIM helps with two big things:

  • Integrity – it proves the content has not been changed after it was signed.
  • Authentication – it shows the message was authorized by a domain that controls the DKIM key.

On its own, DKIM does not block all abuse, but together with SPF and DMARC, it becomes part of a strong protection layer for your domain.

How DKIM Works Step by Step

To understand DKIM, it helps to walk through a simplified sending and receiving process.

  1. Your mail system prepares the email.
    Before sending, it selects certain headers and parts of the body and creates a hash (a kind of fingerprint) of that content.
  2. Your server signs the hash with a private key.
    This private key is kept secret on your mail server or email provider.
  3. A DKIM-Signature header is added.
    This header includes:
    • The domain that is signing the message.
    • A selector name (to find the right key in DNS).
    • Information about which headers were signed.
    • The actual signature, as a long string.
  4. The email is sent across the internet.
  5. The receiving server gets the email and reads the DKIM header.
    From that header, it learns which domain and selector to check.
  6. The receiver looks up the DKIM public key in DNS.
    It queries a TXT record like selector._domainkey.example.com.
  7. The receiver verifies the signature.
    If the signature matches the content using the public key, DKIM passes. If not, DKIM fails.

All of this happens automatically and usually in milliseconds. End users only see the result indirectly, as better inbox placement and fewer warnings.

What a DKIM DNS Record Looks Like

A DKIM record is stored as a TXT record on a special subdomain under _domainkey. The full name includes a selector, which lets you have multiple keys for one domain.

The pattern is:

<selector>._domainkey.<your-domain>

Example hostname:

news._domainkey.example.com

The value of the TXT record is a series of tags, such as:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Common tags in a DKIM record:

  • v – version, usually DKIM1.
  • k – key type, typically rsa.
  • p – the public key (long base64 string, often split across lines in examples).

In your DNS panel, it might look like this:

Host: news._domainkey
Type: TXT
Value: "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

You usually do not write this by hand. Your email provider or mail server software generates the key pair and gives you the exact DKIM record to publish.

What Is a DKIM Selector?

The selector is the first part of the DKIM DNS name (before ._domainkey). You can think of it as a label for a specific DKIM key.

Selectors allow you to:

  • Use different keys for different systems (for example, news for newsletters, app for transactional email).
  • Rotate keys without breaking existing mail (set up a new selector and then switch your sending system to use it).
  • Run multiple email providers under the same domain, each with its own selector.

When you look at an email’s headers, you will see a field like s=news inside the DKIM-Signature header. That is the selector name.

How DKIM Works Together With SPF and DMARC

DKIM is most effective when it is not alone. It usually sits alongside:

  • SPF – lists which servers are allowed to send mail for your domain.
  • DMARC – sets a policy for how receivers should treat emails that fail SPF and DKIM checks.

DMARC in particular cares about alignment: whether the domain in the DKIM signature and/or SPF result matches the domain in the visible “From” address. If DKIM passes and is aligned, DMARC will typically treat that message as authenticated.

You do not have to be an expert in all three to get benefits, but knowing that they work as a team helps when you are reading reports or fixing delivery issues.

How to Set Up DKIM for Your Domain

The exact steps depend on your email provider or mail server, but the general flow is similar almost everywhere.

  1. Enable DKIM in your email system.
    In a hosted email service, this is often a toggle or setup wizard. On a self-hosted server, you may need to configure DKIM software like OpenDKIM.
  2. Generate a key pair (if not generated automatically).
    The system creates a private key (kept secret on the server) and a public key (to be published in DNS).
  3. Copy the DKIM DNS record details.
    Your provider shows you:
    • The selector name (for example, default or news).
    • The DKIM host (for example, default._domainkey.example.com).
    • The TXT value containing v=DKIM1; k=rsa; p=....
  4. Add the DKIM TXT record in your DNS panel.
    Create a TXT record at the given host and paste the full value exactly as provided.
  5. Wait for DNS to propagate.
    This may take from a few minutes to a couple of hours depending on TTL and caching.
  6. Turn on signing and send test emails.
    Once the record is visible, enable DKIM signing (if it is not automatic) and send test messages to verify that DKIM passes.

Common DKIM Misconfigurations

Most DKIM problems come down to a few classic mistakes:

  • DNS record added at the wrong host. For example, adding the TXT record at _domainkey.example.com instead of selector._domainkey.example.com.
  • Public key copied incorrectly. Removing spaces or quotes incorrectly, or losing part of a long key when pasting.
  • Signing enabled before DNS is ready. Emails are sent with DKIM headers, but receivers cannot find the matching key in DNS yet.
  • Multiple systems using the same selector without coordination. One system rotates the key, but another still signs with the old one.

If DKIM fails for your messages, checking the DNS record with a lookup tool and comparing it to what your provider shows is often the fastest way to find the issue.

How to Check if DKIM Is Working

Once DKIM is set up, you should test it from time to time.

  • Use online DKIM test tools. Many services let you send a test email to a special address, then show you the DKIM result.
  • Inspect email headers in a real inbox. Open a received message and look for fields like:
    • DKIM-Signature:
    • Authentication-Results: with something like dkim=pass or dkim=fail.
  • Check DMARC reports (if you use DMARC). Aggregate DMARC reports often show how many messages passed or failed DKIM for your domain.

Seeing dkim=pass in the headers for legitimate messages is a good sign that your configuration is correct.

Key Takeaways About DKIM Records

  • DKIM uses a private key on your mail server and a public key in DNS to sign and verify emails.
  • The public key lives in a TXT record at <selector>._domainkey.<your-domain>.
  • DKIM helps prove that a message was authorized by your domain and was not tampered with in transit.
  • Selectors let you use multiple keys and rotate them safely.
  • DKIM works best when combined with SPF and DMARC for full email authentication.

DKIM Records FAQ

What is a DKIM record in DNS?

A DKIM record is a TXT record that publishes the public key used to verify email signatures from your domain. It lives under a subdomain like selector._domainkey.yourdomain.com and is read by receiving mail servers to check whether DKIM signatures are valid.

Do I need DKIM if I already use SPF?

Yes, you should usually use both. SPF checks which servers are allowed to send mail, while DKIM proves that the content was signed by your domain and not altered. Together with DMARC, they give mail providers a much stronger basis for trusting your messages.

Who generates the DKIM keys, me or my provider?

In most hosted email services, the provider generates the key pair for you and simply tells you which DKIM TXT record to publish. If you run your own mail server, you or your admin will generate the keys using your mail software’s tools and then add the public key to DNS manually.

Can I have multiple DKIM selectors for one domain?

Yes. You can publish multiple DKIM records with different selectors, all under the same domain. This is useful when you have several sending systems or when you want to rotate keys gradually without interrupting email flow.

How often should I rotate my DKIM keys?

There is no single rule, but many organizations rotate keys periodically (for example, once or twice a year) or when changing infrastructure. Rotating keys with new selectors and updating your mail systems to use them helps reduce risk if an old key were ever exposed.

Related Email Security Topics

  • SPF records: listing the servers that are allowed to send mail for your domain.
  • DMARC policies: telling receivers how to treat messages that fail SPF or DKIM.
  • TXT records in DNS: the underlying record type that holds SPF, DKIM and DMARC data.
  • MX records: how mail servers know where to deliver messages for your domain.

Once DKIM is set up and your keys are safely published in DNS, you give mailbox providers a strong reason to trust your messages. That trust often translates into better inbox placement and fewer headaches for both you and your users.

Related Articles