Crypto basics in five minutes

DKIM is built on public-key cryptography. You do not need to understand the math. You do need to understand the three operations — generate, sign, verify — and where each one lives in the DKIM workflow. That is what this lesson covers.

If you are already comfortable with asymmetric crypto, skim. If you have only ever set up SSH keys, this is the right level of detail for the rest of the module.

Two keys, one pair

Public-key cryptography starts with a key pair. Two values, mathematically related, generated together.

• The private key stays with the owner. It is never published, never shared, never transmitted. Anyone who has it can sign as the owner.
• The public key is published openly. Anyone can use it to verify a signature created with the matching private key.

The relationship between the two is asymmetric — that is the term of art. Knowing the public key tells you nothing useful about the private key. You cannot derive one from the other in any reasonable amount of compute.

In DKIM terms:

• The private key lives on the sending mail server. M365 stores it in the tenant. Google Workspace stores it in the workspace. A self-hosted sender holds it in a file on disk.
• The public key is published in DNS, as a TXT record, at a specific hostname under the sending domain.

That second point is the load-bearing one. DKIM uses DNS to distribute public keys. No central authority. No certificate. Just a TXT record the receiver can look up.

Signing — what the sending server does

When the sending server hands a message to SMTP, before transmitting, it does the following:

1. Selects which headers to include in the signature — usually From:, To:, Subject:, Date:, a few others.
2. Computes a hash of the message body.
3. Computes a second hash that covers the selected headers plus the body hash from step 2.
4. Signs that second hash with the private key. The result is a cryptographic signature — a long base64 string.
5. Adds a new header to the message: DKIM-Signature:. The header contains the signature itself plus enough metadata for the receiver to verify it.

The message goes out over SMTP with this header in place. Nothing about the rest of the message changes.

Verifying — what the receiving server does

When the receiver gets a message with a DKIM-Signature: header, it does the reverse:

1. Reads the d= field from the signature header. That is the signing domain.
2. Reads the s= field. That is the selector — a label that names which key to use, since a domain might publish more than one.
3. Constructs the DNS hostname: {selector}._domainkey.{domain}. Looks up the TXT record there.
4. Parses the TXT record. Extracts the public key.
5. Re-computes the body hash and the header hash, exactly the way the sender did.
6. Uses the public key to verify the signature against the re-computed hash.

If the verification succeeds — pass. The message was signed by something that holds the matching private key, and the signed content has not been modified in transit.

If it fails — the message was altered, the signature is forged, or the wrong selector was used. The receiver records the DKIM failure and hands the result to DMARC (Module 5) to decide what to do about it.

Where DNS fits

Step 3 above is the DNS step. Without it, DKIM would need a separate key-distribution channel for every domain pair on the internet. With it, the sender publishes one TXT record and every receiver in the world can look it up.

For isidoregroup.com on M365 with selector selector1, the receiver queries:

selector1._domainkey.isidoregroup.com

M365 actually publishes that as a CNAME pointing to a record under tenant.onmicrosoft.com. The receiver follows the CNAME automatically. The end result is a TXT record like:

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

p= is the public key. That single TXT record is what verifies every DKIM-signed message from the domain.

Why this is harder to spoof than SPF

SPF authorizes senders by IP. If an attacker can send from an IP listed in your SPF — say they compromise a transactional sender — they pass SPF cleanly.

DKIM authorizes senders by possession of a private key. The attacker would need to steal the private key from the sending tenant. That is a much higher bar than getting onto a permitted IP range. It does not happen by accident.

The other side of that strength is that DKIM has a maintenance burden SPF does not: keys age, keys need to rotate, and rotating without breaking deliverability is the reason two selectors usually exist. We cover that in lesson 4.6.

What you should remember

• DKIM uses public-key crypto. Private key on the sender, public key in DNS.
• Signing happens on outbound SMTP. The signature goes in the DKIM-Signature: header.
• Verifying happens on inbound SMTP. The receiver fetches the public key from DNS at {selector}._domainkey.{domain}.
• The public key lives in a TXT record (or a CNAME that points to one). That record is the thing Cathedra checks for.
• DKIM is stronger than SPF against IP-based spoofing because possession of an IP is not possession of a key.

Next: the DKIM-Signature header itself, field by field, on a real message.

---

Cathedra alignment: DkimRecordCheck.php — foundation for everything DKIM does