Email Security for SaaS

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 16 — Email Security for SaaS. Alice, I feel like email is one of those things everybody uses but nobody thinks about securing properly.

Alice: Because it’s invisible infrastructure. Your legal SaaS platform sends hundreds of transactional emails daily — password resets, case update notifications, court deadline reminders, magic-link logins. And every single one of those is an attack vector if your email authentication isn’t locked down.

Dan: Give me the scale of the problem.

Alice: The FBI reported 2.9 billion dollars in business email compromise losses in 2023 alone. And Verizon’s DBIR — their annual Data Breach Investigations Report — consistently shows that 74% of all breaches involve a human element — predominantly phishing and pretexting via email. For legal tech, a spoofed court deadline email from your domain could cause a lawyer to miss a filing. That’s malpractice territory.

Dan: So how do you prove your emails are actually from you?

Alice: Three mechanisms that work together. SPF, DKIM, and DMARC. SPF — Sender Policy Framework — publishes a DNS record — DNS being the internet’s address book that translates domain names to IP addresses — listing which IP addresses can send email on behalf of your domain. When Gmail receives an email claiming to be from notifications@yourlegalplatform.com, it checks your SPF record. If the sending IP isn’t listed, the email fails authentication.

Dan: Simple enough. What about DKIM?

Alice: DKIM — DomainKeys Identified Mail — adds a cryptographic signature to every outgoing email. Your sending server signs the headers and body with a private key. The receiving server retrieves your public key from DNS and verifies the signature. This proves two things: the email genuinely came from your infrastructure, and it wasn’t modified in transit.

Dan: And DMARC ties them together?

Alice: DMARC — Domain-based Message Authentication, Reporting, and Conformance — does three things. First, it tells receiving servers what to do when SPF and DKIM both fail — none, quarantine, or reject. Second, it requires domain alignment — the domain in the From header must match the domains used in SPF and DKIM checks. Third, it sends you aggregate reports showing who’s attempting to send email as your domain.

Dan: What policy should a legal SaaS platform use?

Alice: The goal is p=reject — meaning any email that fails both SPF and DKIM authentication gets rejected outright, never delivered. But you don’t jump there on day one. Start with p=none to collect reports without affecting delivery. Monitor for two weeks. You’ll discover forgotten systems — that old marketing tool, the CRM integration, the legacy notification server. Add them to your SPF record and configure DKIM. Move to p=quarantine for two weeks. Then p=reject. Google now requires SPF, DKIM, and DMARC for bulk senders as of 2024.

Dan: What about magic links? Passwordless login seems elegant but I’m guessing it has risks.

Alice: Magic links are a single-use URL sent to your email that logs you in when clicked. They’re popular because they eliminate password management. But they inherit every vulnerability of the email channel. If an attacker has access to your inbox — even temporarily — they click the link and they’re in. If your corporate email proxy prefetches URLs for security scanning, it might consume the token before you can use it. If you forward the email, you’ve forwarded your login.

Dan: How do you harden them?

Alice: Five controls. One — bind the magic link to the browser session that requested it. The link only works in the same browser. Two — short time-to-live. Five to ten minutes maximum, not hours. Three — single use, obviously, but also rate-limit requests — maximum three per email per hour. Four — device fingerprinting. If the link is clicked from a completely different IP range or device, require additional verification. Five — notify on consumption. When the link is used, especially from a new device, send a separate alert.

Dan: What about account recovery? That’s basically the master key to everything.

Alice: Account recovery via email is the nuclear option that bypasses every other security control you’ve built. Multi-factor authentication — MFA, where you need a second proof of identity beyond just your password — strong passwords, session management — all meaningless if an attacker can trigger a password reset and intercept the email. Lapsus$ specifically targeted help desk staff to initiate email-based resets for their victims. For legal SaaS, never rely solely on email for recovery. Combine with out-of-band verification — a phone call, an admin approval workflow, identity questions. And after any recovery event, impose a cool-down period — no downloading documents or changing security settings for 24 hours.

Dan: I want to talk about something I’ve seen in Gmail recently — brand logos next to emails. That’s BIMI?

Alice: BIMI — Brand Indicators for Message Identification. It displays your verified logo next to your emails in supporting clients like Gmail, Apple Mail, and Yahoo. It requires DMARC at p=quarantine or p=reject, plus a Verified Mark Certificate from DigiCert or Entrust. The security value is subtle but real — it trains recipients to expect your logo. A phishing email spoofing your domain won’t display it, creating a visual discrepancy that alert users will notice.

Dan: That makes sense. What’s the architectural principle here? What should email actually be used for in a legal SaaS platform?

Alice: Email is a notification channel. Never a data transport channel. Your case update email should say “You have a new update on Matter 2024-1234 — log in to view it.” Not “Here’s the full update: opposing counsel filed a motion to dismiss arguing...” The moment you put privileged content in an email body, you’ve lost control of it. It sits in inboxes, gets forwarded, gets backed up to systems you don’t control, gets indexed by email search tools.

Dan: And transport security?

Alice: MTA-STS — SMTP MTA Strict Transport Security. SMTP is Simple Mail Transfer Protocol — the standard way email servers send messages to each other. It publishes a policy requiring TLS for email delivery to your domain. Without it, an attacker performing a network-level attack can strip TLS from the SMTP connection and intercept emails in plaintext. MTA-STS prevents that downgrade attack. Combined with DANE — DNS-based Authentication of Named Entities — if your DNS supports DNSSEC — DNS Security Extensions, which cryptographically sign DNS responses — you get assurance that the receiving server’s TLS certificate is legitimate.

Dan: One last thing — multi-tenant considerations. If your platform serves multiple law firms, does each firm need its own email setup?

Alice: Ideally yes. Each tenant sends from their own subdomain — firmname.yourplatform.com — with dedicated SPF and DKIM records. This isolates sender reputation. If one tenant’s users report emails as spam, it doesn’t tank deliverability for all your other tenants. And it prevents a compromised tenant’s subdomain from being used to phish users of another tenant on your platform.

Dan: Next episode — Password Hashing Done Right. Why storing passwords “encrypted” is almost as bad as storing them in plaintext.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.