Everyday use

The honest answer is: almost nothing changes. Here is the "almost".

Receiving

Nothing to do. Every message you open gets one line at the top telling you what was established about it. Most of the time it says the mail is ordinary, and you carry on.

The desktop application can also watch your inbox and tag messages as they arrive, so the verdict is visible in your normal mail program's list without opening anything. It only ever adds a tag; it never moves, marks as read, or deletes anything.

Sending

Two ways.

Deliberately, per message

In the browser plugin and the Outlook add-in, two buttons appear when you write: Sign and Encrypt. Sign proves you wrote it. Encrypt also seals it so only the recipient can read it — available when they have a published key.

Automatically, for everything

The desktop application can protect everything you send without you thinking about it. It sits between your mail program and your provider: your mail goes out the same way, but signed on the way past, and encrypted automatically whenever every recipient has a key.

This is the setting most people end up using, because protection you have to remember is protection you will forget on the day it matters. The automatic protection guide sets it up.

If anything goes wrong, your mail still goes. The rule the sending path follows is: never lose a message. If a signature cannot be made, or the network is unreachable, the message is relayed exactly as you wrote it rather than being held or dropped. You may lose the protection on that one message. You never lose the message.

What the other side sees

If they also use ProtectMyMail, they see a banner. If they do not:

Replying and forwarding

Replies work normally. Your reply gets its own signature; the quoted text of the original is not re-signed, which is why quoted lines are ignored when a message is checked.

Forwarding a protected message forwards its text and its reference line. The recipient can still check that the original was genuine — the signature travels with the words.

Messages written in HTML only

What gets signed is the plain-text version of your message — the version every mail program can show and every plugin can reproduce. Almost all mail clients send both a plain and an HTML version together, so this is invisible to you.

If your client is configured to send only HTML, there is no such text, and a signature over it could not be checked by anyone. Rather than sign something that would read as "altered" to every recipient, the message is sent unprotected and counted as such in the statistics. If you want everything protected, set your mail program to send plain text as well as HTML.

Attachments

Attachments are carried unchanged and are not covered by the signature today. If the content of an attachment matters, say so in the body of the message: the body is signed, so "the invoice attached is for €4,120 to account NL00…" cannot be altered without the reader being warned.

A message with an attachment is signed but not encrypted. Sealing replaces the whole message with one locked block, so everything that is not the sealed text would be dropped — the attachment included. Rather than deliver a message without the thing it was sent for, it goes out signed and readable, and the application says why. If the content is confidential, put it in the body, which can be sealed, rather than in a file alongside it.

More than one device

Enter the same recovery phrase on each device and they share one identity: the same key, the same verified address, and messages encrypted to you can be opened on any of them. There is no syncing and no account — the phrase is the whole link.

Mailing lists and newsletters

Lists usually rewrite messages as they pass through, which changes the text, which breaks the fingerprint. A message that went through a mailing list will normally read as altered. That is the check working correctly on a message that genuinely was altered — but it means signing is not much use for list traffic.

Next: your recovery phrase.

← All documentation