How to Digitally Sign Email With Your CAC Safely

Quick answer: Digitally signing email with a CAC uses S/MIME and a signing certificate on the card to help recipients verify the sender and detect changes to the message. Your organization must enable the mailbox/client workflow, the supported email application must see the current CAC signing certificate, and you must choose the signing—not encryption or generic authentication—operation according to component guidance.

A digital signature does not hide the message. Signing provides sender authentication and message integrity; encryption protects content from being read by unauthorized recipients. They use related certificate technology but solve different problems and may use different certificates.

CAC email-signing prerequisites

1. Understand what a digital signature proves

Microsoft describes S/MIME digital signatures as helping recipients verify the sender and confirm that the message has not been altered since signing. The signature includes the signer’s certificate and public-key information needed for validation. The private signing key remains protected by the CAC and is used for the signing operation after PIN authorization.

A signature does not prove that every statement in the email is true, that the recipient is authorized to receive the content, or that the mailbox itself has not been misused in another way. Continue to follow classification, controlled-information, records and recipient-verification rules.

2. Confirm S/MIME is enabled for your environment

Exchange and Microsoft 365 administrators configure S/MIME support, certificate publication, client policies and web controls. The exact workflow differs among classic Outlook, new Outlook, Outlook on the web and other approved clients. If the Sign command or S/MIME settings are absent, confirm client and tenant support before changing certificates.

Do not install a browser extension, S/MIME control or certificate package from an advertisement or unofficial download. Use the organization’s managed deployment, software center or current Microsoft/DoD guidance.

3. Make sure the email client sees the CAC

Connect the approved reader, insert the current CAC and verify the operating system detects the card. If not, use the CAC reader diagnostic before changing Outlook. A client cannot sign through a card it cannot enumerate.

In supported Outlook configurations, review the certificate shown under email security/S/MIME settings. Confirm that it belongs to the current cardholder, is within its validity period and is intended for digital signatures. Do not export the CAC private key or import a copied private-key file to make the certificate appear.

4. Select the correct signing certificate

A CAC may expose certificates for authentication, digital signature and encryption. Use the certificate purpose and current organization instructions—not a universal label such as “always choose EMAIL.” Microsoft’s Outlook certificate settings allow the user or administrator to choose a certificate for digital signatures and, separately, encryption.

If multiple current and old certificates appear, record their displayed subject, issuer, purpose and dates. Do not delete them at random, especially when encrypted historical mail may depend on older encryption keys. Ask the email/help-desk owner to identify the correct signing certificate and approved cleanup process.

5. Sign one test message

Use a controlled, non-sensitive test to an approved recipient. In classic Outlook, Microsoft’s current workflow exposes a Sign command while composing, or a per-message digital-signature option under security settings. Outlook on the web and new Outlook expose S/MIME options only when the account, client and administrator configuration support them.

1. Start a new message in the approved mailbox and client.
2. Confirm the intended recipients and content markings.
3. Enable the digital-signature/S/MIME signing option for that message.
4. Review the certificate if the client asks for a choice.
5. Enter the CAC PIN once for the signing operation you initiated.
6. Send the message and inspect the copy in Sent Items.
7. Have the approved recipient open the signature details and verify its status.

Do not begin by enabling “sign every outgoing message” across the mailbox. Prove the correct certificate and recipient validation first, then follow organization policy for default signing behavior.

6. Verify the signature

The recipient’s S/MIME-capable client should show that the signature is valid, identify the signer/certificate and indicate whether the message changed after signing. A warning may reflect an expired or revoked certificate, an untrusted chain, a name/address mismatch, unavailable revocation data, unsupported algorithm/client or message modification by another system.

Open certificate details rather than judging only by an icon. If the client reports a trust or validation problem, use the DoD certificate-validation diagnostic and preserve the exact status text.

7. Keep signing and encryption separate

Signing uses your private signing key and allows others to verify the message. Encrypting to a recipient uses that recipient’s public encryption certificate; the recipient needs the corresponding private key to read it. A person can often read a signed message without possessing an S/MIME certificate, while an encrypted message requires compatible keys and client support.

Do not encrypt merely because the Sign option works. Confirm recipient certificates, distribution-list behavior, archival/key-recovery requirements and policy first. Losing access to an old encryption private key can make historical encrypted mail unreadable even though signing with a new card works.

8. Troubleshoot by symptom

No Sign or S/MIME option

Verify the mailbox type, Outlook edition/version, tenant policy and whether the organization supports S/MIME in that client. This is often an administrator/client capability issue, not a CAC hardware failure.

No signing certificate appears

Check card detection and whether the current CAC contains the required email/signature certificate. DoD lifecycle guidance notes that an email certificate may be absent when no organization email address was available at issuance; authorized update processes exist through component/DMDC workflows. Contact the sponsor or help desk rather than creating a private certificate yourself.

Repeated PIN prompts

Cancel the loop and use the repeated CAC PIN prompt diagnostic. Separate a legitimate second cryptographic operation from a client session, certificate, provider or actual lockout problem.

Signed message shows invalid or untrusted

Inspect certificate validity, issuer chain, revocation status, sender-address mapping and whether a gateway modified the message. Do not disable validation or tell recipients to ignore the warning.

Signing stopped after CAC renewal

The client may still reference the old signing certificate, while the new CAC presents a different one. Re-select the current certificate through the approved S/MIME configuration and preserve older encryption-key access according to organization policy.

9. Protect the PIN and private key

Enter the PIN only in the expected smart-card dialog for an action you initiated. Never send the PIN, export CAC private keys, approve an unexpected signing prompt or let remote support control the PIN entry. If the card reports blocked after incorrect entries, follow the authorized biometric-reset process rather than attempting a home unlock.

Frequently asked questions

Does signing an email encrypt it?

No. Signing supports identity and integrity; encryption protects message content. A message can be signed, encrypted, both or neither depending on policy and client support.

Which CAC certificate signs email?

Use the certificate designated for digital signatures by your organization/client configuration. Do not select solely by a familiar email label because card profiles and application filtering can differ.

Can I export the CAC signing key?

No. The CAC is designed to protect private-key operations on the token. Do not export, duplicate or upload the private key.

Why can the recipient read the email but not validate the signature?

Reading clear signed content and validating its certificate are separate. The recipient may lack S/MIME support, required trust roots, revocation access or a valid path for the signing certificate.

Official references

• Microsoft Support: Set Up Outlook for S/MIME and Digital Signatures
• Microsoft Support: Digitally Sign Messages in Outlook
• Microsoft Learn: S/MIME Message Signing and Encryption
• DoD ID Card Reference Center: Managing Your CAC
• DoD Manual 1000.13, Volume 1: CAC Email Certificates

Official S/MIME and CAC guidance was checked in August 2026. Your component’s mailbox, client, certificate and information-handling policies take precedence.

For remote mailbox access before S/MIME configuration, use the authorized .mil webmail and CAC access guide to verify URL, device, tenant, mailbox, certificate and policy.