Email security practices for SaaS teams sending at volume

SaaS companies sit on both sides of email security: they're a frequent target for phishing campaigns impersonating their brand (fake "verify your account" or "invoice" emails), and they send high volumes of transactional and marketing mail where an authentication or process gap can tank deliverability for every customer-facing message, from password resets to billing receipts.

Why outbound authentication is a security control, not just a deliverability one

SPF, DKIM, and DMARC exist to prevent spoofing - the same records that improve inbox placement are what stop an attacker from sending phishing mail that appears to come from your domain. A SaaS company with DMARC at p=none (monitoring only, no enforcement) gets visibility into spoofing attempts via aggregate reports but doesn't actually block them; moving to p=quarantine or p=reject is the step that turns DMARC from a monitoring tool into protection, both for your own deliverability and for your customers who'd otherwise receive the spoofed mail.

Key threats specific to SaaS sending

• Brand impersonation phishing: attackers spoofing your domain or a close lookalike to send fake password-reset or billing emails to your actual customers - damaging to trust even though your infrastructure wasn't technically compromised.
• Compromised sending credentials: an exposed SMTP credential or API key for your ESP can let an attacker send spam or phishing mail that's fully authenticated as coming from your domain, since it's using your legitimate sending infrastructure - this is far more damaging to reputation than external spoofing, because the mail passes SPF and DKIM.
• Third-party sending sprawl: SaaS products commonly connect multiple systems to send as the company domain - the core transactional email service, a marketing ESP, a support/helpdesk tool, a status-page notifier - and each one needs to be in SPF and properly DKIM-signed, or it becomes either a deliverability gap or a security gap.

Practical steps

1. Enforce DMARC, moving from p=none to p=quarantine to p=reject as aggregate reports confirm legitimate senders are all correctly aligned - skipping straight to p=reject without monitoring first risks blocking your own legitimate mail.
2. Rotate and scope sending credentials. API keys and SMTP credentials used for transactional sending should be scoped to sending-only where the provider supports it, and rotated on a schedule or immediately on suspected exposure.
3. Audit SPF regularly. Every third-party tool added to send as your domain needs an SPF entry; an SPF record with unused or forgotten includes is both a deliverability risk (SPF has a 10-DNS-lookup limit that's easy to exceed) and a security risk (an unused include is a potential spoofing vector if that third party is ever compromised).
4. Separate transactional and marketing sending domains, so a security incident or reputation problem on one doesn't take down the other - a compromised marketing ESP credential shouldn't be able to affect password-reset deliverability.
5. Monitor DMARC aggregate reports on an ongoing basis, not just during initial setup - they're the clearest signal that something new is sending as your domain, authorized or not.

What not to do

• Don't leave DMARC at p=none indefinitely. Monitoring without enforcement provides visibility but no actual protection against spoofing.
• Don't share one SMTP credential across every system that sends as your domain - a single compromised credential then has broad blast radius.
• Don't add a new third-party sending tool to production without updating SPF and confirming DKIM signing before go-live - this is one of the most common causes of a sudden authentication failure.

A worked DMARC enforcement progression

A realistic rollout from first publishing a record to full enforcement, based on aggregate report review at each stage:

Week 1-2:  p=none; rua=mailto:dmarc@company.com
           -> collect reports, identify every legitimate sending source

Week 3-4:  Add missing sources to SPF, confirm DKIM signing for each,
           re-check aggregate reports show 100% alignment from known sources

Week 5-6:  p=quarantine; pct=25
           -> enforce on a quarter of mail, watch for unexpected drops
              in legitimate mail delivery

Week 7-8:  p=quarantine; pct=100
           -> full quarantine enforcement

Week 9+:   p=reject
           -> full enforcement once quarantine period shows no legitimate
              mail being caught

Note that pct itself is a tag DMARCbis (RFC 9989) removes going forward - this staged rollout pattern still works operationally during migration, but new records should move straight to full p=quarantine or p=reject once sources are confirmed, rather than relying on partial-percentage enforcement long-term.

A worked example of a compromised-credential signature in DMARC reports

<record>
  <row>
    <source_ip>198.51.100.77</source_ip>
    <count>6,200</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <spf>pass</spf>
      <dkim>pass</dkim>
    </policy_evaluated>
  </row>
</record>

This is the dangerous case: SPF and DKIM both pass because the sender is using your actual, legitimate SMTP credentials - meaning DMARC alone won't catch a compromised API key. The 6,200-message count from an unfamiliar IP is the signal to check against your known sending infrastructure list and rotate the credential immediately if it doesn't match.

DMARC policy tags and what skipping each one costs

A domain with p=none and no rua set has published DMARC in name only - it provides neither enforcement nor visibility, and is a common gap even at companies that believe they've "set up DMARC."

MailPilot checks SPF, DKIM and DMARC against what's actually published for a domain, and tracks per-mailbox reputation daily - useful for catching authentication drift (an SPF include that's missing, a DKIM selector that stopped signing) before it becomes either a deliverability problem or a spoofing exposure.