Email DLP: how to test your outbound email rules

Friday, 6:40 pm. A salesperson leaving at the end of October emails the customer file for their territory to their personal Gmail, zipped “so it gets through”. On Monday morning, your SOC has seen nothing. Yet the DLP rule on customer data was marked as active.

Testing an email DLP rule means replaying that action with synthetic data: from a real workstation and a real mailbox, you send synthetic IBANs or synthetic customer files, then look at what the gateway did with them. Block, quarantine, encryption, alert, or nothing at all. In practice, email is often the channel where exceptions pile up fastest.

This article covers outbound email only, whether you run Microsoft 365, Google Workspace or a dedicated gateway. For the approach across all channels, see our page on data exfiltration testing.

Why email rules degrade silently

On the day you create it, your email DLP policy is rarely wrong. It becomes wrong. A partner domain allow-listed in March, a relay connector for the ERP in June, an Exchange transport rule created on a Thursday evening to unblock an executive: each of these changes is defensible, and each one opens a door.

On the email side, these are the most common culprits:

• Rule evaluation order: a transport rule processed before the DLP can short-circuit inspection.
• Exceptions by sender or group: your senior management, your service accounts, your shared mailboxes.
• Parallel exit paths: application SMTP relay, iOS or Android mobile client, webmail outside the scope.
• Content analysis limits: maximum size, archive depth, unsupported formats.

The four families of tests to cover

1. Message body and attachments

Everyone runs this test, and almost everyone stops too early. A synthetic IBAN in a Word document validates the simplest detection. Next, vary the container, one variable at a time:

• the same synthetic IBAN in the body, then in a .docx file, then in a PDF or a PowerPoint;
• a PDF from a scan (an image with no text layer), to see whether your optical character recognition is enabled;
• a ZIP, then a ZIP tucked inside a 7z archive, 2 or 3 levels deep (MITRE ATT&CK technique T1560);
• a large file, just under and then just over your solution’s analysis limit;
• an Excel workbook with the sensitive data in a hidden sheet.

Each variant asks your solution the same question: can it open this format, and if not, what does it do? Silently letting an unreadable file through can be defended, provided someone has decided it and written it down.

2. Encryption

This word covers two unrelated situations.

First, encryption as a DLP action: the rule spots sensitive data and encrypts the message instead of blocking it (in Microsoft 365, with Purview Message Encryption for example). Check from an external mailbox that the recipient really receives a protected message, and not the plain text under a banner.

Second, encryption that prevents inspection. A password-protected workbook, an AES-encrypted ZIP, an S/MIME message: your gateway cannot read them. What does your policy do then? Blocking, quarantining or letting it out with an alert to the SOC can each be defended depending on the context. Deciding nothing cannot.

3. Forwarding to personal addresses

This is our Friday-evening salesperson, the most mundane insider threat scenario. Test four paths separately, as they do not depend on the same settings:

• manually sending an attachment to Gmail, Yahoo Mail, Outlook.com or Proton Mail;
• forwarding a received message, with its original attachment;
• an automatic forwarding rule created by the user in their mailbox (T1114.003 in MITRE ATT&CK);
• a server-side redirect configured for a shared mailbox.

4. Forgotten exit paths

Part of your outbound email never goes through Outlook: the ERP that sends its exports through an SMTP relay, the multifunction printer that “scans to email”, the CRM that writes to customers on your behalf. One of these flows bypassing the DLP can be justified. But it still needs to be written down somewhere, and compensated by another control.

A validation grid for email DLP

For each scenario, record the expected result and the observed result. The gap between the two is your to-do list.

Scroll the table →

Also check the alert chain, which is often forgotten. If the message is blocked but the SOC knows nothing about it, you have only gone half the way. A test should only be closed once an analyst has seen the event arrive in your SIEM. Break each result down by protocol, application layer and path: that tells you where the chain broke.

A concrete scenario: an employee leaving

Picture a distribution company that has just come out of an audit and tightened its DLP. First send: a spreadsheet of 200 synthetic IBANs to an external domain. Blocked, nothing to add. Second send: the same spreadsheet, zipped, from the account of an executive assistant who belongs to the group exempted for the external accountant. The message goes out. No alert.

Technically, nothing is broken: the exception was approved in January 2024. But today it covers 14 people instead of 3, and nobody had connected it with forwarding to external addresses. You only see it by replaying the send with the real exempted account.

Ground rules for testing without using any real business data

• Send only decoys that respect formats and checksums: synthetic IBANs with a valid modulo 97 key, synthetic UK National Insurance numbers (2 letters, 6 digits and a final A, B, C or D) or US Social Security numbers (9 digits). Our article on synthetic data in production details the approach.
• Inform the SOC or agree on a marker to qualify test incidents, without removing them from the alert chain.
• Send from real workstations in your estate, not from a lab machine.
• Receive your test messages in external mailboxes you own, to see what actually arrived.
• Test with your different profiles: standard user, exempted account, shared mailbox.
• Rerun the scenarios after every policy update, new connector or migration, and on a regular schedule, daily or weekly for example.

If your email runs on Microsoft 365, the method applies directly to the policies described in our guide to validating Microsoft Purview^™ DLP.

FAQ