The short answer
Outlook on the web does not use the certificate store on your PC. It validates S/MIME signatures against a collection of issuer certificates held inside your Microsoft 365 tenant, and as of September 2026 that collection arrives empty. Classic Outlook for Windows reads the Windows certificate store instead, which already trusts the public roots, so the same message is trusted on the desktop and reported as untrusted in the browser. The fix is not a new certificate. An administrator exports the issuing chain as an SST file and publishes it with Set-SmimeConfig -SMIMECertificateIssuingCA, then waits an hour or so for the change to take effect.
Which trust store is your Outlook using?
Two families of Outlook client answer the question “do I trust who signed this?” from two different places. Classic Outlook for Windows asks the Windows certificate store on that machine, and Outlook for Mac asks the keychain. Both stores already carry the public root certificates the operating system ships and keeps updated, so a certificate from a publicly trusted authority verifies without anyone configuring anything. Outlook on the web asks Exchange Online instead, and Exchange Online keeps its own collection of issuer certificates for exactly this purpose.
That second collection is the part nobody expects. Microsoft documents it as a virtual certificate collection: a store, held in the service rather than on any device, containing the root and intermediate certificates used to validate S/MIME. It is not inherited from the Windows root program, it is not populated by your certificate authority when you buy from them, and it is not filled in by the act of installing a certificate on a laptop. It is a tenant-level setting, and a new tenant has nothing in it.
Read that alongside the symptom and the whole thing stops being mysterious. A user installs a perfectly good S/MIME certificate, signs a message from the desktop, and it looks right. The same user opens their own sent item in a browser and sees a warning. Nothing about the certificate changed between those two moments. A different store was asked, and that store had never heard of the issuer.
It is worth being precise about the boundary of this problem, because a lot of time gets wasted on the wrong side of it. The tenant collection governs how your own users’ clients judge signatures. It has no bearing on how a recipient at another company sees mail you send. If your complaint is that customers see a warning on your signed mail, the tenant is not where you fix it, and we come back to that at the end.
What the message actually means
Outlook reports several different failures in language that all sounds like tampering, which is why these tickets arrive sounding more alarming than they are. A signature can fail because the issuer is unknown, because the chain is incomplete, because the certificate has expired, because the signing address does not match the sender, or because a revocation check could not complete. Only one of those means anything is actually wrong with the message, and it is not the common one.
The wording shifts between clients and versions, so match on the shape of the complaint rather than the exact sentence:
| What you see | What failed | Where to look |
|---|---|---|
| The certificate used to sign this message is not trusted by your organisation | Chain building. The client cannot reach a root it trusts | The tenant collection, if this only happens in the browser |
| Trusted in classic Outlook, untrusted everywhere else | Nothing. Two stores, two answers | Publish the issuing chain to the tenant |
| Untrusted in every client, including the desktop | The signature itself: a missing intermediate or an expired certificate | The message, not the client |
| No option to sign, or the sign button does nothing | No usable certificate found for this mailbox | Address match and private key |
| Reading works, sending is blocked | A revocation lookup that cannot complete | Network egress to the CA, and the CRL settings |
The second row is the one worth memorising. A difference between clients is diagnostic information, not a contradiction to be resolved. It tells you the certificate is fine and points straight at the tenant.
Publishing your CA to the tenant
Publishing an issuer takes two commands and about an hour of patience. You export the issuing chain into a serialized certificate store file, a single file with the .sst extension that holds several certificates at once, and then you hand that file to Exchange Online with Set-SmimeConfig -SMIMECertificateIssuingCA. Microsoft documents the SST as the container for the certificate authority signing and intermediate certificate information, and it is the only supported way to tell the service which issuers you accept.
Start on a machine that already trusts the chain, which in practice means a Windows PC where the same certificate verifies cleanly. Export the root and every intermediate together, using the SST type so they land in one file:
Get-ChildItem -Path Cert:\LocalMachine\CA, Cert:\LocalMachine\Root |
Where-Object { $_.Subject -match 'Your CA Name' } |
Export-Certificate -FilePath C:\certs\smime-issuers.sst -Type SSTThen connect to Exchange Online PowerShell and publish it. The parameter expects the file as bytes rather than a path, and Microsoft gives the exact syntax:
Set-SmimeConfig -SMIMECertificateIssuingCA ([System.IO.File]::ReadAllBytes('C:\certs\smime-issuers.sst'))
Get-SmimeConfig | Format-ListThree things go wrong at this point, and all three are quiet failures rather than errors. The first is exporting only the root: the service then has a trust anchor but no path to your certificate, and the symptom is identical to having published nothing. Build the file with every intermediate in it, and build it in one pass with all the issuers your organisation needs rather than one authority at a time.
The second is impatience. The change has to propagate through the service, and an hour or more before it takes effect is normal rather than a sign of failure. Administrators re-run the command four times in twenty minutes, change the file in between, and lose track of what they actually published. Run it once, check it with Get-SmimeConfig, and go and do something else.
The third is testing with the wrong message. Reopening a signed message you looked at ten minutes ago is not a clean test. Have someone sign a new one and open that, ideally in a browser session you have just refreshed.
When the certificate is the problem
If the signature is doubted in every client, including classic Outlook on a machine that trusts the issuer, the fault travels with the message and no tenant setting will help. Four causes account for nearly all of these, and you can check all four against the certificate itself in a couple of minutes.
The address does not match. S/MIME binds a signature to a mailbox: the certificate has to carry the sender’s SMTP address, normally in the subject alternative name. Send from an alias, a shared mailbox or a secondary account with a certificate issued to your primary address and the client will either refuse to sign or produce a signature recipients cannot tie to the sender. This is the most common cause of a sign option that appears to do nothing at all.
An intermediate is missing from the signature. Signed mail normally carries the issuing chain along with it. If the certificate was imported without its intermediates, the message goes out with a gap in the middle, and every recipient whose store does not happen to contain that intermediate sees an untrusted signature. Re-import the certificate from the original PKCS #12 file, including the full chain, and sign again.
The certificate has expired. Worth stating because it produces a warning that reads like tampering. Unlike a timestamped code signature, an ordinary S/MIME signature does not stay convincingly valid forever after the certificate lapses, which is one of several reasons old signed mail starts looking suspect long after anyone touched it. We covered what expiry does to an existing archive in our guide to S/MIME renewal.
The private key is not there. A certificate imported without its key verifies other people’s mail perfectly well and cannot sign a single message of your own. In the Windows certificate store the giveaway is the missing key icon on the certificate, and the fix is to re-import from the .pfx or .p12 rather than from a .cer file.
When a revocation check is blocking you
There is a distinct failure that looks nothing like a trust problem until you know to look for it: incoming signed mail verifies normally, and outgoing signed or encrypted mail will not send. That pattern points at revocation checking rather than trust. Exchange Online can be set to require a successful certificate revocation list lookup when a message is sent, and Microsoft documents that when the CRL distribution point cannot be reached, the user gets a warning dialog and the message is not sent.
Egress filtering is the usual culprit. A CRL lives at an HTTP URL published inside the certificate, and networks that carefully allow only HTTPS to a short list of destinations block it without anyone noticing until someone tries to sign an email. The behaviour is configurable, and the same S/MIME configuration you used to publish the issuer carries the switches:
| Setting | What it does | Symptom when it bites |
|---|---|---|
| OWACheckCRLOnSend | Requires a successful CRL check before a message goes out | Warning dialog and a blocked send when the CRL is unreachable |
| OWADisableCRLCheck | Turns revocation checking off, which speeds validation up | Revoked certificates validate happily. Use with care |
| OWAAllowUserChoiceOfSigningCertificate | Lets users pick which certificate signs | When off, the eligible certificate with the newest NotBefore date wins |
| OWAClearSign | Chooses clear-signed rather than opaque-signed messages | Opaque signatures are unreadable in clients without S/MIME support |
The third row explains a complaint that otherwise makes no sense. A user renews, keeps the old certificate installed, and finds that mail is being signed with the wrong one. With user choice disabled, the client picks the eligible certificate with the most recent NotBefore value rather than the one the user has in mind. Removing the superseded certificate is usually simpler than changing the policy.
Reach for OWADisableCRLCheck last, and preferably not at all. Turning revocation checking off makes the symptom disappear by agreeing to validate certificates that may have been revoked, which is a strange trade to make on the security feature you deployed specifically to prove who sent something. Opening the CRL endpoint on the firewall solves the same problem without giving anything away.
Mobile, new Outlook and the Mac
New Outlook for Windows behaves like the browser client rather than like the classic desktop app, which is the practical thing to know when users are being migrated onto it. Existing S/MIME certificates keep working and Microsoft has continued adding to the feature through 2026, including storing recipients’ certificates in contacts and extending S/MIME to shared and delegate mailboxes. What changes underneath is where trust decisions come from, so a fleet that was fine on classic Outlook can start reporting untrusted signatures the week it moves, with no certificate having changed.
That timing catches people out. The migration is blamed for breaking S/MIME, when what actually happened is that a tenant-side gap which had always been there finally started being consulted. If you have a new Outlook rollout on the calendar, publish your issuer collection before it starts rather than during the support surge.
Outlook for iOS and Android also depend on the tenant configuration, with the user’s own certificate typically delivered through device management rather than installed by hand. Outlook for Mac sits with the desktop family and reads the keychain. And there is one long-standing gap worth checking before you debug anything: S/MIME in these clients is a work or school account feature, so a personal Microsoft account will not do it however the tenant is configured.
If you are rolling S/MIME out across a team rather than fixing one mailbox, the certificate side of that has its own complications around key custody and what happens when someone leaves, which we work through in our guide to running S/MIME for a team. The S/MIME certificates we issue for individuals and organisations come from a publicly trusted authority, which matters here for one specific reason: it is the chain you will be publishing to your tenant, and the same chain your recipients’ clients have to recognise.
A diagnosis order that takes ten minutes
Work through these in order and you will land on the cause without changing anything you later have to change back. The first test is the one that matters: it splits every case in this article into two halves, and it costs thirty seconds.
- Open the same message in classic Outlook on a Windows PC. Trusted there and doubted in the browser means the tenant collection is missing the issuer, and you can skip straight to publishing the chain.
- Check what the tenant already has. Run Get-SmimeConfig and look at what is stored before you publish anything, so you know whether you are filling an empty collection or replacing a working one.
- Inspect the chain in the signed message. Open the signature details and confirm the intermediates are present. A chain that stops short of a root is the failure that looks identical in every client.
- Compare the certificate address to the mailbox. The sending address has to appear in the certificate. Aliases and shared mailboxes are where this quietly goes wrong.
- Test whether sending is what is broken. If reading is fine and sending is not, stop looking at trust and check that the CRL distribution point in the certificate is reachable from your network.
- Publish, then wait properly. One Set-SmimeConfig run, one Get-SmimeConfig to confirm, an hour of patience, then a freshly signed message as the test.
One case does not appear on that list because no amount of configuration reaches it. If the people seeing warnings are outside your organisation, their clients are applying their own trust rules and your tenant settings are irrelevant to them. The only thing that travels is the certificate itself, which is why the choice of a widely distributed publicly trusted issuer matters more for external mail than any setting discussed above. If that is where you have landed, the useful next reading is how certificate trust stores decide what is trusted, because the answer for external recipients lives entirely in stores you do not administer.
FAQ
If you are buying rather than debugging
My-SSL is a Certum partner, so the S/MIME certificates ordered here come from an authority already present in the major root programs. That is the part you cannot configure your way out of afterwards: your tenant collection is yours to publish, but the store on a recipient’s phone is not. If you are setting this up for a team, the individual and organisation S/MIME certificates we issue are listed with their validation requirements, and our team can tell you which chain you will need to publish to Exchange Online before you place an order.