DKIM, S/MIME and OpenPGP can all involve digital signatures, but they do not make the same assertion. Start with the protection you need: domain accountability, integrity of a signed message entity, confidentiality for a recipient or confidence in a particular key holder. No label alone establishes that a payment request is authorized.
Follow one message path
Imagine an author composing a message, a sending server applying DKIM, a gateway adding a footer and a recipient opening the result. DKIM connects selected headers and the canonicalized body to a signing domain. The receiver uses the selector and domain to locate the public key in DNS. It does not encrypt the content. A footer modification can break the body hash, depending on the signed scope and processing. RFC 6376.
S/MIME operates on MIME message entities using certificate-based cryptography. Signing and encryption are distinct operations: a signed-only message is not confidential. The recipient must validate the relevant certificate and identity binding under its trust policy. Encrypting to a recipient certificate protects the encrypted entity for the corresponding private-key holder; it does not hide every outer routing field. RFC 8551.
OpenPGP defines key, signature and encrypted-data formats. A valid signature proves a relationship to a key, while the user's confidence that the key belongs to the intended correspondent depends on a verified binding and local trust decisions. Encryption and signing are again separate. Email packaging and client interoperability need their own implementation checks. RFC 9580.
Compare threats without collapsing identities
For a forged domain-level sender path, DKIM contributes domain authentication and can provide an aligned DMARC path. For an intermediary altering signed content, an applicable S/MIME or OpenPGP signature can reveal modification when verified correctly. For a passive party reading message content, appropriate encryption addresses confidentiality; a signature alone does not.
None of these statements means the endpoint is safe. A compromised private key or authorized account can produce cryptographically valid material. Nor does any signature make an invoice correct. Key lifecycle, recipient validation and independent business approval remain necessary.
Use a bounded control matrix
The following documentary comparison supplies the five choices directly. It describes intended protection when correctly implemented, not verified interoperability.
- DKIM: selected headers and canonicalized body associated with a signing domain; no confidentiality. A footer changing covered canonicalized bytes may invalidate the signature.
- Signed-only S/MIME: signed MIME entity associated with a validated certificate key; no confidentiality. A changed signed entity can fail verification, while an outer modification requires scope inspection.
- Encrypted S/MIME: encrypted MIME entity protected for intended recipient key holders; outer routing fields can remain visible. Encryption alone does not authenticate the author.
- Signed-only OpenPGP: signed data associated with a key whose correspondent binding must be verified; no confidentiality. Altering covered data can invalidate verification.
- Encrypted OpenPGP: encrypted data protected for intended key holders; packaging and exposed metadata still need review. Encryption alone is not sender authorization.
No cryptographic operations, client round trips or gateway tests were executed for this comparison. Combining signing and encryption is possible; ordering and packaging must be tested on the actual route. An added gateway footer outside the encrypted or signed entity has a different effect from changing that entity. Keep those cases separate instead of assigning a universal survives-forwarding result.
Select and validate the combination
Write the required identity and protected scope into the acceptance criteria. Verify key enrollment, loss and revocation handling, algorithm support, forwarding behavior and recipients outside the organization. Inspect what users actually see when validation fails. DKIM can coexist with end-user signing or encryption; adding one does not make the others redundant. Keep a documented recovery path that does not silently downgrade the intended protection.