The controls are only the start. Operating them is the work.

Inbound mail security

We make the platform’s own controls specific to the organization: anti-spoofing and impersonation policy, external-sender treatment, link and redirect handling, attachment policy including anomalous types and password-protected archives that limit what scanning can inspect, malware filtering, quarantine behavior, and the allow and block policy underneath all of it. Then the mail-flow settings nobody files under security: external auto-forwarding, routing and transport rules, and delegated or send-as behavior that widens who can send under your name.

Where a real requirement remains, we implement and operate a gateway such as Mimecast, Barracuda or a comparable platform. Buying one changes your mail flow rather than simply adding a filter, and most of the ways it goes wrong are routing problems rather than policy ones.

Once mail arrives via the gateway, an SPF check at the final hop evaluates the gateway, not the original sender. What stays useful is DKIM, where the message was not modified in transit, together with the results the gateway established upstream. The receiving platform has to recognize the gateway as a trusted hop and use those results. Direct inbound also has to be closed so mail cannot bypass the gateway.

Tuning is most of the work and it does not end. A control at its strictest setting is not the safest configuration; it is the one that generates false positives, fills a quarantine nobody reads, and teaches people to work around the system. The target is protection that is effective and can actually be operated.

Phishing reporting and response

Reporting only works if it is where people already are and if something happens afterwards. We put a reporting mechanism into the mail client people already use, and build the operational path behind it, so a report becomes an investigation rather than a message forwarded to a colleague for a second opinion.

The investigation itself is mail-layer forensics. Headers, and what SPF, DKIM, DMARC and ARC actually said rather than whether a green tick appeared. Links, including where a redirect chain finally lands. Attachment behavior. Reply-To, envelope sender and the sending infrastructure behind the message. Authentication results are evidence about authorization, not about intent, and a well-formed phishing message can authenticate correctly from a domain belonging to somebody who should not be trusted.

When something is malicious, the response stays inside the mail channel and is thorough within it. We establish who else received the same or a related message, remove remaining copies where the platform supports administrative remediation, and update sender, domain and policy controls so the next attempt is caught earlier. We close the loop with the person who reported it and explain what happened. That follow-through is what keeps the next report coming. Where the attack has gone further than the mailbox, it stops being ours: captured credentials belong to Identity, code that executed belongs to Endpoint, and an incident crossing several systems belongs to Security Readiness and Response.

Phishing awareness

People are part of the detection and reporting path, not a substitute for technical controls. What they need is narrow: recognize that something is off, know how to report it, and have seen that reporting leads somewhere. Visible follow-through is what sustains reporting, which is why awareness sits inside the response path rather than beside it.

The tooling follows the requirement. Free material is enough for some organizations; others benefit from a paid awareness or simulation platform, and simulations earn their place when they teach something rather than produce a score. We select the approach, integrate the reporting mechanism with it, and use the patterns actually seen in your environment. What this is not is a technical preventative control: awareness does not change how much deceptive mail reaches the mailbox, which is the filtering layer’s job. It changes how often somebody acts on one, and how quickly the rest are reported.

Email DLP and outbound content controls

Where email is the enforcement point, outbound content can be inspected before it leaves. We implement DLP on the mail path: body and attachment rules, sensitive-content policy, routing through a detection service where the design calls for one, and the decision that shapes everything else, whether a rule reports or blocks. Where the risk allows it, new rules normally start in monitor mode, because a rule that blocks before anyone has measured what it catches blocks the wrong thing.

Getting it into production is engineering rather than policy writing. Roll out in scope before organization-wide enforcement. Use synthetic tests that deliberately trigger the rule, test the bypass paths, and cover combinations that behave differently, including unusual attachment types, archives and exempted recipient domains. A detector in the mail path can affect routing and authentication, so both are revalidated rather than assumed.

Then come the operating decisions: quarantine and reviewer workflow, notifications, how exceptions are requested and granted, and whether the design fails open or closed when the detection service is unavailable. That last choice is a real trade-off and should be decided rather than inherited. This is email as the control point. Classification and governance across every channel a company holds data in is a larger program, and not a claim we are making here.

Mail security operations and maintenance

Email security degrades when nobody owns the exceptions. Every allow entry, bypass and relaxed rule changes the boundary of what the control is actually inspecting, and each one is usually reasonable at the moment it is made. What causes trouble is that they tend to have no recorded owner, no reason attached, and no point at which anybody looks at them again. We keep them attributable: an entry carries who asked for it and why, gets reviewed on a schedule, and is removed or given an expiry where the reason was temporary.

The rest is keeping the layer honest as everything around it moves. False positives are reviewed rather than tolerated, because a queue people stop trusting is a control people stop using. Quarantine behavior and policy are revisited as mail patterns change. Platform capability changes on someone else’s release schedule, and a native control that has improved is frequently the reason a workaround or a third-party tool can be retired. We check that controls still fire as intended rather than assuming a policy written last year is still matching anything, that the reporting path still terminates in action, and we report on whether the layer is working rather than on how much mail it touched.