Category: training

Lifting shrouds from IT-related mysteries is what we do here.

DKIM… yet another mys(t)ery to so many, but actually not that much rocket science as it seems.
Let me explain : 

Simplified as an acronym, DKIM stands for “Domain Keys Identified Mail” and is nothing more than “just another TXT record” in your DNS.
In a previous post, you could read up about SPF records and how they can diminish the amount of spam being sent FROM your domain name. DKIM takes this to a next step.
It’s the implementation of DKIM that will require some extra feedback from me, though.

Extremely simplified

Woodpecker.co explains DKIM as following :

“Take Game of Thrones to get the bigger picture of DKIM. Ned Stark is sending a raven with a message to king Robert. Everyone could take a piece of paper, write a message and sign it Ned Stark. But there’s a way to authenticate the message – the seal. Now, everyone knows that Ned’s seal is a direwolf (that’s the public key). But only Ned has the original seal and can set it on his messages (that’s the private key).”

Quite the analogy, if you’ve seen GoT (and no spoilers, even !)

 

What happens when using DKIM ?

The entire concept is based on encryption of a specific value that uses a public and a private key, that are generated in pairs and therefore cannot exist apart from each other.

The public value is stored (obviously) in a public location where all e-mail servers and clients can access it : the DNS server that holds your domain name (OVH, Skynet, Godaddy, Combell, …)

The private value is sent in an encrypted way over internet and can be verified through means of that private key, to check if it used the original correct signature.
It’s comparable to how an MD5 checksum works

(with the exception that at the time of this writing, DKIM can not yet be broken and it’s possible to “fake” an MD5 lol)

This hidden signature is then verified by the mail server, through which you send your signed mail, as well as all other mail servers where this message passes (in its original form).

Because…. the signature is added to the mail headers and is completely independant from how SPF records work, a proxy’ing mail server that just passes on your message, retains headers.
Theoretically, your mail could fail on an SPF, but could be perfectly valid on a DKIM basis !

 

Fool-proof ?

Is this method a fool-proof way of confirming ALL mails from your domain are safe now ?

A simple answer : NO.

DKIM is kind of the reverse of SPF, whereas SPF tells the receiving mail server what mail NOT to trust.
DKIM tells the receiving mail server that this specific mail, sent from this specific source is – in fact – OK to receive. DKIM does not guarantee that mails from your domain name, sent from a source other than the one defined in the key verification, are in fact safe, because the key in the verified mail message only counts for the specified source.

“Should I not bother to use DKIM, then ?”

You should still try to implement DKIM wherever possible, as all methods of securing your mail flow and getting spam/phishing mails out of this digital world, are most welcome.

 

What does DKIM look like & “comment ça marche” ?

Enough with the theory; let me explain how (and when) this works.

First of all, your own mail server, through which YOU send outgoing mail, has to have support for DKIM key generation.
Most ISPs (I think we can say “all ISPs”) will not use DKIM, as this would mean having to sign every friggin mail message that the millions of their customers send out on a daily basis.
All mail software would first have to talk on an encrypted basis to a public SMTP server to stuff that signed key in the mail header of their own mail message.
Seeing as most ISPs allow sending over their mailservers, without any authentication whatsoever, except for sending from their IP address range, this can ony mean : a big no-no.

Onward.

If your mail server supports DKIM (we’ll be using Microsoft 365 as an example), we can go ahead and create a DKIM.

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure?view=o365-worldwide  explains in heavy detail how to create a DKIM pair on a M365 mail-based subscription (Exchange Online in short).
Go ahead and read the article.
The come back here, for a small moment of enlightenment.

…

All caught up?
Good.

The original private key is never shown and is only known to your very own mailserver.
You get to see – usually in the form of a next-next-next wizard – the entries you have to add as a CNAME record in your own DNS server that hosts the domain name from which you’re sending mail.

As cryptography goes, the mailserver recieves your request to send a mail to somebody.
Next, it adds a specific unique mail header to your outgoing mail, based on its own private key, in combination with the key known to the public (and thus shown in your DNS records, for others to reverse verify)

Before showing the layout of the DKIM record, let me show you what a signed mail header looks like.
If you’ve been following my instructions, you’ve already seen a DKIM record on the Microsoft website mentioned above, by the way :p

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=newyork;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Analysis time :

• Every DKIM signed mail starts with “DKIM-Signature:”
• The obvious part “v=1” defines the versioning (duh). Ironically at the time of writing, the version will always be “1”
• “a” defines the signing algorithm, usually RSA-SHA or RSA-SHA256
• “d” stands for the domain name of the sender
• “s” is short for “selector” which can be found in the corresponding DNS record (in this case) newyork._domainkey.example.net 
• “c” is the abbreviation for “canonicalization algorithm”. A tricky one to explain, but I’ll try my best.
  You can see it contains 2 values. They represent header/body and define the (dis)allowing of slight header changes in mail forwarding.
  “Relaxed” allows a certain change in the header (for instance when forwarding a mail).
  “Simple” just tells the receiving mail server, that no change in the mail header part is allowed for it to still be a trusted DKIM key.
