smime.p7s: Why Your Signed Email Arrives as an Attachment

What is the smime.p7s file?

The smime.p7s file is the detached signature block from an S/MIME-signed message. It holds two things: the signature value computed over the message, and the sender's certificate, usually with the certificates that issued it. It does not hold the message, and nothing in it is encrypted. In our test below the file came to 2,970 bytes for a one-line email with a small PDF attached, and opening it in a text editor shows base64 rather than prose.

The name is a convention rather than an accident. The S/MIME specification, RFC 8551, recommends file names for its parts so that receiving software and people can recognise them, which is how signed mail from every sender ends up carrying a part with the same name. The .p7s extension points at PKCS#7, the container format underneath, and the s marks it as a signature. Its sibling, .p7m, holds a whole message, and the difference between the two matters more than the names suggest.

Because the file carries the sender's certificate, a client that processes it also learns how to encrypt mail back to that sender. That is why the usual advice for starting an encrypted exchange is to send each other a signed message first.

What does a signed message actually contain? We tested it

A clear-signed S/MIME message is a two-part MIME envelope: your message as it would have been sent unsigned, followed by a signature part that is labelled as an attachment named smime.p7s. We built one on October 9, 2026 with OpenSSL 3.0.13, signing a short email with a PDF attached, using a throwaway test certificate authority rather than a publicly trusted one, and kept the real output (sender and recipient addresses omitted, most of the base64 cut).

$ openssl cms -sign -in withattach.txt -signer user.crt -inkey user.key \
    -certfile ca.crt ... -subject "Invoice" -out clear.eml

MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
  micalg="sha-256"; boundary="----0F0EA41D20F5F296BD1B1C7896BA67F3"

This is an S/MIME signed message

------0F0EA41D20F5F296BD1B1C7896BA67F3
Content-Type: multipart/mixed; boundary="b1"
  ... the text of the message, then invoice.pdf ...

------0F0EA41D20F5F296BD1B1C7896BA67F3
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIILlgYJKoZIhvcNAQcCoIILhzCCC4MCAQExDTALBglghkgBZQMEAgEw...

Four things in that output explain most smime.p7s questions:

• The signature is marked as an attachment on purpose. Its header says Content-Disposition: attachment with the file name smime.p7s, so software that cannot verify it still has a harmless place to put it.
• It is small. The decoded smime.p7s was 2,970 bytes with our test root certificate included and 1,903 bytes when we signed without it, using 3072-bit RSA keys. The size depends on the certificates inside it, not on the length of the email.
• Your attachment is one level down. The PDF sits inside the first part, under multipart/mixed, not beside the signature.
• The media type has an older spelling. OpenSSL's newer cms command wrote application/pkcs7-signature, the type RFC 8551 specifies, while its older smime command, run on the same input, wrote application/x-pkcs7-signature. You will see both in the wild; they label the same kind of part.

Both messages verified with openssl cms -verify. Then we appended one line to the signed body, the kind of footer a mail gateway adds, and verification of the clear-signed copy failed. The same line appended to the opaque-signed copy left its verification intact. That difference is covered below.

Why does it show up as an attachment?

The smime.p7s file shows up as an attachment because the signature is a MIME part in its own right, labelled as an attachment, and a mail app that does not process S/MIME treats it like any other file: it lists it. The message was built correctly and arrived intact. What differs is whether the receiving software recognises the signature type as something to verify or something to offer for download.

Support questions about this usually arrive framed as a delivery problem: the signature "broke", the certificate is "not working", the message "arrived wrong". None of that is happening. The same message opened in a client that verifies S/MIME shows a signature indicator and no extra file, which is usually the fastest way to settle the question. If the recipient is on Outlook and sees a warning rather than a badge, that is a different fault with its own cause, covered in why Outlook says your S/MIME certificate is not trusted.

smime.p7s or smime.p7m: which are you sending?

A smime.p7s file means the message was clear-signed: it travels as multipart/signed, with a readable body and a detached signature beside it. A smime.p7m file means it was opaque-signed: the body, the formatting and every attachment are sealed inside one PKCS#7 container sent as application/pkcs7-mime. RFC 8551 defines both, says the multipart/signed form is generally preferred for sending, and requires receiving agents to handle both.

Our test shows the difference plainly. The opaque-signed copy of the same email had exactly one MIME part, named smime.p7m, and the name invoice.pdf did not appear anywhere in the raw message. The PDF only reappeared after openssl cms -verify unwrapped the container. A mail app that cannot unwrap it would typically show an empty message with one file attached.

Opaque signing does have a real argument behind it. Because the content is encoded inside the signed container, systems that append disclaimers or rewrite line endings on the way through are far less likely to alter what was signed: in our test, the appended footer broke the clear-signed copy and not the opaque one. If your mail crosses gateways like that, opaque signing is how the signature survives the trip.

So the sensible order is: clear signing by default, opaque signing only when you know your recipients can handle it and you have a specific gateway problem to solve. Choosing opaque signing to make smime.p7s go away turns a cosmetic complaint into a real one.

Which clients verify, and which just attach

Whether a recipient sees a signature indicator or a smime.p7s file depends on whether their mail app processes S/MIME, and for webmail, on whether an administrator has set it up. As of October 2026, the vendors' own documentation describes the main clients like this.

Gmail deserves a caveat rather than a flat answer. Google's FAQ says both that a recipient whose client doesn't support S/MIME receives the certificate as a smime.p7s attachment, and that Gmail on web, Android and iOS won't show S/MIME attachments. Which of those a particular person sees depends on their app and account. Either way, unless the organisation has hosted S/MIME turned on, don't read the absence of a warning as a verified signature.

That point is easy to skate past. An unverified signature part proves nothing. Anybody can attach a file called smime.p7s to a message, and in a client that is not checking it, it looks exactly like a real one.

Why do mail robots lose the real attachments?

Scripts and automation tools that pull attachments out of a mailbox often report that the attachments of signed mail were "replaced by smime.p7s". They were not replaced. Signing wraps the original message one level deeper, and a program that reads only the top-level parts of the message finds exactly two: an unnamed multipart/mixed part and the signature.

We checked this against the test message with Python 3.11's standard email module. Listing only the top-level parts returned the unnamed container and smime.p7s; walking the whole tree returned invoice.pdf and smime.p7s. The fix in any tool is the same: walk the MIME tree recursively, and skip parts of type application/pkcs7-signature or application/x-pkcs7-signature unless you mean to verify them. An opaque-signed message (smime.p7m) is a different case: the files are inside the container and have to be unwrapped first.

What can you change as the sender?

As the sender, you cannot make smime.p7s disappear for a recipient whose mail app does not verify S/MIME, and no certificate or setting changes that. What you can do is keep the fallback harmless and avoid generating the complaint where the signature adds nothing. Four decisions carry most of the practical weight, and all of them are made before the message leaves.

Keep clear signing on. In classic Outlook, Microsoft says the option "Send clear text signed message when sending signed messages" is selected by default. Administrators can pin it with the Office policy "Send all signed messages as clear signed messages", which sets a ClearSign value under HKCU\Software\Policies\Microsoft\Office\16.0\outlook\security. If someone switched clear signing off to tidy up the attachment, that change is a likely cause of reports of empty messages carrying a single smime.p7m file.

Don't sign machine-generated bulk mail. Invoices, notifications and newsletters gain little from a signature that most of their recipients are not equipped to check, and every recipient on a client without S/MIME support gets an unexplained file. Sign correspondence between people, where the identity claim means something.

Sign from the address on the certificate. RFC 8550 says sending agents should make the From or Sender address match an email address in the signer's certificate, and that receiving agents must check that match when the certificate contains addresses. Signing from an alias that is not on the certificate invites a mismatch warning at the far end.

Include your issuing certificates. The signature can carry the certificates between yours and the root, which the recipient's software uses to check the chain. In our test, adding our test CA certificate grew smime.p7s from 1,903 to 2,970 bytes, so that one certificate added about a kilobyte. If you are choosing a certificate for a team rather than fixing one you already have, the validation type and which addresses it covers matter more than the brand; our S/MIME certificates for business email page sets out which validation type covers an individual mailbox and which adds the organisation's name.

You received a smime.p7s file: what should you do?

In most cases, nothing. A clear-signed message is fully readable without a certificate of your own, without extra software, and without opening the attachment. You need a certificate only to sign your own mail or to send encrypted replies. The file is there because your mail app did not process it, and ignoring it costs you only the verification you were not getting anyway.

If the verification matters, use a client that does it. Open the same mailbox in a desktop client with S/MIME support and the signature indicator appears, because the message always contained everything needed to check it. For a Google Workspace domain where this comes up often, hosted S/MIME moves verification to Google's side; it is limited to Frontline Plus, Enterprise Plus and the Education Fundamentals, Standard and Plus editions, and an administrator has to turn it on.

Two things not to do. Don't treat the attachment as proof of anything: in a client that is not verifying, it can be attached by anyone, so a message that looks signed deserves the same scepticism as any other. And don't ask the sender to switch to opaque signing so their mail looks "properly signed". That trades a harmless extra file for an empty message with the real attachments locked inside it. For what the signature would have proved had anything checked it, see what a digital signature actually proves.