Encrypted Email for CUI: S/MIME, Sensitivity Labels, and OME

CUI that moves through email needs cryptographic protection and policy controls that match NIST SP 800-171. The rule set does not name a product. You can meet the requirement with S/MIME or with Microsoft Purview encryption through sensitivity labels or Microsoft Purview Message Encryption, if you design and operate the controls to satisfy the practices and you can show evidence.

Regulatory expectations for encrypting CUI in email

NIST SP 800-171 Rev. 2 calls for two things that drive your email design. Control SC.L2-3.13.8 tells you to implement cryptographic mechanisms that prevent unauthorized disclosure of CUI during transmission unless the path already has protection. Control SC.L2-3.13.11 tells you to use FIPS-validated cryptography when that cryptography protects CUI confidentiality. Control AC.L2-3.1.3 tells you to control the flow of CUI in line with authorizations, which includes outbound email.

NIST SP 800-171A explains how assessors check those practices. Assessors examine your policies and observe the mechanisms you use to protect CUI in transit and to control CUI flow. They look for effective configuration and use, not a specific brand.

DoD sets the contractual hook in DFARS 252.204-7012. That clause points you to NIST SP 800-171 for protecting covered defense information on your systems, which includes CUI in email. DFARS 252.204-7019 sets expectations for assessment reporting. Neither clause names an email encryption product.

The CMMC final rule places Level 2 on the NIST SP 800-171 control set for CUI environments and leaves the technology choice to you. The DoD CIO CMMC Level 2 Assessment Guide gives examples, including TLS, IPsec, or application-layer encryption for non-federal networks, and it aligns with the same evidence focus. NIST SP 800-171 Rev. 3 keeps the same outcomes for protecting CUI in transit and for FIPS-validated cryptography. The CUI Registry adds handling and marking direction for email and points you to any extra safeguards that a category may impose.

You must select a design, document it in the SSP, and show that your implementation uses FIPS-validated cryptography where it protects CUI. Your policy must control who can send CUI, where they can send it, and which protection applies.

S/MIME protection model

You can use S/MIME to encrypt and sign email. Outlook and Outlook on the web support S/MIME when the user installs an S/MIME certificate. Outlook can encrypt every message or only selected ones. Outlook warns when it cannot find a recipient public key, which prevents blind sends to recipients who cannot decrypt.

S/MIME uses the recipient public key to encrypt the message. The recipient private key enables decryption. A sender can also sign a message to provide integrity and sender authenticity. Your PKI team must issue, renew, and revoke user certificates. Your directory team must publish recipient public keys so senders can find them. Your help desk must support key recovery procedures that align with policy.

You must confirm that the S/MIME stack you deploy uses FIPS-validated modules when those modules protect CUI. You must train users on recipient readiness. A sender who picks S/MIME encryption must confirm that every intended recipient can decrypt before sending.

Sensitivity label encryption in Microsoft 365

You can use Microsoft Purview sensitivity labels to encrypt email. Administrators configure labels to restrict access to users and groups, set usage rights such as Do Not Forward, and keep protection with the content after send. Microsoft implements this through Microsoft Purview Information Protection, also known as Azure Rights Management.

Administrators can set external access behavior in the label. You can require authentication with a Microsoft account. You can permit access through a one-time passcode. Labels can scope access to named domains or users and can limit access to internal users when policy forbids external transmission. Microsoft documents advanced options such as double-key encryption for stronger key control.

Microsoft supports label-based encryption in commercial, GCC, and GCC High. Feature parity can vary across clouds and over time, so you should verify required options in your tenant before you lock a design.

Label policy design touches more than the mail app. Your Conditional Access team must control where users can open protected content. Your DLP team can use rules to suggest or require a label on email that matches CUI patterns. Your records team must align retention behavior with protected content. Your SSP must describe how the tenant keys and label policies protect CUI across messages and attachments. See Microsoft Purview DLP for CUI and System Security Plan for NIST 800-171.

Microsoft Purview Message Encryption for external recipients

You can use Microsoft Purview Message Encryption (OME) to encrypt messages to internal or external recipients. OME builds on Azure Rights Management. Outlook includes an Encrypt button that invokes OME when your tenant has the required licensing. Users can pick Encrypt or Do Not Forward. Administrators can drive OME through Exchange mail flow rules based on recipients, keywords, or DLP matches.

