The usual version of this argument goes: email is insecure, attachments get intercepted, use signing links. That framing was convincing fifteen years ago and is mostly wrong now.
Email in transit is generally encrypted between major providers. Interception on the wire is not where your contracts are at risk. The actual risks are different, and once you see them clearly the case for signing links is stronger — just not the case usually made for it.
Key takeaways
TLS in transit is now standard, so "email is a postcard" is outdated. At rest, it isn't encrypted.
The real exposures are mailbox compromise, uncontrolled forwarding, version ambiguity and missing audit trail.
The tamper-evidence that matters is the digital seal on the signed PDF, which survives being emailed.
Signing links have a genuine downside: they teach people to click and authenticate, which is the phishing pattern.
For most businesses the answer is both — links to execute, encrypted delivery for the final copy.
What email actually does and doesn't protect
In transit: Gmail and other major providers encrypt mail in transit with TLS where the other provider supports it. Encryption in transit requires both providers to support it, so it isn't guaranteed — but between mainstream business providers it's now routine.
At rest: TLS does not encrypt email while it's stored on a server. Your contract sits in two mailboxes, readable by anyone with access to either account and by both providers.
That's the real exposure. Not someone tapping a cable. Someone compromising an inbox — which is exactly what the attacks described in our guide to fake signature request emails are designed to achieve.
So when you email a contract, you're not broadcasting it. You're depositing a permanent copy in two accounts you partly don't control, indefinitely.
The four risks that actually matter
1. Mailbox compromise. One phished account exposes every contract ever sent or received through it. This is the single largest risk and it's unaffected by how the document was encrypted in transit.
2. Uncontrolled distribution. Once a PDF lands, it can be forwarded anywhere with no record. You cannot revoke it, cannot see who has it, cannot tell who opened it.
3. Version ambiguity. Three rounds of redlines produce four attachments with similar names. Which one was signed? Attachments are where this becomes genuinely hard to answer later.
4. No audit trail. You have an email header. You don't have who opened it, when, from where, or how their identity was verified. In a dispute this is the gap that costs you.
Note what isn't on the list: wire interception. Keep it in proportion.
What about tampering?
This is the risk most misunderstood in both directions.
Yes, a downloaded PDF can be edited. But a properly signed document carries a digital signature and tamper-evident seal — alter a single byte and validation fails. That protection is part of the file, so it works whether the document is emailed, downloaded or stored on a USB stick.
Two consequences:
An unsigned PDF sent as an attachment has no tamper protection at all. Anyone can change terms before signing and you'd have only your sent copy to compare against.
A properly executed signed PDF is tamper-evident wherever it goes. Emailing the final signed copy is not the vulnerability people assume.
The protection comes from how it was signed, not how it was delivered. How e-signature security and audit trails work covers the mechanism, and types of electronic signatures explains how signature level changes the strength of that guarantee.
What signing links actually give you
Set aside interception. The real advantages:
A document identity. One canonical version with a URL. No ambiguity about which draft was executed.
Identity verification at signing. Email link, SMS code, or stronger methods for high-value documents — proportionate to risk rather than uniform.
A complete audit record. Opened when, from which IP, on what device, verified how, signed at what time. This is the evidence that resolves disputes, and it's the thing attachments cannot produce.
Control after sending. Void a document, see who hasn't signed, send reminders, revoke access.
Workflow. Sequential approvals, routing by value or type, automatic filing. Common signing workflows covers the patterns, and integrations determine whether signed documents file themselves.
The honest downside of signing links
Signing links ask recipients to click a link in an unexpected email and authenticate. That is precisely the behaviour that makes e-signature phishing effective, and attackers exploit it by sending genuine envelopes from real platforms containing malicious content.
What reduces it:
Consistency. If your organisation always signs through one platform, anything else is visibly odd.
Telling recipients what to expect before the first send, particularly for high-value counterparties.
Training people to reach the platform directly rather than through the link, which works regardless of how convincing the email is.
MFA on your own signing accounts, since a compromised sender account lets an attacker send genuine requests in your name.
Pretending this tradeoff doesn't exist is how security guidance loses credibility. It's a real cost, and it's outweighed — but you should know you're paying it.
When attachments are fine
Not every document needs a platform:
Internal documents between colleagues on the same managed domain.
Drafts and redlines during negotiation, before execution.
Low-stakes agreements with established counterparties.
Delivering the final signed copy — tamper-evident, and the recipient is entitled to keep one.
When the counterparty refuses. A wet signature scanned and returned is valid. Insisting on your tooling at the cost of the deal is rarely the right call.
If you do send sensitive attachments, encrypted attachments are the right mechanism, and the password goes through a different channel. Never the same thread.
Where password-protected PDFs sit
Better than nothing, worse than people assume — but not for the usual reason.
Modern PDF encryption uses AES-256. The algorithm is not the weak point. The weak points are: passwords that are guessable, passwords sent in the same email, no way to revoke access once shared, and no audit trail or identity verification. It's key management that fails, not cryptography.
Use it for confidentiality on a document being delivered. Don't treat it as a substitute for a signing workflow.
Compliance, stated accurately
GDPR. Contracts contain personal data, so transmission and storage both matter, along with retention limits and processor arrangements. A platform gives you a documented processing location, a DPA and a subprocessor list. Email scatters copies across mailboxes indefinitely, which sits badly with storage limitation. See GDPR compliance for e-signatures, the DPA and the subprocessor list.
HIPAA. More nuanced than usually stated. Encryption is an addressable specification, not an absolute prohibition on email, and HHS guidance permits sending PHI to a patient by unencrypted email where they've requested it and been warned of the risk. Where a vendor handles PHI you need a business associate agreement — a contract you execute, not a feature a platform "supports." Many contracts contain no PHI at all. [LEGAL REVIEW]
Evidentiary standing. Electronic signatures are recognised under ESIGN and eIDAS. Both attachments and links can produce valid signatures. The difference is the quality of evidence if challenged, which is a practical distinction rather than a legal one.
Review any platform's actual posture rather than a compliance badge: security and trust.
A practical policy
Document | Method |
|---|---|
Internal memos, routine acknowledgements | Attachment fine |
Drafts under negotiation | Attachment fine |
Anything executed with financial or legal weight | Signing link |
Personal data, regulated sectors | Signing link, with a DPA or BAA in place |
Multi-party or sequential approval | Signing link |
Final signed copy to the counterparty | Either — it's tamper-evident |
Standardise on one platform. Mixed tooling costs you the consistency that makes anomalies visible.
Common mistakes
Arguing from interception. It's the weakest point and an informed reader will notice.
Treating the link as the protection. The audit trail and version control are what you're buying.
Assuming signers can't download. They can, and generally should be able to.
Password in the same email.
Sending unsigned PDFs for signature with no tamper protection at any stage.
Ignoring the phishing tradeoff.
Treating "HIPAA compliant" as a product property.
FAQ
Is emailing a contract as a PDF unsafe?
Not inherently. Email between major providers is usually encrypted in transit, though not at rest. The weaknesses are no audit trail, no version control, no identity verification, and copies sitting in mailboxes indefinitely.
Can someone intercept my emailed contract?
Possible but unlikely between mainstream providers, since TLS is widely deployed — though it requires both providers to support it. Mailbox compromise is the far more common route.
Can a signed PDF be altered?
A properly signed document carries a tamper-evident seal; alteration breaks validation. An unsigned PDF has no such protection.
Can signers download their copy?
Yes, on most platforms, and ESIGN requires electronic records to be capable of retention by the recipient. Treat a platform that prevents it as a problem rather than a feature.
Are password-protected PDFs enough?
For confidentiality in delivery, sometimes. They provide no audit trail, no identity verification and no revocation, and the password is usually the weak link.
What if the counterparty won't use a link?
Offer a wet signature returned by scan, which is valid. Weigh the risk against the relationship rather than insisting as policy.
Doesn't a signing link look like phishing?
It uses the same pattern, which is a genuine cost. Standardise on one platform, tell recipients what to expect, and train people to reach the platform directly rather than through links.
