Email security is the combination of authentication, filtering, encryption, policy, and user behavior that keeps mail trustworthy and inbox noise manageable. Crimes exploiting trust in email caused more than $4 billion in losses during the FBI IC3 2025 reporting cycle, including $3.04 billion from business email compromise, according to the IC3 reporting analysis.
A five-person company running on Gmail and Outlook can lose money after a single convincing vendor message, while the same inboxes fill with newsletters, cold sales pitches, fake calendar invites, and customer requests. The practical question isn't whether email security exists. It's whether the company can verify senders, stop dangerous messages, protect sensitive content, route legitimate mail intelligently, and show what happened when a rule made a decision.
Table of Contents
- What Email Security Means Today
- The Threats Email Security Has to Stop
- How SPF DKIM and DMARC Stop Spoofing
- Where Native Gmail and Outlook Filters Reach Their Limits
- Encryption Filtering and Allow List Strategies
- Policies Training Incident Response and Monitoring
- A 30 Day Plan for Founders Executives and Small Teams
What Email Security Means Today
A useful answer to what is email security begins with four controls working together:
- Stop malicious mail: Detect phishing, malware, spoofing, and fraud before someone acts.
- Authenticate legitimate senders: Use SPF, DKIM, and DMARC to give receiving systems evidence about who sent a message.
- Encrypt sensitive content: Protect messages in transit and, where appropriate, while they remain accessible in mailboxes.
- Filter low-value mail: Route newsletters, unknown senders, vendor notices, and repetitive alerts so important messages stay visible without deleting unexpected mail.
A founder who has just approved a fraudulent wire transfer after reading a spoofed vendor email needs all four controls. Authentication may expose the spoofing. Filtering may move the message for review. A policy may require payment verification through another channel. User behavior determines whether the warning is acted on.
Security is also an operations problem
SPF authorizes sending IP addresses for a domain. DKIM adds a digital signature that helps detect tampering. DMARC connects those results to the visible From address and tells receiving systems whether to monitor, quarantine, or reject failures. These controls reduce guesswork when receiving systems handle spoofed messages.
Authentication does not organize an executive's inbox. Native Gmail filters and Outlook rules can route predictable mail, but they become harder to manage when conditions depend on contacts, previous replies, sender groups, headers, attachments, or mailbox state. A message can be safe enough to preserve while still distracting from higher-priority work.
Use layered controls. Start with threat detection, then sender authentication, native filter limits, encryption, allow-list and VIP routing, operating policies, and a staged rollout. Allow lists should protect trusted senders without creating bypasses for authentication checks. VIP routing can keep executive, customer, or payment-related mail visible, while repeated low-value messages move to a review folder instead of being deleted.
The strongest design keeps unfamiliar mail recoverable, visible, and subject to review. It also records why a rule acted, so an administrator can correct a false positive without guessing.
The Threats Email Security Has to Stop
A founder approves a payment from a familiar-looking thread. The sender address appears normal, the request matches a current project, and no malicious link is present. Email security must catch that kind of fraud, not only obvious phishing messages.
Phishing remains a high-volume threat. APWG trend reporting recorded 3.8 million phishing attacks in 2025, compared with 3.76 million in 2024, as reported in the market summary of APWG findings. The financial impact can be greater than the message count suggests. FBI IC3 reporting showed phishing losses rising from $70 million to $215.8 million year over year, while complaint volume changed only slightly, from 193,000 to 191,000. Losses increased 208%, and business email compromise accounted for $3.04 billion, according to the FBI IC3 email fraud analysis.
Different attacks require different controls
A phishing email may copy a cloud login page and steal credentials. A business email compromise message may contain no malicious link. It can request changed bank details, an invoice payment, or payroll information.
Attackers also use lookalike domains, compromised vendor mailboxes, fake replies inside existing threads, attachments, and calendar invitations. Sublime reported that BEC and fraud represented nearly 32% of all email threats in 2025, while thread hijacking and fake threads made up 28.1% of BEC attacks. The same report found QR-code phishing rose 282.7% from the first half to the second half of 2025, as detailed in Sublime's email threat research.
Practical rule: A message can be dangerous because of its relationship context, not only because it contains a suspicious link.
| Threat | Typical impact | Primary control |
|---|---|---|
| Phishing | Stolen credentials, fraudulent sign-ins, or unauthorized payments | Link and content filtering, authentication, user reporting |
| Business email compromise | Payment diversion, payroll fraud, or sensitive-data disclosure | Verification policy, sender analysis, payment controls |
| Malware | Device compromise through an attachment or link | Attachment scanning, sandboxing, safe-link analysis |
| Spoofing | A fake message appears to come from a trusted domain | SPF, DKIM, and DMARC alignment |
| Account takeover | A real mailbox sends convincing messages to existing contacts | Strong account access controls, anomaly monitoring, rapid response |
Separate volume from consequence. A harmless newsletter should not receive the same review priority as a vendor request for new payment instructions. Use detection and authentication to reduce broad exposure, then apply stronger verification to financial requests, executive mail, vendor relationships, and messages that change established workflows. Route repeated low-value mail to a review folder rather than deleting it, while VIP messages remain visible for prompt handling.
How SPF DKIM and DMARC Stop Spoofing
SPF, DKIM, and DMARC form one control chain. They answer different questions: may this server send for the domain, did the message remain intact, and does the authenticated identity match the visible From address? Together, they help receiving systems separate authorized mail from messages using a forged domain.
SPF checks the sending server
SPF lists the IP addresses authorized to send mail for a domain. If a phisher claims to send from a company's domain but uses an unauthorized server, the receiving system can record an SPF failure.
SPF has a clear limit. Forwarding can change the server that delivers a message, so legitimate forwarded mail may fail the check. Use SPF as one signal, not as the organization's entire authentication strategy.
DKIM checks message integrity
DKIM attaches a cryptographic signature to the message. The recipient's mail system checks that signature against the signed content and headers. A changed message can therefore fail the integrity check.
A valid DKIM signature does not by itself prove that the visible From address belongs to the organization the recipient recognizes. A marketing platform may sign with its own domain, while DMARC still requires alignment between the authenticated domain and the visible From domain.
DMARC applies alignment and policy
DMARC connects SPF and DKIM results to the visible From domain. It also tells receiving systems how to handle messages that fail alignment, such as monitoring, quarantine, or rejection.
Start by inventorying legitimate senders under a monitoring policy. Confirm that approved services authenticate and align correctly, then tighten the policy to quarantine and later reject unauthorized mail. A staged 90-day move from p=none to p=quarantine to p=reject is a practical editorial recommendation, not a universal requirement. Set the pace according to the organization's sending inventory and report quality.
Publishing a DMARC record while leaving enforcement at monitoring indefinitely creates visibility without directing receivers to handle unauthorized mail more aggressively. Document every sending service, verify SPF or DKIM alignment, and review reports before changing enforcement.
The embedded video below demonstrates how DMARC alignment works in practice, including how the visible From domain relates to authentication results.
Authentication failures still require an operating procedure. Use this guide to message security verification failures to distinguish a configuration problem from a suspicious sender or a legitimate service set up incorrectly. Route repeated low-value failures to review, while messages involving payments, executives, vendors, or changed workflows receive direct verification.
Where Native Gmail and Outlook Filters Reach Their Limits
Native rules are useful, and teams should start with them. Gmail filters can apply labels, archive, delete, star, forward, or skip the inbox. Google also documents a limit of 500 filters per account, as summarized in Gmail filter guidance.
Outlook and Exchange Online use a different constraint. Microsoft documents a default and maximum inbox-rule quota of 256 KB, with an administrator-set range from 32 KB to 256 KB. The quota applies to enabled rules, while disabled rules don't count, according to Microsoft's Exchange Online rule-quota documentation.
The problem isn't only the named limit
Gmail's native system handles predictable searches well. A rule can route mail from a known sender, apply a label to a recurring subject, or archive a newsletter. Google guidance limits filter behavior to new messages and replies that still match the same search criteria, so a filter doesn't automatically understand the evolving relationship behind a conversation.
Outlook doesn't impose a simple fixed rule count in Exchange mailboxes. The practical constraint is the combined serialized size of enabled rules, and independent Outlook rule guidance notes that more than 100 rules may affect mailbox performance. Large shared inboxes can therefore become difficult to debug even when the visible rule list looks manageable.
| Capability | Gmail | Outlook / Exchange Online |
|---|---|---|
| Native routing | Labels, archive, delete, star, forward, skip inbox | Mailbox rules with actions and exceptions |
| Named constraint | 500 filters per account | 256 KB maximum enabled-rule quota |
| Disabled rules | Still subject to Gmail's account filter model | Don't count toward the active quota |
| Advanced relationship logic | Not native | Not native in the standard rule model |
| Safe staged testing | Basic native preview is limited | Rule testing and auditability require additional process |
| Best fit | Straightforward sender, subject, and list routing | Conventional mailbox sorting and exceptions |
The gap appears when a founder wants “all mail from people who haven't received a reply moved to review,” or an IT lead wants a shared policy based on sender identity, headers, attachments, and mailbox state. A richer filter builder can evaluate those signals, preview real mail, keep new filters paused, and preserve a decision history.
KeepKnown is one option for that gap. Its filters can use up to 20 conditions across three nested group levels, with signals including contacts, prior replies, VIP domains or groups, headers, subject metadata, attachments, and mailbox state. Outcomes can keep, move, label or categorize, prioritize, hold for review, or add matching mail to a digest. Exact actions and modes vary by provider, so Gmail, Google Workspace, Outlook, and Microsoft 365 shouldn't be treated as identical. A broader email security comparison can help teams separate native protection from advanced routing.
Encryption Filtering and Allow List Strategies
TLS protects messages while they travel between mail servers. It limits passive interception during delivery, but it does not protect a message after arrival in a mailbox or after an attacker gains control of the account.
S/MIME adds message signing and encryption, though certificate distribution and lifecycle management create work that small teams often avoid. Provider-managed encryption is simpler for routine communications. S/MIME remains useful when both parties can manage certificates and need message-level assurance.
Filtering should preserve recoverability
Spam filtering works through several layers. Connection reputation assesses the infrastructure sending the message. Content checks inspect message characteristics, links, and attachments. Behavioral analysis identifies unusual sender or communication patterns.
These controls work best against broad campaigns. They provide less certainty when a vendor mailbox is compromised or an attacker imitates a trusted relationship. An allow-list strategy adds an operational control by handling approved senders, domains, contacts, or VIP groups differently from unfamiliar mail.
A practical routing policy should:
- Keep approved contacts visible: Mail from known customers, vendors, investors, and internal leaders stays in the primary inbox.
- Review unfamiliar senders: First-time contacts move to a recoverable review label or queue rather than being deleted.
- Batch repetitive messages: Newsletters, alerts, and low-priority vendor notices go to a digest or secondary category.
- Prioritize sensitive relationships: Messages from approved investor, customer, or executive domains receive a higher-priority outcome.
- Preserve exceptions: A known sender with a suspicious attachment or failed authentication still receives additional scrutiny.
The goal is to reduce repeated low-value interruptions without losing legitimate first contact. Core KeepKnown filtering does not read email bodies. Relationship signals use per-user HMAC-SHA256 tokens, while encrypted subject metadata is used only when a rule requires it. Teams can therefore apply richer routing while keeping message content out of routine filtering decisions.
Policies Training Incident Response and Monitoring
Technical controls fail when people don't know who owns the decision. A founder or IT lead should publish a short acceptable-use policy covering personal use, forwarding, external sharing, mailbox access from devices, and the steps required before changing payment details.
Training should use realistic scenarios rather than generic warnings. Vendor impersonation, payroll diversion, gift card requests, fake threads, and urgent executive messages test whether people verify the request instead of merely recognizing suspicious formatting. A recurring 90-day training cadence is a practical recommendation for keeping those behaviors active, while the specific schedule should match the organization's risk and staffing.
Build an incident response path
A small team needs a runbook that answers four questions immediately:
- Who receives the report? Name the IT lead, operations owner, or security contact.
- Who can contain the account? Define authority for password resets, session revocation, and mailbox review.
- Who verifies financial requests? Require an independent channel for bank, payroll, and invoice changes.
- Who communicates the outcome? Assign responsibility for notifying affected staff, vendors, and customers.
A 30-minute triage target can be used as an internal operating goal for suspected account compromise, but it isn't a verified industry benchmark. The runbook should cover quarantine, recall where the provider supports it, account containment, mailbox search, forwarding-rule review, and notification.
Operating principle: A reported phish is an incident signal, not an employee performance test.
Monitor control health, not vanity metrics
Useful indicators include DMARC aggregate pass rate, the ratio of messages sent to spam quarantine, and the time between a user noticing a phish and reporting it. Teams should also review false positives, unresolved review-queue items, and failed payment-verification exceptions.
For executives, allow-list routing can reduce noise without making the inbox a closed system. VIP mail stays visible, while unfamiliar senders enter a recoverable review path. That arrangement supports both attention management and security review, provided the policy includes an escalation route for urgent legitimate contacts.
A 30 Day Plan for Founders Executives and Small Teams
A staged rollout keeps email security from becoming a disruptive all-at-once project. The plan below assigns work to the people who can complete it without building a large security department.
Week one establishes sender identity
Owner: IT lead or managed administrator. Time: one working session plus review.
Publish SPF and DKIM for every legitimate sending service, then create a DMARC monitoring policy. Build a list of marketing platforms, customer-support tools, finance systems, and other services that send mail for company domains.
Outcome: The organization can identify legitimate senders and begin reviewing authentication reports. Don't move to enforcement until the sending inventory is credible.
Run a baseline phishing exercise using a vendor-impersonation scenario. Keep the exercise focused on reporting behavior, not embarrassment. The result should identify which teams need clearer payment-verification instructions.
Week two tunes routing
Owner: IT lead with operations support. Time: several focused configuration sessions.
Adjust provider spam controls, review transport or mail-flow rules, and create a recoverable review location for messages that need attention but don't belong in the main inbox. Separate security quarantine from ordinary low-value mail so users don't mistake a newsletter queue for a malware quarantine.
Microsoft's rule quota makes consolidation important for Exchange Online mailboxes. Gmail's filter cap makes naming and retiring obsolete filters important for Google Workspace users. A rule inventory should record the owner, purpose, conditions, action, and review date.
Week three assigns responsibility
Owner: founder or operations lead. Time: one policy session and one short training session.
Publish a one-page acceptable-use policy. Record a 15-minute training video covering fake vendor requests, suspicious replies, unexpected attachments, and reporting steps. Finish the incident-response runbook with named owners and escalation contacts.
Teams that want a broader deployment model can compare this rollout with cloud-based email security service guidance, while keeping provider-specific capabilities separate from general planning advice.
Week four activates advanced routing
Owner: executive assistant, operations lead, or IT administrator. Time: staged testing followed by review.
Start with VIP and approved-contact routing for executive inboxes. Preview the filter against real mail, keep it paused while the team checks matches, then use Shadow or Review Only where the connected provider supports those modes. Enforce only after false positives and exceptions have been reviewed.
An advanced builder should show why a message matched and what happened next. KeepKnown calls a saved filter an Inbox Protocol, but the plain concept remains a filter. Its filters can route, label, prioritize, hold for review, or add mail to a digest, while exact enforcement behavior varies by provider.
Measure the result through review-queue quality, reported phish handling time, authentication-policy progress, and the reduction in repetitive inbox interruptions. The target isn't maximum blocking. It's a trustworthy, recoverable, auditable mail flow.
KeepKnown helps founders and operations teams build richer filters across Gmail, Google Workspace, Outlook, and Microsoft 365, preview matches on real mail, and activate rules in staged modes where supported. Visit KeepKnown to Build a filter for an inbox workflow or Run free audit for Gmail cleanup, with recoverable routing instead of permanent deletion.