Send for signature, explained: encrypted links, signer order, and email verification

Send for signature (in Sign, under the Share & advanced menu) lets someone else sign your PDF in their own browser via a link. It is the one feature where document bytes leave your device — and they leave only as ciphertext your browser encrypted first. Here is how the whole flow actually works.

How the encryption works

Before anything is sent, your browser encrypts the PDF with AES-GCM. AttachKit’s server stores only the encrypted blob — it never holds a readable copy. The decryption key travels in the link itself, after the # in the URL (the #k=… fragment). Browsers never send the fragment to a server, so the key passes from you to your recipient without AttachKit ever seeing it.

Two consequences worth knowing:

• Anyone who has the full link can decrypt that document, so share it like the document itself.
• AttachKit cannot recover the key for you. Reminders, for example, can only be sent from the browser you sent from, because that is where the key lives.

For stricter sends there is Zero-knowledge mode (the pricing page calls it “Send so only they can open it”), where the key is encrypted to the recipient’s own published keypair instead of riding in the link, so only that recipient can decrypt. The recipient must first publish an encryption key under Account → Encryption keys. It’s a Max feature (during the private beta, everything is free).

The encrypted payload is capped at 35 MB, which fits roughly a 25 MB PDF after encryption and encoding.

Sending modes

In a sequential chain, only the current signer is emailed; when they submit, the next person in the chain gets their email automatically, and the request is marked complete when the last one signs. Sends are also rate-limited per hour (5 for anonymous senders, 30 signed-in, 100 on paid plans), which mostly matters for large bulk runs.

Email verification for signers

When a request has two or more recipients, every recipient must verify their assigned email address with a one-time code before the document opens for them. The Require email verification checkbox locks on automatically in the send dialog, and the server enforces it regardless — this is what stops one link-holder from signing on behalf of everyone else in the chain.

For a single recipient the checkbox is optional, and for open links it’s unavailable (there is no assigned email to verify against).

Tracking, reminders, and revoking

Your sign-requests dashboard lists every request with its state — pending, in progress, complete, expired, or revoked — and per-recipient signed status. From there you can:

• Copy link — to re-share it yourself.
• Remind — re-emails the current signer. This works only from the browser you sent from, since the link’s key never left it.
• Revoke — stops the link working immediately for anyone who hasn’t signed.
• Download the signed copy once recipients have signed.

Every request expires 7 days after sending, and expired requests are deleted from the server. Download the signed result before then; if a request expires unsigned, send a fresh one.

Checking the result

Anyone — sender, recipient, or a third party years later — can drop the signed PDF on Verify to check who signed it and that the content hasn’t changed since. Verification is free, needs no account, and the file is checked in the browser. That is the point of the whole flow: the signature stays checkable by anyone, not locked inside a platform.

Related

• How to sign a PDF
• How to verify a signed PDF
• Plans and AI actions