If it opened without a key, it wasn't encrypted. It was probably signed by the sender, and if you have the sender's public key (out of band) then you can verify the signature.
The point of S/MIME is the same as PGP, but geared for corporate use. It's not good, and people should use Signal instead, but when used for encryption it does provide encryption.
The people who downvote this answer because they don't like me saying PGP and S/MIME are not good and should not be used, should read the "Johnny-You-Are-Fired" paper about PGP and S/MIME signatures.
My reply to a comment got too long so I post it here:
@martijnbrinkers in practice you are wrong.
A standard for doing something between you and another person is only good and useful if there is a high chance the other person will (1) have an implementation and (2) that the implementation they have is good.
If no one uses the standard (e.g. too hard to implement or expensive) then it's no good.
If the major implementations are not good then it's no good.
Take for example TLS. If only an implementation you never heard about had the bug we would agree the bug doesn't mean anything about TLS. But if every major implementation had the bug, like poodle and lucky13 variants, we say TLS was a bad standard (fixed in TLS 1.3).
Back to secure mail, Thunderbird, Outlook, Apple mail all fell? Interoperability with a random implementation used by other side is likely insecure? The standard is bad.
If it's only secure to use if you are sure the counterparty verifies signatures and decrypts using gpg command line outside their mail client, it's not good.
And even when all these bugs are fixed, it's not using authenticated encryption, there is no forward secrecy, the non repudiation is too strong, the metadata is problematic, etc. etc.