Add Digital Signature (S/MIME + RSA-PSS padding) to outgoing email in Exchange Server 2003/2007/2010/2013/2016/2019 and IIS SMTP Service

Digital signature ensures authenticity and data integrity between the email sender and recipient. It gives the recipient an assurance that the sender is who he claims to be and the email content was not altered in transit.

How S/MIME work

After an email was signed and arrived in the recipient’s email client, the email client will verify the email content with the sender’s public key and validate the certificate chain through trusted certification authorities. If the email content was changed or the certificate chain is invalid, the email client will warn the recipient.

Use Digital Signature (S/MIME) in Email Client

Most popular email clients support email digital signature. To setup digital signature in your email client, you need a digital certificate with a private key for the sender’s email address. You can refer to the documentation of your email client for the settings.

This tutorial introduces how to use S/MIME Plugin to add digital signature to an email in IIS SMTP Service or Exchange 2003 automatically without an email client. If you send emails from an email tool that doesn’t support digital signature, this plugin can help to sign email on server side.

How S/MIME Plugin Works?

In IIS SMTP Service or Exchange 2003, S/MIME Plugin works as a SMTP event sink; In Exchange 2007/2010/2013/2016, it works as a transport agent. It adds digital signature to an email based on pre-defined rules.

A digital signature rule can be defined for a single sender or multiple senders.

How Disclaimer plugin works with digital signature in Exchange Server

Import, Export and Generate Test Certificate

To view/import/export certificate in Current User Store and Local Machine Store, you can open the Certificates MMC Snap-in like this:

Certificates MMC Snap-in

Now you can view all certificates in current user store and local machine store.

As S/MIME Plug can’t access certificates from the Current User Store, if your certificate is stored in the Current User Store, you must export it from the Current User Store.

Export Certificate from Certificate Store

You can export certificate(s) from Current User Store like this:

Export certificate to pfx file

You can use exported pfx file as Certificate Source in S/MIME Plugin.


If you selected No, doesn't export private key, you can export the certificate as .cer, or pfx and sst (multiple certificate selected). The certificate without a private key is used for email encryption only.

Pfx, Cert and Sst file

Import Certificate to Certificate Store

You can import a certificate file to Certificate Machine Store like this:

Import certificate to certificate machine store

After certificate file was imported to Certificate Machine Store, you can use Certificate Machine Store as Certificate Source instead of certificate file.

Generate Self-Signed Root Certificate

If the email digital certificate is not issued by third-party authorities, the email client will prompt an error of “Certificate is not issued by a trusted publisher”.

However, for internal enterprise usage or test purpose, you can create a self-signed root certificate and issue this digital certificate to internal users by New-SelfSignedCertificate PowerShell cmdlet.


If you have an existing certificate from third-party authorities, you can skip this section.


New-SelfSignedCertificate requires PowerShell 3.0 on Windows 10, Windows 8/8.1 and Windows Server 2012/2012 R2/2016.

You can create a root certificate like this:

New-SelfSignedCertificate -Type Custom -HashAlgorithm sha256 -KeyLength 2048 -KeyUsage CRLSign, CertSign, KeyAgreement, DataEncipherment, KeyEncipherment, DigitalSignature -KeyAlgorithm RSA -Subject "CN=Test Root V1" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (get-date).AddDays(7300)

Then the new root certificate can be found in Certificates MMC Snap-in, select Certificates - Current User -> Personal -> Certificates.

Test root certificate

Now you can issue the certificate to users from root certificate like this:

Generate Email Certificate Issued by Root Certificate

Here is an example to issue the certificate from the root certificate generated in the previous section.

Set-Location -path cert:\CurrentUser\My
$signer = Get-Childitem -DnsName "Test Root V1"
New-SelfSignedCertificate -HashAlgorithm sha256 -Type Custom -Subject ",CN=SMIME Tester 2048" -TextExtension @("{text}","{text}") -KeyLength 2048 -KeyAlgorithm RSA -SmimeCapabilities -CertStoreLocation "Cert:\CurrentUser\My" -NotAfter (get-date).AddDays(365) -Signer $signer			

Then the new email certificate can be found in Certificates MMC Snap-in, select Certificates - Current User -> Personal -> Certificates.

Test root certificate

