How this differs from what you already have
Your mail already has several protections. Here is exactly what each one does, and the gap this fills.
SPF, DKIM and DMARC
Your provider almost certainly uses these already. They check that a message came from a
server the domain owner authorised, and that the domain's own signature is intact.
What they do well: stop a stranger sending mail that claims to come from
@yourbank.com at all. This is genuinely valuable and is why outright domain spoofing
is much rarer than it was.
What they cannot do:
- They say nothing about a person. Everyone at a company shares one domain
result. A colleague's compromised account passes all three perfectly.
- They stop at the door. Once a message is inside a mailbox or is forwarded, the
guarantee is gone — forwarding routinely breaks SPF, which is why DMARC has to be
lenient about it.
- They do not protect the content in a way you can check. DKIM signs a message
as it leaves a server; you cannot ask "did this specific person write this specific
text".
- A look-alike domain passes all three, because the attacker owns their own domain and
configures it correctly.
Where this fits: alongside them, not instead. They authenticate the
domain; this authenticates the person and the text.
PGP and S/MIME
Both do something close to what this does: sign and encrypt mail with a personal key. They
are older, standardised, and — for most people — unusable.
| PGP / S/MIME | ProtectMyMail |
| How you get a key | Generate one, then get it signed or bought | Created on install, in seconds |
| How others find your key | Key servers, or you send it to them | Published to the network automatically |
| How the key is tied to your address | A web of trust, or a paid certificate | A code mailed to the mailbox and returned |
| What a reader sees when it fails | Often nothing, or a technical error | One sentence saying what was established |
| Independently audited | Yes, extensively | No |
The honest comparison: PGP and S/MIME are more mature and more scrutinised
than this is. Their problem has never been the mathematics; it is that after thirty years,
almost nobody uses them, because getting a key, distributing it and keeping it working is
work most people will not do. This trades some of that maturity for something a person can
actually finish setting up in ten minutes.
If you already run S/MIME successfully across your organisation, you have most of what
this offers and you should keep it.
Spam filters
A spam filter asks "does this look like bulk unwanted mail". The frauds that cost money
are none of those things: one message, well written, addressed to you personally, often from
a genuine mailbox. Filters are good at what they do and structurally blind to this.
Secure portals and "click here to view your message"
Banks and hospitals often send a notification and keep the real message behind a login.
That does protect the content, and it moves your correspondence into somebody else's system,
adds a password to remember, and cannot be used by anyone who does not run the portal.
It also, unfortunately, trains people to click links in e-mails and log in — which is what
phishing depends on.
End-to-end encrypted messengers
Signal and its like are stronger than any e-mail solution: they hide metadata better, they
have forward secrecy, and they have been audited. If you can move a conversation there, do.
Most business correspondence cannot move. Invoices, contracts, orders and legal
correspondence arrive by e-mail from parties who will not install anything. This is for that
mail.
A summary
| Threat | SPF/DKIM/DMARC | Spam filter | This |
| Outright domain spoofing | Yes | Partly | Yes |
| Look-alike domain | No | Sometimes | Yes |
| Text altered in transit | No | No | Yes |
| Compromised real account | No | No | Warns on key change |
| Provider reading your mail | No | No | Yes, when encrypted |
| An unwise instruction | No | No | No |
← All documentation