[mh_key_takeaways]
The idea that typing “secure” in the subject line encrypts an email is one of the most repeated pieces of workplace advice in healthcare and finance. It is also one of the most misunderstood. The behavior only works when an administrator has already configured a matching rule on the server.
This guide covers what the subject-line trigger actually does inside Microsoft 365 and Google Workspace, how to configure it, when it fails, and when a default-encrypt approach through a dedicated encrypted email service removes the guesswork.
The intent is to give administrators, compliance leads, and practice managers a clear picture of the mechanism so staff training reflects reality rather than folklore.
The Subject-Line Trigger Is a Server Rule, Not a Client Feature
Outlook, Gmail, Apple Mail, and every other major client have no built-in behavior that reads the subject line and encrypts the message based on a keyword. The client sends whatever the user typed.
The encryption happens on the server side after the client hands the message off. Microsoft 365 uses mail flow rules. On-premises Exchange calls them transport rules. Google Workspace calls them content compliance rules. All three inspect the subject line before delivery.
The rule matches a keyword pattern. Common patterns include the word “secure”, the word “encrypt”, or a bracketed tag like [secure] and [encrypt]. When the pattern matches, the rule applies the encryption action.
In a stock tenant with no rules defined, typing “secure” in the subject line does nothing except add the word to the subject. The recipient sees plain text with a sensitive-looking word at the top. That is worse than nothing because it signals sensitivity without actually protecting the content.
Microsoft 365 Uses Mail Flow Rules Under Exchange Admin
Setting up subject-line triggered encryption in Microsoft 365 takes about five minutes for an administrator familiar with the Exchange admin center. The tenant needs a Microsoft 365 plan that includes Office 365 Message Encryption or Purview Message Encryption.
Sign in to the Microsoft 365 admin center. Open Exchange. Open Mail flow, then Rules. Click the plus icon and select “Apply Office 365 Message Encryption and rights protection to messages”.
Configure the condition as “The subject or body includes any of these words” and enter the keywords staff will use. Add all variants you plan to support such as secure, encrypt, [secure], and [encrypt]. Set the action to Encrypt.
The Microsoft Purview Message Encryption documentation walks through the exact screens. Save the rule, enable it, and send a test message with the keyword to an external Gmail address to confirm the portal experience.
Google Workspace Uses Content Compliance Rules
Google Workspace supports the same pattern through content compliance rules. Sign in to the Google admin console. Navigate to Apps, then Google Workspace, then Gmail, then Compliance.
Scroll to Content compliance and click Configure. Give the rule a descriptive name such as “Subject-line encryption trigger”. Under Email messages to affect, choose Outbound.
Under Expressions, add a Simple content match with location set to Subject and enter the keyword. Add multiple expressions for each supported keyword. Under the action, choose the encryption route configured for your tenant, which is typically S/MIME on an eligible plan, client-side encryption, or a third-party gateway host.
The Google Workspace admin help article on content compliance covers the full flow. Confidential Mode cannot be triggered through content compliance because it is a compose-time feature that must be selected per message.
Common Keyword Patterns and What They Actually Trigger
The specific keyword an organization picks matters. Some patterns are cleaner than others because they avoid accidental matches on legitimate business subject lines.
The most common patterns in practice are:
- Bare word “secure” at the start of the subject.
- Bare word “encrypt” anywhere in the subject.
- Bracketed tag such as [secure] or [encrypt].
- Prefix code such as SECURE: or ENC:.
- Custom identifier unique to the organization such as [PHI-SEND].
Bare words trigger easily but also fire on legitimate business subjects like “Secure area badge renewal”. Bracketed tags reduce false positives because staff rarely include square brackets by accident. Custom identifiers work best for organizations with strict compliance policies.
Pair the trigger with an outbound rewrite that strips the tag from the subject after the encryption action fires. That way the recipient sees a clean subject and the sensitivity marker does not leak into the inbox preview.
[mh_example]
The Subject Line Itself Is Rarely Encrypted
Most encryption implementations protect the body and attachments but leave the subject in cleartext. Office 365 Message Encryption keeps the subject visible for routing. Standard S/MIME does not encrypt the subject. Portal-based delivery systems show the subject in the notification email.
That gap matters when the subject conveys sensitive information. A subject like “MRI results for John Smith” is protected health information even before the body is opened. Encrypting the body does not change that.
Best practice is to write subject lines that carry no PHI or sensitive detail. Use neutral phrasing like “Report from clinic” or “Follow-up available in portal”. Keep sensitive content in the encrypted body.
S/MIME 4.0 introduced an extension for subject line encryption, but adoption is limited. Both sender and recipient clients must support the extension for it to work, which rules out most cross-organization exchanges.
Silent Failures Are the Biggest Risk
Subject-line triggers have a specific failure mode that catches practices off guard. Staff type the trigger word slightly wrong. The rule does not match. The message goes out unencrypted with no error and no notification.
Common misfires include typos like “secre”, missing brackets on a tag-style trigger, capitalization that a case-sensitive regex misses, or extra whitespace inside the tag. Each misfire produces a plain text send.
The Microsoft 365 message trace tool and Google Workspace email log search can show whether a specific message hit the rule. But that check happens after the fact, once someone notices a problem. Nothing stops the send in real time when the trigger word is wrong.
Compliance teams often add a second rule as a safety net. A data loss prevention rule that scans the body for patient data patterns triggers encryption independent of the subject line. That gives coverage when the subject-line trigger fails.
Comparison of Subject-Line Trigger Approaches
The table below compares the three main ways organizations implement subject-line encryption triggers.
| Approach | Config location | False positive risk | Failure mode | Best fit |
|---|---|---|---|---|
| Bare keyword such as secure | Exchange mail flow rule or Workspace content compliance | High | Silent send on typo | Small teams with clear conventions |
| Bracketed tag such as [secure] | Same | Low | Silent send on missing bracket | Multi-department practices |
| Custom identifier such as [PHI-SEND] | Same | Very low | Silent send on typo | Regulated organizations with formal policy |
| DLP body scan as backup | Additional rule | Depends on pattern | Overly aggressive matches | Any environment with sensitive data |
| Default-encrypt every outgoing message | Dedicated service | None | None | Solo and small practices without IT |
Practices that want zero staff training overhead and no silent failure risk often route outbound mail through a secure email service that encrypts every message by default without any subject line convention.
[mh_protip]
Staff Training Determines Whether the Trigger Works
A subject-line trigger only works as well as the training that supports it. New hires need clear documentation on which keyword the tenant uses, where it goes in the subject, and how to verify the message was encrypted.
Verification is the piece most training programs skip. Staff should know how to confirm a message was encrypted. In Outlook and OWA, sent messages that hit the encryption rule show a small lock icon in the Sent Items folder. In Gmail, a portal-encrypted send generates a corresponding sent message with a portal reference.
Quarterly reviews of the mail flow rule hit rate catch policy drift. If the rule fires 200 times a month one quarter and 50 the next, either send patterns changed or staff forgot the convention. Both cases warrant a refresher.
Practice managers building patient communication protocols benefit from aligning the encryption trigger with the broader intake and follow-up flow. Guidance on security features for healthcare websites covers the surrounding controls that make subject conventions credible to compliance auditors.
When Default-Encrypt Beats a Subject-Line Trigger
Default-encrypt tools apply encryption to every outgoing message regardless of subject content. That approach removes the user decision point entirely. Staff never forget the keyword because there is no keyword.
The tradeoff is that every message goes through the portal experience on the recipient side, including routine confirmations and appointment reminders that could travel in plain text safely. Some recipients find the portal step friction.
Mailhippo works with existing Gmail and Outlook accounts, applies encryption automatically to every outbound message, and includes a business associate agreement in the base plan. There is no PGP key exchange, no S/MIME certificate distribution, and no subject-line convention for staff to remember. One brief mention here in case a default-encrypt model fits the practice better than a keyword rule.
Multi-location dental groups and therapy practices with rotating front desk staff often find the default-encrypt approach cheaper to operate than maintaining transport rules across an Exchange tenant. Fewer moving parts means fewer chances for silent failure.
Related Encryption Setup Steps to Verify
A subject-line trigger is one piece of an encryption program. Several related controls determine whether the trigger produces the intended result end to end.
Verify each item before treating the trigger as production ready:
- The tenant plan actually includes Office 365 Message Encryption or the Workspace encryption route configured on the rule.
- A business associate agreement covers the specific encryption feature in use, not just the mailbox.
- External recipients on major providers can decrypt without setup on their end.
- The mail flow rule is enabled, not just saved as a draft.
- A DLP rule provides backup coverage when the subject line trigger misses.
For a related walk-through on the broader encryption options across major clients, see the guide on does https encrypt email. That article covers the transport layer versus body encryption distinction that determines what a subject-line trigger can realistically enforce.
Practices in healthcare that want to align patient-facing communication with the encryption layer sitting behind it often work with a healthcare SEO services partner to make sure the site messaging matches the security posture staff execute in the inbox.
[mh_faqs]
