A message should have been encrypted but wasn’t

The Decision tab on the message’s audit record tells you which of four things happened: detection found nothing, it found something below the threshold, an exception matched, or the rule was in test mode. Each has a one-step fix.

Before you start

Compliance, Admin or Owner role, to read decisions and edit policy.
The message’s sender, recipient and rough time.
TLS delivery is still encrypted in transit; the gap is that the message landed in an ordinary inbox rather than behind a one-time code. If the recipient was the wrong person, report a security incident first.

Steps

Console → Archive & audit → find the message → Decision tab. It lists each finding with its confidence, the matched rule, any exception applied and the policy version.
No findings. Nothing matched a pack pattern. Add your own identifier under Policy → Custom → Pattern (chart number, client ID, matter number), upload a document fingerprint for the form, and remind staff that [SECURE] in the subject forces locked delivery.
Findings below threshold. A pattern fired with low confidence, often a date of birth without a name. Lower the threshold under Policy → Packs and watch Reports → Detection for a week; see handle false positives if noise rises.
An exception matched. The recipient domain is on the exception list, usually for S/MIME or a signed agreement. Expected; if stale, remove it under Policy → Exceptions.
Rule in test mode. The Decision shows “would encrypt”. Open Policy → Rules, switch the rule on and save a new version with a note.

Verify

Paste the same content into Policy → Rules → Test policy; it shows findings and action without sending. Then resend a copy to a test address you control: the audit record reads “Locked · delivered” and a notification arrives instead of the message.

Troubleshooting

The message is not in the audit trail at all. Cause: it went to another user in your own domain, and internal mail never leaves Google or Microsoft. Fix: nothing to change; internal mail is outside PXCMail’s scope.
[SECURE] was in the subject but the mail went TLS. Cause: the tag was typed differently from the configured tag, or inside a reply subject after “Re:”. Fix: check Policy → Subject tags for the exact text and add the spelling staff use as a synonym.
The attachment held the sensitive content. Cause: the attachment was an image or a scanned PDF with no text layer; OCR is a Hosted Pro feature. Fix: on Gateway and Hosted, train staff to use [SECURE] for scans, or move to Hosted Pro.

Example

Lakeside Family Dental, a 12-person office on Google Workspace, sends X-ray referrals from frontdesk@. One went out as TLS to an oral surgeon. The Decision tab showed no findings: the referral carried the patient’s name and a Dentrix chart number but no date of birth, SSN or MRN, so the healthcare pack had nothing to match. The office manager added a custom pattern for the chart number format and a document fingerprint for the referral form. A test referral now shows two findings and the action “encrypt”, and the next real one went out as locked delivery.

FAQ

Was the message exposed?

It was encrypted in transit and delivered to the intended mailbox. Whether that meets your policy for the content is your call; the audit record gives you the facts.

Can I make everything to outside addresses locked delivery?

Yes. A rule with the condition “recipient outside the organization” and the action encrypt does that. Most offices prefer detection plus [SECURE] so routine mail stays ordinary.

Why did a similar message encrypt last week?

Compare the two Decision tabs. The usual differences are an extra identifier in one message, a policy version change in between, or a new exception.

Still stuck? A human answers within 15 minutes on chat, 1 hour by email during business hours (24/7 for outages).