Why email security matters for compliance
Email is the single biggest attack vector for SaaS companies. The FBI's Internet Crime Report consistently lists Business Email Compromise (BEC) as the largest source of cybercrime losses — $2.9B in 2023 alone. Phishing accounts for 36% of breaches (Verizon DBIR 2024). And every compliance framework that touches security has email controls baked in.
Yet many SaaS founders treat email as a solved problem because they use Google Workspace or Microsoft 365. The platforms are good — but the default configuration is not what auditors expect, and certainly not what stops a targeted BEC attack.
| Framework | Specific Requirement | What Auditors Check |
|---|---|---|
| ISO 27001 A.8.23 | Web Filtering & Email Security — protect against email-borne threats | Email security policy; gateway controls; phishing protection deployment |
| ISO 27001 A.8.7 | Protection against malware — including via email | Anti-malware on email; sandbox/detonation evidence |
| SOC 2 CC6.7 | Restricting information transmission | DLP for outbound; encryption when required |
| NIS2 Art. 21(2)(g) | Cyber hygiene practices & training including phishing | Training records; phishing simulation results |
| HIPAA §164.312(e)(1) | Transmission security for ePHI | Encryption of email containing PHI; BAA coverage |
| PCI DSS Req 5 + 4.2.1 | Anti-malware on email systems; strong crypto for PAN in transit | Anti-malware reports; DLP block records for PAN |
| GDPR Art. 32 | Appropriate TOMs for security of processing | Email controls supporting overall security posture |
| CIS Control 9 | Email and Web Browser Protections | DMARC deployment; file-type filtering; user training |
Email authentication: the three-layer stack
SPF, DKIM, and DMARC are the three protocols that together prevent domain spoofing. Without all three properly configured, anyone can send email pretending to be your domain.
SPF (Sender Policy Framework)
SPF is a DNS TXT record that lists which servers are authorised to send mail on behalf of your domain. When a receiver gets mail claiming to be from your domain, they check SPF against the actual sending server.
- Hard fail (-all): Receivers reject mail from non-authorised senders. Recommended.
- Soft fail (~all): Receivers mark as suspicious but may deliver. Not full enforcement.
- Common misconfiguration: Too many includes — SPF has a 10-DNS-lookup limit. Once you exceed this, SPF starts failing for all mail. Consolidate or use SPF flattening services.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing email headers. The public key is published in DNS. Receivers verify the signature to confirm the message was authorised and unmodified in transit.
- Key size: 2048-bit minimum. 1024-bit is deprecated and considered insecure.
- Rotation: Rotate keys at least annually. Use selectors to allow zero-downtime rotation.
- Per-service signing: Each service sending on your behalf (mailgun, sendgrid, etc.) gets its own selector and key.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is the policy layer on top of SPF and DKIM. It tells receivers what to do with mail that fails both checks, AND it sends you reports on what mail is being sent claiming to be from your domain.
| Policy | What It Does | When to Use |
|---|---|---|
p=none | Monitoring only — receivers take no action on failures, but send you aggregate reports | Initial deployment: 30–60 days to discover all legitimate senders |
p=quarantine | Failing mail sent to spam/junk folder | Mid-stage: after p=none confirms legitimate senders aligned; 30–90 days |
p=reject | Failing mail rejected outright — doesn't reach the recipient | Target enforcement state. Maximum spoofing protection. |
Critical: p=none is monitoring, not compliance. It does not stop spoofing. Many companies publish p=none and call themselves DMARC-compliant. They are not protected. Progress through the policy levels.
Aggregate reports (rua=): Publish a reporting address. You'll receive XML reports from major receivers (Google, Microsoft, Yahoo) showing which IPs are sending mail claiming to be your domain. Review weekly during rollout. Tools like Postmark DMARC, dmarcian, or Valimail process these into dashboards.
Forensic reports (ruf=): Sample copies of failing messages. Can contain personal data — handle per GDPR. Many receivers don't send these anymore due to privacy concerns.
MTA-STS: TLS enforcement for inbound
MTA-STS forces sending servers to use TLS when delivering mail to your domain. Without it, mail can be downgraded to cleartext by network attackers. Pair with TLS-RPT (TLS reporting) to detect when partners can't use TLS.
Business Email Compromise (BEC)
BEC isn't a malware attack — it's a social engineering attack. Attackers impersonate executives or vendors to trick employees into wiring money or sharing credentials. Total losses exceeded $2.9B in 2023 (FBI IC3). Common patterns:
- CEO fraud: Email from "the CEO" to finance asking for an urgent wire transfer. Often sent from a look-alike domain or a compromised account.
- Vendor impersonation: "Your supplier has changed bank details — please update for the next invoice." Attacker has often compromised the vendor's email.
- Payroll redirect: Employee "asking HR" to redirect salary to a new account.
- Account takeover: Real compromised account used to insert into existing legitimate conversations.
BEC bypasses traditional malware filters because there's no malicious payload — just words and a wire instruction. Detection requires impersonation protection, anti-AI/ML behavioural filtering, and — most importantly — process controls (out-of-band verification for any payment instruction change).
Anti-phishing controls stack
| Control | Google Workspace | Microsoft 365 | What It Catches |
|---|---|---|---|
| SEG / Gateway | Native + 3rd-party (Mimecast, Proofpoint) | Defender for Office 365 + 3rd-party | Spam, known-malicious senders, basic phishing |
| AI/ML behavioural filtering | Security Sandbox + Workspace AI | Defender O365 Plan 2; Abnormal Security | Zero-day phishing, novel BEC patterns |
| Sandboxing (detonation) | Security Sandbox | Safe Attachments / Safe Links | Malicious attachments + URLs detonated in safe environment before delivery |
| URL rewriting / time-of-click | 3rd-party required | Safe Links | Delayed weaponised URLs (safe at delivery, weaponised hours later) |
| External email banner | Native external sender warning | External tag + transport rule banner | User awareness that sender is outside organisation |
| Impersonation protection | Workspace impersonation protection | Anti-impersonation (Defender O365) | Look-alike executive/vendor domains; display-name spoofing |
| Phishing simulation | 3rd-party (KnowBe4, Hoxhunt) | Attack Simulator (Plan 2) or 3rd-party | Measures + trains user susceptibility |
External email warning banners
One of the highest-ROI, lowest-effort controls. A visible banner on every email from outside your organisation that says "this is external; verify before acting" reduces successful phishing significantly.
Suggested banner text:
⚠️ This message originated from outside [your company]. Do not click links or open attachments unless you recognise the sender. Report suspicious messages to phishing@[yourdomain].
Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Compliance → Content compliance rule. Apply to inbound, prepend banner HTML.
Microsoft 365: Exchange Admin Center → Mail flow → Rules → New rule: "Prepend disclaimer" with condition "sender is located outside the organisation". Also enable native external sender tag (Outlook).
DLP rules for email
Email DLP prevents accidental or malicious data leakage. Configure rules per data classification:
- PII (personal data): Detect email addresses, phone numbers, IDs at scale (>10 records in one email). Action: quarantine for review, or encrypt before send.
- PCI (cardholder data): Detect PAN regex with Luhn validation. Action: block. PAN should never be in unencrypted email.
- PHI (health data): Detect medical record numbers, diagnosis codes, HIPAA identifiers. Action: block unless TLS-enforced + recipient on approved list, or end-to-end encrypted.
- Source code / credentials: Detect API key formats, private key headers. Action: block.
- Personal email recipients: Warn user when sending to gmail/outlook/yahoo addresses if email contains confidential content.
Email encryption: when required
| Scenario | Encryption Required | Practical Approach |
|---|---|---|
| PHI to external recipient | Yes (HIPAA §164.312(e)(1)) | Platform-managed (M365 Information Protection / Google Confidential Mode) or S/MIME |
| Financial data / wire instructions | Strongly recommended | Out-of-band verification + TLS minimum; encrypted email for documents |
| Legal privileged communications | Yes | Platform-managed or S/MIME; "Do Not Forward" rights |
| Cross-EU/EEA boundary with PII | Depends on transfer mechanism; encryption is part of TOMs | TLS in transit minimum; platform encryption for high sensitivity |
| Routine internal mail | TLS in transit (platform-default) | Confirm MTA-STS / forced TLS to known partners |
Practical options:
- S/MIME: Strongest, but certificate management is painful. Deploy to executives and high-sensitivity roles only.
- Platform-managed (Google Confidential Mode / Microsoft Purview Information Protection): Good middle ground; user-friendly; integrates with DLP.
- TLS in transit only: Default; not end-to-end. Adequate for most internal mail; insufficient for PHI to external.
Email archiving by regulation
| Framework | Minimum Retention | Notes |
|---|---|---|
| SOC 2 / ISO 27001 | No explicit; policy-defined | 1–3 years typical |
| HIPAA §164.316(b)(2) | 6 years for PHI-touching communications | If covered entity / BA |
| PCI DSS Req 10.5.1 | 12 months minimum for CHD-related | Ideally PAN never in email |
| GDPR | Proportionate; not excessive | Marketing consent records: 7 years post-relationship |
| Legal hold | Indefinite during hold | Supersedes standard retention |
Phishing simulation programme
A good phishing simulation programme has 4 components:
- Frequency: Quarterly minimum. Monthly campaigns for higher-risk roles (finance, exec, HR).
- Variety: Mix of difficulty — obvious to sophisticated. Include BEC-style and credential-harvest variants.
- KPIs: Track click rate (target ≤5%), report rate (target ≥25%), repeat-clickers per quarter (target trending down).
- Just-in-time training: Users who click receive immediate, short training (not punitive). Repeat clickers escalated for targeted coaching.
Reporting rate matters more than click rate. A team that reports phishing fast detects real attacks fast. Reward reporting.
Email compromise: 6-step response
- Identify: User reports compromise, anomaly alert, or external notification (partner says they got phishing from you).
- Contain: Force password reset; revoke all active sessions; disable mailbox access; disable any auto-forward or inbox rules created during the compromise window (these are typical BEC indicators).
- Assess scope: Pull mailbox audit log. What was accessed? Sent? Forwarded? Deleted? Were customer or personal data records exposed?
- GDPR 72h trigger: If personal data was likely accessed/exfiltrated, assess risk per Art. 33. If risk to data subjects, notify supervisory authority within 72 hours. If high risk, notify affected data subjects per Art. 34.
- Notify affected parties: External recipients of malicious outbound mail; payment partners if wire fraud attempted; relevant business stakeholders.
- Root cause: Was MFA enabled? Was password reused/breached? Phishing kit? Document and fix the gap that allowed the compromise.
6 common email security failures
- DMARC stuck at p=none. Monitoring only. Domain still spoofable. Move to p=reject.
- External banner not implemented. Users can't tell internal from external sender at a glance. BEC slips through.
- Auto-forwarding to external accounts allowed. Classic data exfiltration path; classic BEC persistence mechanism.
- DLP not configured. PII/PCI/PHI flows out via email without controls. Major audit finding.
- No phishing simulation. No measurement = no improvement = high click rates when real attack arrives.
- Personal email accounts used for work. Outside corporate controls, MFA, DLP, retention. Common at startups.
Related generators
Get started: Email Security Policy Generator, Information Security Policy, Incident Response Plan, Security Awareness Training Policy, IT & BYOD Policy, GDPR Breach Notification.
Related reading: Security Awareness Training Guide, GDPR Data Breach Notification, Access Control Policy Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. DMARC enforcement progression should be tested via monitoring (p=none + aggregate reports) before stepping to quarantine or reject. Consult a qualified email security specialist for your specific environment.