Many partner domains do not natively open protected messages. In those cases, OME delivers a wrapper message that points the recipient to a secure viewer. The recipient signs in with a Microsoft account or uses a one-time passcode, then reads the message and attachments in the viewer. Microsoft documents this behavior and the fallback for recipients on common webmail platforms.

Microsoft supports OME in commercial, GCC, and GCC High. Microsoft’s public sector guidance explains the compliance positioning of those clouds and reminds you that you must configure encryption and access controls to meet your framework.

Design choices and tradeoffs

Sensitivity-label encryption and S/MIME do not combine on the same message. Microsoft documents that Outlook cannot apply S/MIME and IRM-based protection together. You must choose one per message. You can run both patterns in the tenant, with policy steering which one applies.

Keys and trust:

S/MIME uses partner or enterprise PKI for identity and key issuance. You manage cert enrollment, revocation, and publication.
Sensitivity labels and OME use Azure Rights Management for policy enforcement and key services. You manage label scope, rights, and access paths.

Recipient diversity and user experience:

S/MIME requires each external recipient to hold a current decrypting cert. Outlook blocks sends to recipients without a public key.
OME and label-based encryption can reach recipients without S/MIME by using the secure viewer and a Microsoft account or one-time passcode.

Governance and recall:

Sensitivity-label encryption can revoke access after send, enforce Do Not Forward, and expire access. Those controls can bind to attachments.
S/MIME encryption protects the message in transit and at rest in the mailbox. After a recipient decrypts and saves content, you cannot enforce new policy on that copy.

Policy automation:

Exchange mail flow rules and Purview DLP can trigger OME or a label based on recipients or detected CUI. You can reduce user choice and turn policy into a system action.
S/MIME offers limited policy automation. You can encourage signing for integrity, then require encryption for messages that meet a routing rule to specific partner domains that publish public keys.

Access control and device compliance:

Sensitivity-label encryption and OME work with Conditional Access. You can restrict decryption to compliant devices and named locations.
S/MIME decryption happens in the client with the user key. You must enforce device posture with Conditional Access on mailbox access and with endpoint controls on the device.

Archiving and investigation:

Label-based protection uses tenant keys, which supports enterprise eDiscovery within Microsoft 365 services.
S/MIME relies on user keys. You must plan for key escrow and discovery procedures that match your retention and legal hold needs.

Program governance:

You must align the chosen pattern with your CUI boundary. Scope which users and domains can handle CUI, then bind policy to that scope. See CMMC scoping your CUI boundary.
You must train senders on which option to use for each partner and on signs that an external recipient cannot open a protected message, such as Outlook warnings for S/MIME or partner complaints about the OME viewer.

Across all choices, you must meet the cryptographic requirements in SC.L2-3.13.8 and SC.L2-3.13.11, and the flow-control requirement in AC.L2-3.1.3. You must confirm that cryptography that protects CUI uses FIPS-validated modules. You must document the design, including key management, partner onboarding, fallback behavior, and incident response steps for misdirected messages. You must test external workflows with key suppliers and primes.

Practical configuration notes

Outlook supports S/MIME and OME from the compose experience. Outlook warns if it cannot confirm decryption readiness for all recipients on an S/MIME-encrypted message. Users can sign every message with S/MIME to provide integrity, then apply encryption where policy requires it.

Purview sensitivity labels can apply encryption at compose time or through auto-labeling rules. Administrators can route messages through OME when a label applies to the email. Administrators can set external access behavior in the label, including named domains and authentication choices. You should avoid label sprawl and keep the number of email-usable labels low.

Exchange mail flow rules can enforce encryption for messages that match partner domains or CUI indicators. You can pair those rules with DLP to reduce false positives and reduce manual steps for senders. You can add Conditional Access policy to control where users open protected content, which strengthens your DFARS 7012 story for controlled access to CUI email. See Conditional Access and DFARS 7012.

Your architecture can support both S/MIME and OME or label encryption in the same tenant. Use S/MIME for partners who insist on it and who share public keys with you. Use OME or label encryption for partners who do not operate S/MIME and who accept the OME viewer. Publish clear rules to users so they pick the right path.

Bottom line for CUI email

NIST and CMMC expect you to protect CUI during transmission with cryptography and to control who can send and receive it. Microsoft 365 gives you two workable patterns. S/MIME uses partner or enterprise PKI and fits partners who standardize on that model. Purview encryption through labels or OME uses Azure Rights Management and fits partners who accept protected mail through the viewer or through native support.

You own the selection and the evidence. Write the policy, configure the controls, test with partners, and keep records that show how the system protects CUI in transit and at rest.