Who Is "The Kim," and What Does She Have to Do With Your Email Security? Nothing — Meet DKIM, not The Kim

Good question. The answer is nothing as she has nothing to do with it. We promise our technical skills are much better than our comedy skills. That's because it's not "The Kim" — it's DKIM, and it's been sitting quietly (hopefully) in your email settings this whole time, doing a job that has nothing to do with reality TV and everything to do with keeping your business emails honest.

Fair warning up front: we peaked with the sun tan lotion joke in Part 1. This one's not as good. We'll own that when we get to Part 3.

That's Part 2 of our four-part series on email security. Last time we covered SPF — the guest list that decides which servers are allowed to send email as you. This time it's DKIM, which handles something SPF can't touch at all: helping the receiving mail system verify that the protected parts of a message were not meaningfully changed after it was signed.

So what is DKIM, actually?

DKIM stands for DomainKeys Identified Mail, but like last time, forget the acronym. Think of it as a wax seal on an envelope.

SPF checks whether the sender is allowed to send on your behalf — it's the guest list at the door. DKIM checks something completely different: whether the protected parts of the email still look the way they did when an authorized mail system signed it. It's a digital signature, attached invisibly to the message by a mail service that is authorized to send for your domain.

Here's the practical version. When your mail service sends a message, it runs the protected parts through a bit of math and attaches the result as a hidden signature. When the message arrives, the receiving server looks up the matching public key, checks the signature, and makes sure the protected parts still match. If they do, the signature validates. If those parts were meaningfully changed along the way, the signature no longer validates, and the receiving server knows something's off.

That does not mean every DKIM-signed message is honest or safe. A scam email can still be properly signed. DKIM simply helps prove that the protected parts of the message arrived substantially as the signing system sent them.

That's the piece SPF can't do. SPF vouches for where the email came from. DKIM helps verify the integrity of the signed message.

Do you actually need to worry about this?

Same rule of thumb as last time: look at what comes after the @ symbol.

• If you're using a free email address — Gmail, Outlook.com, Yahoo — DKIM is already handled for you on their end. Nothing to set up.
• If you're using your own business domain — `you@yourbusiness.com` — don't assume DKIM is active just because your Microsoft 365 or Google Workspace email is working. Business domains often need an additional DNS setup or administrator step before DKIM is properly enabled for the company's own domain.

And just like SPF, it matters what is sending the mail. Microsoft 365, Google Workspace, your CRM, your invoicing tool, your marketing platform — every service that sends email using your business domain needs its own proper email-authentication setup. Ideally, that includes DKIM signing for that particular service. Otherwise, one stream of your email may be properly protected while another quietly goes out without it.

What actually happens if you skip it

DKIM being missing is quieter than SPF being missing, which is part of why it gets overlooked. A few things it opens the door to:

• There is no digital seal to check. Most modern email is also protected while it travels, but without DKIM the receiving system has no separate cryptographic way to verify that the protected parts of the message still look the way the sending service intended.
• Your emails may look less trustworthy to spam filters. Gmail, Yahoo, and other large providers increasingly expect properly authenticated mail. Missing or broken DKIM can contribute to messages being filtered or rejected — same story as SPF, different mechanism. DKIM is not the only thing spam filters consider, but it is an important part of the picture.
• DMARC has fewer ways to verify your mail. We'll get into DMARC in Part 3, but the short version is that it can use either SPF or DKIM when they properly match your domain. Having both gives legitimate email two different ways to prove it belongs to you, especially because forwarding can interfere with SPF while DKIM may continue working.

None of this necessarily shows up as an obvious error message or warning banner. It may show up later as emails that quietly land in spam, get rejected, or fail authentication for no obvious reason.

If you already have DKIM set up, it might still need a tune-up

Having DKIM turned on isn't the same as having it covering everything it should. A few things we run into constantly when we check this for clients:

Not every sending source gets signed. It's common for a business's primary email — Microsoft 365 or Google Workspace — to be properly signed, while a marketing platform or invoicing tool sending mail from the same domain never got set up at all. Each legitimate sending service should have its own properly configured DKIM setup, and it's easy for newer tools to slip through when nobody thinks to check.

Old keys never get reviewed. DKIM works off a cryptographic key pair. Like other important security keys, it should not be created once and forgotten forever. Providers have different recommendations, but the setup should be reviewed and the keys rotated when appropriate. Plenty of domains are still running on whatever key was generated when DKIM was first turned on, sometimes years ago, and nobody has circled back to check it.

A broken DNS record can break validation silently. DKIM makes its public key available through DNS, either directly in a record or through a pointer supplied by the email provider. If that record gets deleted, mistyped, or overwritten during some unrelated DNS cleanup, the sending service may continue attaching DKIM signatures, but receiving servers can no longer find the correct public key to verify them. To the sender, everything may appear normal. To the recipient's mail system, the signature is broken.

Selectors matter more than people realize. DKIM records are published under names called "selectors." Microsoft 365 commonly uses two selectors so it can switch from one DKIM key to another without interrupting mail. It may use only one at a particular moment, but both DNS records need to be correct so a future key change does not suddenly break validation.

The bottom line

DKIM covers the part of the story SPF can't reach — not who's allowed to send as you, but whether the protected parts of the message still look the way they did when the sending system signed them. Between SPF and DKIM, you've got a real foundation. But there's still a piece missing: something that actually decides what happens when SPF or DKIM fails, and tells receiving servers what to do about it.

That's Part 3. And yes, we'll address the joke situation then.