A little bit of background: I want to sign my emails for my own safety. None of my intended recipients are users of digital signatures. If one day someone were to impersonate me, I can prove my own identity, and disprove the identity of my impersonator.

I intend to use GPG to produce signatures for my emails. Right now, I am facing a dilemma on how to attach these signatures. Whether to use 'clearsign', 'detached signature', or just plain old 'sign'.

I will elaborate on my thought process, and the pros and cons I came up with, of each form of signatures.

Clear Signature


  • No external program required to read messages
  • Verification can be done easily


  • Intrusive and ugly headers
Hash: SHA256

some message

some signature

Detached Signature


  • No external program required to read messages
  • No intrusive and ugly headers


  • To verify messages, the content must be copied and formatted exactly like how it was when used to produce the signature. Reference here.

Normal Sign


  • No intrusive and ugly headers


  • Require an external program to read messages
  • Or the alternative is, to duplicate the content of the message. One for readability, and another that was baked in the signature, as produced by GPG.
  • When using the alternative, produces longer emails.
  • When using the alternative, to verify a message, one will need to compare the produced output from the baked content in the signature, and the duplicated plain content in the email.

If I were to resort to use 'clearsign', when my recipient don't have a clue in the purpose of digital signatures, the ugly headers will make my emails look unprofessional. I want to ensure any digital signature I attach to be as least intrusive as possible.

I could simply remove the headers. However, the process of verifying signatures becomes no less different than 'detached signature', although less error prone.

If I were to use just the normal 'sign' and duplicate the content for plain reading, in some cases, this procedure defeats the whole point of digital signatures through hashing and getting the fingerprint of the message.

What should I do? What's the norm of attaching signatures to emails? Are there other alternatives that I have yet to consider?

  • "To verify messages, the content must be copied and formatted exactly like how it was when used to produce the signature." - How is this a problem in your use case? In my opinion this is just a technical requirement, not really a problem. Commented May 15, 2021 at 8:21
  • @SteffenUllrich I believe this is a problem because in the process to verify, there is a lot of manual work that has to be done. And this invites opportunities for human error. I think verification should be handled with the least amount of intervention from people. Commented May 15, 2021 at 8:44
  • @SteffenUllrich Although, maybe I'm wrong. In terms of my use case, I could definitely set up some simple scripts to handle it. Thanks for pointing that out. Commented May 15, 2021 at 8:48
  • If there was a single standard way for doing this, there wouldn't be a problem. But there are many standards. Commented May 15, 2021 at 9:28
  • 1
    OP, do you send email from your own domain (e.g. [email protected])? If so, you might want to consider using DKIM to sign your messages. No ugly headers and verification is automatic by most MTA's.
    – mti2935
    Commented May 15, 2021 at 11:41

1 Answer 1


PGP/MIME (RFC 4880 and RFC 3156) is (in my humble opinion) the least intrusive way to PGP-sign mail. It puts the signature into an attachment of type application/pgp-signature using the filename signature.asc, which some email clients will be able to verify and others will at least recognize that it's a cryptographic signature.

However, if you control your server, you could consider using something more broadly adopted: DKIM and DMARC.

DKIM (DomainKeys Identified Mail, RFC 6376) signs your message body as well as several headers (typically From, Date, To, and Subject). Keys are served via DNS and signature verification is decently universal as this (alongside DMARC) is a key defense against spoofing attacks like phishing and Business Email Compromise (BEC).

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) sets a policy: what to do when an email fails to verify its DKIM signature (and is not permitted by SPF – you need an SPF record of v=spf1 ?all, denoting that SPF permits nothing, to effectively require DKIM). DMARC can instruct servers to quarantine or reject non-compliant mail. It also has reporting built in so you can observe what mail might be inappropriately blocked.

This ensures all mail sent by your server is cryptographically signed, that it's verified by nearly all recipients, and that you can instruct recipients to block or quarantine mail that isn't provably from you.

  • Please notice that if you use SPF policy v=spf1 -all for the domain, you would have to use some other hostname as the envelope sender; otherwise the delivery fails. Commented May 21, 2021 at 5:07
  • Oops, I meant to say v=spf1 ?all (now corrected), but no email system should be set up to deny delivery upon SPF failure. (SPF adoption has never had high enough efficacy to justify that.)
    – Adam Katz
    Commented May 21, 2021 at 15:02
  • If SPF is set to -all, that's certainly a justified reason for a connection-stage rejection. Commented May 21, 2021 at 17:39
  • @EsaJokinen – I'm in anti-spam professionally and can tell you that SPF was designed for that concept but was not successful. Nobody SMTP-rejects on SPF failures. For public data, here are the latest SpamAssassin net test results for SPF_FAIL, which show it hitting 2.1168% of the ham corpus. It's a fair spam signal, but not strong enough to independently convict a message.
    – Adam Katz
    Commented May 21, 2021 at 17:45
  • That's unfortunate, and might be the destiny of DMARC, too, because e.g. Microsoft doesn't handle p=reject policies properly. Commented May 21, 2021 at 19:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .