Encryption, S/MIME and rule priority
Why a protected message cannot be signed, what the relay does with one, and how to order your mail flow rules so mail gets both a signature and encryption.
If you use Microsoft 365 email encryption, S/MIME or sensitivity labels, some messages will reach Footer365 already protected. A protected message cannot be signed. This article explains which messages that affects, what Footer365 does with them, and how to arrange your rules so that most mail gets both a signature and its encryption.
This article is about mail flow. With the Outlook add-in only, no message reaches Footer365 after it is sent and Footer365 has no rule of its own in your list, so nothing here applies: the add-in adds the signature while the message is being written, or not at all. Using the Outlook add-in only
What arrives at the relay
An outbound connector is a route, not a transformation. What reaches the relay is whatever the message looks like at the moment Exchange routes it.
| What the sender used | State when it reaches the relay | Can it be signed? |
|---|---|---|
| Nothing (an ordinary message) | Readable | Yes |
| TLS on the connection | Readable once the TLS session ends at the relay | Yes |
| S/MIME, signed only | Readable, but the S/MIME signature covers the exact bytes of the body | No |
| S/MIME, encrypted or opaque-signed | Unreadable | No |
| Microsoft Purview Message Encryption applied by a mail flow rule | Protected, unless the rule order below is in place | No |
| A sensitivity label with encryption, applied by the sender in Outlook | Protected before it reaches transport | No |
Signed-only S/MIME is the trap. The text is readable, so a signature could technically be written into it, but every recipient's mail client would then report the message as tampered with. That is worse than no signature, so Footer365 never does it.
Transport decryption does not help here. Exchange can decrypt a protected message inside its own pipeline so that rules can inspect it, but it protects the message again before it leaves. A protected message routed to the relay arrives protected, whatever your transport decryption setting.
What the relay does with a protected message
The relay checks for protection before it looks at any signature rule, because no rule or template could change the answer. A message is treated as protected when:
- its
Content-Classheader containsrpmsg, or - any part is
multipart/signed,multipart/encrypted,application/pkcs7-mimeorapplication/x-pkcs7-mime, or - any part is
application/x-microsoft-rpmsg-messageor is namedmessage.rpmsg.
It is then delivered exactly as it arrived: nothing is opened, rewritten or resealed. It is never delayed or rejected because it is protected. The relay only adds its trace headers, which do not affect an S/MIME signature.
Your audit log records that the message passed through without a signature, with the reason and the kind of protection found.
Getting both a signature and encryption
The signature has to be added before Exchange protects the message. Both are mail flow rules in your own tenant, so it comes down to their order.
Rules run in priority order, 0 first. The Footer365 rules are created at priority 0 and 1 for this reason.
X-Footer365-Processed: trueX-Footer365-ProcessedFirst pass, mailbox to relay:
- The Footer365 rule matches first and routes the message to the relay. It has "Stop processing more rules" set, so your encryption rule does not run on this pass.
- The relay adds the signature and returns the message with
X-Footer365-Processed: true.
Return pass, relay back to Exchange and on to the recipient:
- The Footer365 rule does not match, because of its exception for
X-Footer365-Processed. - Your encryption rule matches and encrypts the signed message, which is what the recipient receives.
Never give your encryption rule an exception for X-Footer365-Processed. That exception belongs on the Footer365 rule only. On the encryption rule it means signed mail is never encrypted at all.
Keep your encryption rules below the Footer365 rules. If an encryption rule is moved above them, it protects the message on the first pass and the signature is lost.
What rule order cannot fix
- Sensitivity labels and S/MIME applied by the sender. These protect the message in Outlook, before it reaches transport, so no rule order helps and these messages always pass the relay unsigned. If people need a signature on labelled mail, it has to come from the client: the Outlook add-in writes the signature into the message while it is being composed, before the label protects it.
- DLP and auto-labelling policies. These run after mail flow rules and are not stopped by "Stop processing more rules". An auto-labelling policy that encrypts outbound mail therefore does so after the signature is added, which is the order you want.
- Journaling and archive copies taken before the return pass hold the unsigned message.
Symptoms and causes
| What you see | Likely cause |
|---|---|
| No signature; the audit log says the message is S/MIME signed | The sender signs with S/MIME. Nothing to fix at the relay; use the add-in if a signature is needed. |
| No signature; the audit log says the message is rights-protected | An encryption rule or label is applied before the Footer365 rule. Check your rule priorities. |
| Signature present but the message arrives unencrypted | Your encryption rule has an exception for X-Footer365-Processed. Remove it from the encryption rule. |
| Every message processed twice | The exception has been removed from a Footer365 rule. Contact support to have the rules recreated. |
See also Encrypted or signed mail and What Footer365 creates in Exchange Online.
Still stuck?
Tell us what you were trying to do and what you saw. Include the sender, a recipient and roughly when a message was sent, and we can trace it.