Encrypting Regulated Data While Keeping Internal Mail Readable

Use policy direction and recipient scope rather than a global DLP bypass. FortiMail policies can distinguish inbound, outbound, and internal direction or match sender and recipient domains. Create or reorder a policy that matches mail from meridian.example to meridian.example and apply a DLP profile that detects the data but does not invoke the IBE encryption action. Keep the outbound policy for external recipients with the encryption action attached. Confirm policy evaluation order, because a broad outbound rule that matches all recipients will catch internal mail before a later internal rule. If the internal policy still needs to record DLP incidents, enable logging without encryption. Test with a controlled message containing a known account number and verify from the delivery log that the internal message is delivered unencrypted and the external message triggers IBE. Do not disable DLP globally, which would also stop detection for external mail.

A bare 16-digit pattern matches any long number, including the registration number in the footer. That creates a high false-positive rate and, because encryption is attached, makes ordinary internal mail unreadable. Replace the broad pattern with one that requires more context, such as a keyword near the number, a specific field label, or a validated account-number format. If FortiMail's DLP engine supports checksum validation for card-like numbers, use it; otherwise combine the pattern with sender, recipient, or attachment conditions. Add an exception for the known registration number only if it cannot be distinguished contextually. Test the profile against samples of legitimate statements, footers, and actual account data, and review DLP incident logs before enforcing encryption. The goal is to keep detection sensitive enough for real account numbers while excluding repeated boilerplate.

Opportunistic TLS explains the plaintext fallback: when the handshake fails, FortiMail continues without encryption. Disabling certificate validation would make the handshake succeed but would also accept an impostor, so the better fix is to trust the partner's internal CA. Import the CA certificate into FortiMail's trusted CA store, create a TLS profile that requires TLS and validates the certificate and hostname, and apply that profile to the route or policy used for clearroute.example. Set the policy so that a TLS failure queues or rejects the message rather than falling back to plaintext, and alert on those failures. Verify the partner certificate chain, expiration date, and the exact hostname FortiMail presents and expects. Send a test message and confirm the delivery log shows a successful verified TLS session. If a temporary exception is ever needed, scope it to the partner destination and document the risk.