Your Email Security

Akins IT • October 24, 2018

What do you think may be the weakest point in your network? It’s probably not the firewall protecting the network from hackers, but may be the end user sitting on an end-point visiting a phishing site that is about to harvest their credentials. Carelessness often leads to environment and network breaches. An attacker’s primary tool isn’t Mimikatz, but the daily driver of productivity in every business: email.

When determining a security gateway that’s right for your company, it’s important to determine the number of users, compliance the company must meet, and the importance of security. My local coffee shop isn’t going to need the same level of security as my bank. Again, it’s about assessing the needs of the company to find the right solution.

Traditional security email gateways are easier to use and have a lower cost associated. Implementation can be as easy as flipping an MX record to point to the gateway. Console management usually provides basic reporting and policies can be spun up within a few hours. Policies include URL rewrites and attachment sandboxing. Microsoft’s O365 ATP features these security mechanisms in their offering, as an example.

Mimecast, a leader in email security, provides granular policies for enterprise. Attachment Protect isn’t only limited to sandboxing at the gateway. Its capabilities are enhanced to provide file conversion where necessary. For example, Office documents can be converted into a PDF, stripping any malicious metadata from the document. Mimecast excels in its ability to create in-depth policies for departmentalized companies.

Below are a few screenshots to illustrate the differences of the two gateways listed.

The company and IT department shouldn't place the responsibility of security on the end user; they're bound to accidentally click on a link for a malicious site at some point. It's the IT department's responsibility to ensure their network is secure and engage their company’s security posture with a focus on email security as these types of attacks become more frequent.

Strengthen Your Email Security

< Older Post

Newer Post >

AWS stumbled this morning. Here’s why multi‑cloud keeps you moving.

By Shawn Akins • October 20, 2025

October 20, 2025 — Early today, Amazon Web Services experienced a major incident centered in its US‑EAST‑1 (N. Virginia) region. AWS reports the event began around 12:11 a.m. PT and tied back to DNS resolution affecting DynamoDB , with mitigation within a couple of hours and recovery continuing thereafter. As the outage rippled, popular services like Snapchat, Venmo, Ring, Roblox, Fortnite , and even some Amazon properties saw disruptions before recovering. If your apps or data are anchored to a single cloud, a morning like this can turn into a help‑desk fire drill. A multi‑cloud or cloud‑smart approach helps you ride through these moments with minimal end‑user impact. What happened (and why it matters) Single‑region fragility: US‑EAST‑1 is massive—and when it sneezes, the internet catches a cold. Incidents here have a history of wide blast radius. Shared dependencies: DNS issues to core services (like DynamoDB endpoints) can cascade across workloads that never directly “touch” that service. Multi‑cloud: practical resilience, not buzzwords For mid‑sized orgs, schools, and local government, multi‑cloud doesn’t have to mean “every app in every cloud.” It means thoughtful redundancy where it counts : Multi‑region or multi‑provider failover for critical apps Run active/standby across AWS and Azure (or another provider), or at least across two AWS regions with automated failover. Start with citizen‑facing portals, SIS/LMS access, emergency comms, and payment gateways. Portable platforms Use Kubernetes and containers, keep state externalized, and standardize infra with Terraform/Ansible so you can redeploy fast when a region (or a provider) wobbles. (Today’s DNS hiccup is exactly the kind of scenario this protects against.) Resilient data layers Replicate data asynchronously across clouds/regions; choose databases with cross‑region failover and test RPO/RTO quarterly. If you rely on a managed database tied to one region, design an escape hatch. Traffic and identity that float Use global traffic managers/DNS to shift users automatically; keep identity (MFA/SSO) highly available and not hard‑wired to a single provider’s control plane. Run the playbook Document health checks, automated cutover, and comms templates. Then practice —tabletops and live failovers. Many services today recovered within hours, but only teams with rehearsed playbooks avoided user‑visible downtime. The bottom line Cloud concentration risk is real. Outages will happen—what matters is whether your constituents, students, and staff feel it. A pragmatic multi‑cloud stance limits the blast radius and keeps your mission‑critical services online when one provider has a bad day. Need a resilience check? Akins IT can help you prioritize which systems should be multi‑cloud, design the right level of redundancy, and validate your failover plan—without overspending. Let’s start with a quick, 30‑minute review of your most critical services and RPO/RTO targets. (No slideware, just actionable next steps.)