DKIM is not a digital signature

"Our mail is signed" can mean three unrelated things, and mixing them up leads to wrong conclusions in both directions — assuming protection you do not have, or buying protection you already had. Email security is layers, and each layer proves something different.

DKIM: the server vouches for the domain

DKIM is infrastructure. Your mailserver (or your email provider) automatically signs every outgoing message with a key whose public half is published in your DNS. A receiver verifies the signature and learns one fact: this message really did leave systems authorized by that domain, and nobody altered the signed parts in transit. It says nothing about which person wrote it — the "signer" is the domain, and no human ever sees or touches the key. This is the signature DMARC builds on, the one your DMARC reports count, and the one this product monitors.

S/MIME and PGP: a person signs the content

A personal digital signature — S/MIME through a certificate, or PGP — is made with an individual's own key and travels in the message body. It proves that a specific person signed this specific content, which is a much stronger and much narrower claim than DKIM's, and it can also encrypt the content end to end. Crucially, it lives in a different universe from DMARC: no DMARC report counts personal signatures, no receiver reporting format tracks them, and publishing DMARC neither requires nor notices them. If your compliance question is "what fraction of our mail is S/MIME-signed", no receiver-side report can answer it — only your own sending infrastructure can.

TLS: the connection is encrypted, the message is not

The third layer is transport. When two mailservers talk, they can encrypt the connection with TLS — the message travels encrypted between servers, then sits in plain form at each hop. DMARC reports say nothing about this either, but unlike personal signatures it does have its own reporting channel: SMTP TLS Reports, where receivers tell you how many connections to your domain succeeded over TLS and how many fell back or failed. Two DNS records opt you in — MTA-STS, which tells senders your mail exchange requires TLS, and TLS-RPT, which names the address the reports go to. Sojka checks both records and decodes the reports, beside the DMARC ones.

The rule of thumb

DKIM answers "did this come from the domain's systems, unaltered?" — S/MIME answers "did this person write this?" — TLS answers "was it encrypted on the wire?". DMARC enforces the first, ignores the second, and has a sibling protocol for the third. For protecting a domain's name and reputation, the first layer is the one that decides where your mail lands — which is why it is the one to finish first.

Check your domain free — it reads your public DNS and grades what is there.