A false sense of security
Your IT team has configured SPF, DKIM and DMARC. Maybe even S/MIME. You think your emails are secure.
Yet email wire-transfer fraud rose 93% among French professionals in 2025. How is that possible?
What these protocols actually do
Checks the email comes from a server authorised for your domain
Does not prove who sent the email
Guarantees the message wasn't altered in transit
Doesn't guarantee the sender's real identity
Defines the policy if SPF or DKIM fail
Adds no further proof of identity
SPF
SPF checks that an email comes from a server authorised for your domain. It says: this server may send on behalf of this domain. It doesn't say who sent the email.
DKIM
DKIM attaches a digital signature to the email to guarantee it wasn't altered in transit. It guarantees message integrity, not the real sender's identity.
DMARC
DMARC builds on SPF and DKIM to define what recipients should do if checks fail. It adds no further proof of who sent the email.
S/MIME
S/MIME goes further: it lets you digitally sign an email with a personal certificate. The signature proves the message comes from the certificate holder. It's stronger, but with a major limitation.
The limitation no one mentions
S/MIME is a point-to-point protocol. For the signature to be visible and verifiable, the recipient must use a properly configured, compatible email client, trust the certificate authority that issued your certificate, and hold your public key.
If your S/MIME-signed email reaches a colleague using a basic webmail client, the signature is invisible. No check takes place. No warning appears if someone impersonates you.
Moreover, S/MIME doesn't produce a qualified timestamp under the eIDAS regulation (EU No 910/2014).
Signature visible. Rare in B2B SMEs.
Signature invisible. The majority case.
S/MIME needs infrastructure on both sides. Without it: zero protection.
What happens in a typical wire-transfer fraud
“New bank details for the next transfer”
No alert triggered
SPF, DKIM, DMARC blocked nothing.
An attacker sends your client an email that appears to come from you or one of your partners. It passes SPF and DKIM because the attacker uses a lookalike domain or a compromised legitimate account. The client sees a familiar name, a usual tone, an urgent request. They pay.
Neither SPF, nor DKIM, nor S/MIME prevented anything.
What email identity certification adds
A cryptographic certification approach with a qualified eIDAS timestamp works differently. Every email sent generates a unique fingerprint certified by a recognised European timestamping authority. This certification can be verified by anyone, on any device, with no prior setup, via a public URL.
If someone receives an email claiming to come from your firm, they can verify in one click that you really sent it – or that no certification exists for it.
Verification doesn't depend on the recipient's email client. It doesn't depend on prior technical setup. It doesn't depend on the user's vigilance.
What this changes in practice
For a lawyer, accountant or notary sending wire instructions, bank-detail changes or contractual documents by email: certification provides proof that the email really comes from you, and lets your client verify it.
This isn't a replacement for SPF, DKIM or S/MIME. It's a complementary layer that addresses what these protocols don't cover: identity proof the recipient can verify, with no technical prerequisites.
Frequently asked questions
Sources: Cybermalveillance.gouv.fr, 2025 Activity Report. RFC 3161 (qualified timestamping protocol). eIDAS Regulation (EU) No 910/2014.
One demo and you'll see the signature appear in Outlook.
Request a demo