You can export it together with a private key as a pfx file and use it in Certificate Source. Alternatively, you can install a pfx file to Certificates (Local Computer) -> Personal -> Certificates and use Machine Store as Certificate Source.

Install Root Certificate to Client Machine

If you used the above certificate to sign emails, email client would give an error about Certificate is not issued by a trusted publisher. You can install the root certificate to client machines like this to avoid the error.

Now you can export the root certificate to a cert file and install it on Trusted Root Certification Authorities:

Export test root certificate

Install it to Local\Computer\Trusted Root Certification Authorities

Install it to Current User\Trusted Root Certification Authorities

After you installed the root certificate to Trusted Root Certification Authorities, user certificate chain becomes valid now.

User certificate chain

Create a Rule for Digital Signature

You can create a test digital signature rule for a user like this:

Create digital signature rule in Exchange Server


IIS SMTP Service is running as Local System user, and Exchange Transport Agent is running as Network Service user, so do not put the certificate file to Desktop or user-dependent folder, S/MIME Plugin doesn’t have permission to read certificate files in these locations.

After rule is saved, click Test, current rule will be executed with a virtual email message, you can find the result in test dialog box.

If Test all rules is checked, all rules defined on current machine will be executed with a virtual email message.

Test digital signature in Exchange Server

If the test result looks good, you can send a test email from that user, and validate if the received email was digital signed.

Certificate Private Key Permission

Signing email requires certificate private key, if you got Access Denied error in Debug Log, you can solve it like this:

If Certificate Source is pfx file, you can import it to Certificate Machine Store by Import Certificate to Certificate Store at first, then change Certificate Source to Certificate Machine Store.

Now you can change the private key permission like this:

Change certificate private key permission

Sender Address Pattern and Wildcard

A single email address or email address with wildcard (* and ?) can be used in Sender Address. It indicates current rule is only enabled for matched sender address.

A digital certificate can only be used for a specific email address. For example, you cannot use's certificate to sign, email client would prompt an error due to address not match.

Therefore, if you used wildcard (* and ?) in sender address, you should specify a Certificate Source that contains multiple certificates, and set Certificate Match Rule to Match certificate by sender email address, to enable S/MIME Plugin to find the correct certificate to sign the email.


If no certificate is identified for the current sender, the message won’t be signed.

Certificate Source and Certificate Match Rule

Certificate Source

Both machine store and pfx file can contain multiple certificates. Please refer to Import, Export and Generate Test Certificate to learn how to import/export certificate from the certificate store.

Certificate Match Rule

Signature Hash Algorithm

Sha1, Sha256, Sha384 and Sha512 are supported. For security reason, you should use Sha256, Sha384 or Sha512 hash algorithm.

RSA-PSS Padding in Digital Signature

To comply with EDIFACT in Germany/EUROPE, please check this option and use sha256 or higher SHA algorithm. If RSA-PSS padding in signature is used, because most email clients don’t support RSA-PSS signature verification, so they would report error for the digital signature. However it can be verified by EDIFACT authorities.

To use this feature, it also requires .NET framework 2.0, 4.0 or 4.61 installed on the server. Because .NET framework 2.0/4.0 is built-in feature in modern Windows Server, so you don’t have to install .NET framework manually in most cases.

Sign Tnef Message

Tnef is an internal email format in Exchange Server. If this option is checked, Tnef messages will first be converted to RFC822/message format by S/MIME Plugin, and then be signed by the specified certificate.

Detached Signature

If this option is checked, the signature is detached from email original data.

See Also

Email Disclaimer
Email Encryption
Journal and Troubleshooting
Appendix - Set up DomainKeys/DKIM
Appendix - Set up SPF record in DNS server

Online Tutorials:

Add Disclaimer or Signature with Embedded Images in Exchange Server 2007/2010/2013/2016/2019 - Tutorial
Add Digital Signature (S/MIME) to Email in Exchange Server 2007/2010/2013/2016/2019 - Tutorial
Encrypt Email (S/MIME) in Exchange Server 2007/2010/2013/2016/2019 - Tutorial

Add Disclaimer or Signature with Embedded Images in IIS SMTP Service and Exchange Server 2003 - Tutorial
Add Digital Signature (S/MIME) to Email in IIS SMTP Service and Exchange Server 2003 - Tutorial
Encrypt Email (S/MIME) in IIS SMTP Service and Exchange Server 2003 - Tutorial