Pre-Send Verification Explained: Missing Attachments, Wrong Recipients, and Confidential Leaks

The Three Mistakes That Cost the Most

Not all email mistakes are equal. A typo makes you look sloppy. A missing Oxford comma makes a purist uncomfortable. But three specific classes of mistakes cost measurable money, damaged relationships, and occasionally jobs:

1. Missing attachment — You promised a file and forgot to attach it.

2. Wrong recipient — You sent sensitive content to the wrong person.

3. Confidential leak — You included content that should not have left your organization.

This piece is a technical deep dive on how a modern pre-send verification system detects each of these classes, what the trade-offs are, and how to think about false-positive management.

Missing Attachment Detection

The problem shape. You write "attached is the report," you hit send, and the attachment area is empty. The recipient sees a message referring to something that is not there. You look scattered, and you have to send a follow-up, which itself sometimes has the same problem.

The naive approach. A regex scan for the word "attached" or "attachment." Blocks send if found and no attachment is present.

Why the naive approach fails. English speakers say "attached" in many contexts unrelated to files ("I feel very attached to this project"). Users in Slack, LinkedIn, and elsewhere paste text into email that mentions attachments to *other* emails. False positive rates on a simple keyword match are around 12-15%, which quickly trains users to dismiss the warning.

The better approach. A curated phrase library across 30+ languages (the Presend library has roughly 640 phrases in English alone), scored by their statistical association with actual file references. Phrases like "please find attached," "PFA," "the file below," and "see the attached document" carry high scores. Ambiguous phrases like "attached to this project" carry low scores. A weighted sum crosses a threshold to trigger the check.

Even better: a small transformer model trained on labeled examples of "email intends to reference an attachment" vs. "email uses the word attached in another sense." This runs client-side in Web Assembly, adds ~40ms per check, and drops false positive rates below 2%.

Edge cases worth handling.

• Screenshots pasted inline. The user thinks they attached, but they inline-pasted an image. Detect inline image presence and treat as an attachment for the check.
• Attachments removed after reference. User attached, referenced, then removed. Should still block.
• Multi-language. "Adjunto" (Spanish), "en pièce jointe" (French), "添付" (Japanese). A language-agnostic model beats an English regex.
• Reply context. "Attached the file yesterday" refers to a past send. Should not fire.

Wrong Recipient Detection

The problem shape. You are typing an email to Sarah. Gmail's autocomplete resolves to `sarah.k@vendor.com` instead of `sarah.k@yourcompany.com`. You do not notice. You send. The vendor receives internal comp discussion.

The naive approach. Warn every time a recipient is external. This immediately becomes noise, because most people send external email all day.

The better approach. Context-aware external recipient detection. The system asks: "Is this recipient consistent with the *rest* of the recipients on this thread and the *content* of this message?"

Specific rules:

• Domain-mismatch on reply. You are replying to a thread where all previous recipients are internal, and you added an external recipient. Block.
• Internal keyword scan. The body contains `internal only`, `confidential`, `salary`, `comp`, `legal privileged`, or team-specific tokens. External recipient triggers a hard warning.
• Autocomplete ambiguity. Two contacts with very similar names (Levenshtein distance ≤ 2) both exist in your address book. When you select one, the system asks "did you mean the other?" — with disambiguating info (last message date, org, avatar) shown side-by-side.
• First-time send warning. The first time you email a new external address on a thread that includes other established internal recipients, ask for explicit confirmation.

False positive management. The most annoying failure mode is warning on every external send. The system must know your team, your customers, and your regular external contacts, and only fire when the pattern breaks. A three-strike rule ("this recipient has been dismissed as a false positive three times; auto-approve going forward") keeps annoyance low.

Confidential Leak Detection

The problem shape. You are drafting an email with a data snippet — logs, a config file, a customer list — that contains something sensitive. An API key. A password. A social security number. A JWT that grants admin access to your production database.

The naive approach. Regex for common secret formats.

Why the naive approach is insufficient but necessary. Regex is fast and cheap and catches the obvious cases (Stripe keys, AWS access key IDs, GitHub personal access tokens, JWTs). It is the baseline. Every serious pre-send system has a regex layer with dozens of patterns.

The additional layer. An entropy-based scan for high-entropy strings that do not match a known format. A password like `kJ3$mn2!qwErTy@4` matches no regex but has enough entropy to be suspicious. Combined with keyword context ("password:", "token:", "secret:") this catches the long tail.

The LLM layer. For high-stakes content, a small classifier model reads the whole email and flags "this looks like sensitive information being shared." This catches things regex cannot — a paragraph describing internal architecture, an offhand mention of a customer's exact revenue, a screenshot of a diff that includes secrets.

Policy tiers. Not all sensitive content is equally sensitive.

• Block tier: API keys, passwords, JWT tokens, SSNs, credit card numbers. Send blocked; override requires reason.
• Warn tier: Financial figures, salary discussions, personnel details. Warning; single click to proceed.
• Log tier: Internal architecture references, employee names, product roadmap. No interrupt; logged for audit.

Enterprise customers configure tier assignments per their DLP policy.

The Latency Budget

All three of these checks must complete before the user hits send, without a perceptible delay. The end-to-end latency budget is roughly 300ms:

• 80ms for structural checks (attachment presence, recipient list parsing).
• 100ms for regex passes (secret detection, phrase library).
• 120ms for LLM classifiers (leak detection, tone/intent). Batched across multiple checks.

Beyond 500ms end-to-end, users start clicking send again in frustration. The engineering constraint is real and shapes every implementation decision.

Handling Overrides

Every check should be overrideable. Blocking without override breeds mutiny; users learn to disable the extension.

The right pattern:

• Warning: Single click "send anyway." Log the override reason automatically ("recipient list confirmed by sender").
• Block: Modal with a short reason field. User types a phrase explaining why the block does not apply. Send proceeds. Reason is logged.
• Enterprise policy blocks: Cannot override without approver on the CC line. Send blocked until approval received.

The audit log of overrides becomes valuable data — it tells the security team which rules are firing on legitimate sends too often (candidate for tuning) and which rules are catching real incidents (worth expanding).

Measuring Success

The right metric for a pre-send verification system is not "checks fired per day." It is "incidents prevented per user per month." Estimated from customer data:

• Missing attachment catches: ~2.3 per user per month on average, ~7 for high-volume senders.
• Wrong-recipient catches: ~0.4 per user per month, ~1.5 for support and sales roles.
• Confidential-leak catches: ~0.1 per user per month, but the cost per incident is orders of magnitude higher.

Aggregate cost of prevented incidents (using conservative estimates of remediation effort) runs to $600-$1400 per user per year for professional-services teams.

What Comes Next

The frontier for pre-send verification in 2026:

• Better cross-thread understanding. Detecting when a message would violate implicit norms established earlier in the same thread.
• Multi-modal check. Reading text in attached images and PDFs, not just filenames.
• Cross-app leak detection. Catching when the same sensitive string was recently pasted from Slack, notes, or a browser tab, suggesting a copy-paste error.
• Recipient behavior modeling. Learning which recipients are safe for which content types and warning on anomalies.

Each of these is under active development. The core three — attachments, recipients, and leaks — are table stakes for any serious professional email workflow in 2026.

Add Presend to Chrome — Free →