This will likely be a shorter part of the series, most platforms can get DKIM implemented, unlike SPF, which they get wrong all the time.

Still, there’s a few misconceptions I see around DKIM that I’d like to try to clear up, and give a few tips to have a nicer client experience.

Background - what is DKIM?

DomainKeys Identified Mail, or DKIM, is a method of cryptographically signing email messages using public-key cryptography.

In short:

  • An email producer creates a pair of cryptographic keys, one private, one public.
  • The public key is published to DNS.
  • The email producer signs the message using their private key.
  • The signature will contain:
    • A list of email headers used to generate the signature.
    • The domain the signature is published on.
    • A “selector” indicating which key was used (domains can have multiple keys).
  • The email receiver looks up the public key from DNS and verifies the signature is valid.

Take careful note - DKIM only verifies if a signature is valid. This means (and only means) that the public key exists, and that the signature attached to the message was generated with said public key.

This is not the same thing as declaring an email as authentic.

DKIM doesn’t really care about the “From” address.

On it’s own, DKIM doesn’t have any specifications about whether a signature needs to match a message’s “From” address, or provide any mechanism for determining if an email is authentic. That’s considered outside the scope of DKIM, and is left up to local policy.

It’s perfectly legal to have DKIM signatures from other domains. I believe at the time, one use-case was mail systems could opt to trust say, any message signed by example.com, even if the “From” address used buffering.rocks - the idea being we would trust particular mail systems.

So if it’s legal for envelope addresses to not match the “from” address, and it’s legal for DKIM signatures to not match the “From” address, how the hell do you verify an email as legitimate or not?

DMARC DMARC solves that issue.

Clients shouldn’t need to publish DKIM TXT records.

Some providers give instructions like “tell your IT team to create this TXT record.” This is really error-prone.

Updating DNS may involve creating a support ticket, and some of those longer TXT records will get completely mangled by the ticketing system (line breaks added and whatnot).

So when somebody from the DNS team picks up the ticket, hopefully the vendor-provided instructions are clear enough, because the client requesting the DNS entry is just copy-pasting and has no idea what any of this means. Saying things like “publish this domain key under the cool-platform selector” might not really mean anything to the DNS team - because they’re not managing email, they’re managing DNS. What the hell is a selector, from a DNS perspective?

I’ve seen TXT records published with extra spaces because the ticketing system added them, I’ve seen TXT records published under the wrong resource record because the instructions didn’t just state “publish this at cool-platform._domainkey.example.com. This all results in an unpleasant experience for the client.

Also, when I see a platform give the TXT record to publish, I immediately know - these keys are never, ever getting rotated.

Clients can publish CNAME entries pretty easily.

Having the client publish a few CNAME entries to link out to domain keys is really easy. Even if they have to jump through a few hoops to get DNS entries created, odds are instructions for CNAME entries will be a success.

So host the needed DKIM public keys on your domain, and give the client instructions to create CNAME records pointing to the public keys. It will add an extra DNS lookup to receiving mail systems, but it’s going to be a lot less error-prone compared to giving them the full TXT record.

Plus by publishing a few of them, like cool-platform-key1._domainkey.example.com, cool-platform-key2._domainkey.example.com - you can perform key rotation without the client’s involvement at all.

Ideally you should generate per-client keys and not just use the same keys for all clients. That’s not the biggest deal ever, but if you have a large organization where multiple departments have their own accounts - and you, as a platform, allow multiple accounts to use the same domain - then you really should give each account its own set of keys.

If signing up for an account is as easy as clicking an email verification link - you absolutely need to create per-account keys. You have no idea how these email accounts are managed, provisioned, what kind of security is in place, and so on. If all accounts use the same set of DKIM keys, you just need one bad actor or hacked account to sign up and start sending authenticated spam using your infrastructure.

Thank you for reading!

Here’s links to other parts of the series.