• “q” is for “query” and tells the receiving end how to perform the DKIM check.
  The q-part is optional. At the time of writing, the only valid entry here is “DNS/TXT”, which defines that a DNS lookup needs to be done, looking into a certain TXT field.
• “t” is the timestamp
• “x” falls together with the timestamp and stands for “expiration”, in case you have a fast-rotating key-pair in your DKIM setup and want to assure the receiving end of a higher security level.
• “h” lists the signed header fields …
• …while “bh” is the hash for the body part of the mail
• “b” is the actual signature data.

Should you totally want to geek out more on the RFC for DKIM, you can get your groove on at https://dkim.org/specs/rfc4871-dkimbase.html

 

The DNS record(s)

Why did I keep this part for last ?
You could see in the above example, that the RFC leaves space for a different way of reading your DKIM record.
For now, we don’t have a different technology other than DNS to exchange DKIM data, but if DKIM were to be upgrading, so to speak, the possibilities would not be limited to DNS.

 

The actual public key would look like this :

NAME : 
nameofyourselector._domainkey.example.net

TYPE : 
TXT

CONTENTS OF RECORD : 
v=DKIM1; k=rsa; p=KLJHLHkjhkhkluhiukhjiulYUHKJUIYUYNJKHLKHIOUHJhjkhkjhklhjkh

The content of this record will be provided by your mail server, when you go through the DKIM generating process

 

A different approach is the use of a CNAME record instead of a TXT record, where your key is stored elsewhere.
Depending on the suggestion your mail server gives you, you’ll implement one or the other.

Your CNAME record could look like this :

NAME : 
nameofyourselector._domainkey.example.net

TYPE : 
CNAME

CONTENTS OF RECORD : 
heresmykey.something.anotherdomain.com

 

There we have it.
Theory and samples.

If you have any questions, don’t hesitate to contact me by mail, postal pigeon, smoke signal, …

Zuper out

 

Handy websites concerning this subject :

• https://mxtoolbox.com/
• https://easydmarc.com/tools/dkim-record-generator

 

Situation sketch

You’ve just imported somebody’s mailbox in a lovely new Office 365 or local Microsoft Exchange Server, coming from a somewhat older system running on IMAP or an other cool 80’s-90’s e-mail protocol.

After struggling with all the necessary issues you run into (getting rid of Mozilla Thunderbird, convincing the local Linux user that he should indeed run Windows for him to receive proper support from you, updating everything to the latest released patches, …), you finally get a version of Outlook up and running, with all mails, calendar and contacts.
Also, don’t forget your auto-complete list ! (NO THIS ISN’T YOUR ADDRESS BOOK)

WHEN SUDDENLY one of the following complaints come your way :

• I can’t delete a certain folder in my Outlook !
• One or more of my folders is empty, even though it says “xxx number of items in this folder” !
• What is “FILTER APPLIED” on the bottom bar of my freshly installed Outlook and why can’t I reset my “Views” in the “Change View” menu ?
• …

In this specific case, after a copy or import from an IMAP mailbox, there’ s a huge possibility that the properties of your folder that houses these mail messages is set to something faulty.

In most of these cases, it’s the so-called Container Class that still thinks that we’re working in an IMAP folder instead of a regular “Note” folder. (I didn’t invent the name)

 

Solving the actual problem

Before we start, I’d like to add a little disclaimer here, saying you can seriously mess up your mail folders if you just fiddle around without knowing what you’re doing in the software we’ll be using.

This magical piece of software is called “MFCMAPI” and can be downloaded from https://github.com/stephenegriffin/mfcmapi

Can’t find the executable ? That’s normal, it’s GitHub. You’re supposed to become depressed here.

https://github.com/stephenegriffin/mfcmapi/releases is the place to be 😉

I’ve made a personal package for your ease here –> MFCMAPI pack v18.2

Download the version corresponding to your OFFICE VERSION (not your Windows version), 32 or 64 bit, unpack the zipfile and run the package.

1. Go to Session > Logon 
2. Select your Outlook profile (if any)
3. Double-click the data store (possibly just one, depending on the rights you have to other mailboxes or extra added PST files)
4. Expand Root – Mailbox (or whatever it’s called in your Office installed language)
5. Expand the Top of Information Store or the IPM_Subtree folder
6. Select Inbox (language-specific name) and browse to the folder containing the problem
   
7. Doubleclick PR_CONTAINER_CLASS in the right column and change the value in the ANSI field to IPF.Note.
   If my predections were correct, it used to say IPF.IMAP.
   If this is not the case, stop what you’re doing and roll back your changes, as there’s a different issue.