# The last gate before anything leaves

> An outbound email DLP gateway that fails closed: detect card numbers, SSNs, and secrets, then block, redact, or hold for a second person's sign-off.

Canonical: https://emailfast.dev/features/dlp

## Outbound mail, inspected on the way out

Email DLP here is an enforcement point, not an after-the-fact report:
an outbound data-loss-prevention gateway that fails closed — card numbers, government IDs, and secrets can be blocked, redacted, or held for a second person's sign-off before anything leaves.

## How it works

1. Define a policy: which detectors — card numbers, government IDs, secrets and API keys — apply to which mail.
2. Choose the action per rule: block outright, redact the match and send, or require TLS for delivery and hold the message when that can't be assured.
3. Held messages need a second person. Maker-checker release means the sender can't approve their own exception.
4. Evaluation happens twice: at admission and again at send time, so nothing that changed in between — a template edit, a variable value — can slip past the first check.

The failure behavior is the headline: an evaluator error blocks rather than leaks.
And until you define a policy, the gateway is inert — no latency tax, no surprise
blocks.

## The evidence

:::panel Two checkpoints, both fail-closed
```
admission --[DLP evaluate]--> durable queue --[DLP re-evaluate]--> send
              error? block                      error? block
```
The second evaluation exists because time passes between accepting a message and
sending it. Whatever changed in that window faces the policy again before anything
leaves.
:::

## Honest limits

:::tradeoffs Detection is patterns, and patterns have edges
Detectors match structure, and structure has lookalikes — a sixteen-digit order
number can trip a card-number check, so expect a tuning period with false positives.
Maker-checker adds human latency to held mail by design; the pause is the control
functioning. And fail-closed means an evaluator bug stops your mail instead of
leaking your data — availability traded for containment, deliberately.
:::

## Where to go next

DLP composes with [customer-held keys](/features/encryption) — one governs what
leaves, the other who can read what's stored — and with the
[compliance machinery](/features/compliance) around both. The
[enterprise door](/enterprise) shows the full control set, and if you're weighing
security-first vendors, the [Paubox comparison](/compare/paubox-alternative) is the
relevant one.

## What can the detectors find?

Card numbers (PANs), government identifiers such as SSNs, and secrets — API keys and credentials. Detectors apply according to the policy you define; without one, the gateway is inert.

## Who releases a held message?

A second person. Maker-checker release means the sender can't approve their own exception — the four-eyes control regulators mean when they say separation of duties.

## Does DLP slow sending if we don't use it?

No — the gateway is inert until you define a policy. No policy, no evaluation, no latency, no surprise blocks.

## What happens if the policy evaluator itself errors?

The message is blocked: an outbound data-loss-prevention gateway that fails closed — card numbers, government IDs, and secrets can be blocked, redacted, or held for a second person's sign-off before anything leaves. An evaluator failure stops mail rather than leaking data — fail-closed is the design invariant, not a configuration option.