Skip to content
Back to Blog
DMARC.WS Team··9 min read

Email Authentication for SaaS Companies: A Practical Guide

SaaSEmail AuthenticationBest PracticesDMARC

The SaaS Email Challenge

SaaS companies send email from more sources than almost any other type of business. A typical SaaS product might use:

  • Google Workspace for team email
  • SendGrid or Postmark for transactional emails (password resets, welcome emails, invoices)
  • Mailchimp or HubSpot for marketing campaigns
  • Zendesk or Intercom for customer support
  • The application itself for in-product notifications
  • Salesforce for sales outreach
  • Various internal tools for alerting and monitoring

Each of these services sends email "from" your domain. Each one needs to be properly authenticated. Miss one, and you've got an authentication gap that either triggers DMARC failures or blocks your path to enforcement.

Step 1: Inventory Every Email Source

Before configuring anything, list every service that sends email using your domain. Check:

  • Marketing: Email campaigns, drip sequences, newsletters
  • Product: Transactional emails, notifications, digests
  • Support: Helpdesk replies, satisfaction surveys
  • Sales: CRM-sent emails, sequences
  • Engineering: Monitoring alerts, error notifications, CI/CD notifications
  • Internal: HR systems, internal communication tools

Don't forget less obvious sources:

  • Calendar invitations (Google Calendar, Calendly)
  • Document sharing notifications (Google Docs, Notion)
  • Payment receipts (Stripe, billing systems)
  • Signup forms that send confirmation emails

Step 2: Configure SPF

Add each service's sending infrastructure to your SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:spf.mandrillapp.com -all

Watch the Lookup Limit

With many services, you'll quickly approach the 10-lookup limit. SaaS companies are particularly vulnerable to this.

Strategy: Use subdomains to segment your email:

; Main domain — business email only
example.com    TXT "v=spf1 include:_spf.google.com -all"

; Marketing subdomain
marketing.example.com    TXT "v=spf1 include:sendgrid.net -all"

; Notifications subdomain
notify.example.com    TXT "v=spf1 include:amazonses.com -all"

; Support subdomain
support.example.com    TXT "v=spf1 include:mail.zendesk.com -all"

Each subdomain gets its own 10-lookup budget. As a bonus, sending reputation is isolated — a marketing campaign that triggers spam complaints doesn't affect your transactional email deliverability.

Step 3: Configure DKIM for Every Service

Each email service needs its own DKIM signing configuration:

Google Workspace

  • Generate DKIM key in Admin Console
  • Publish the key at google._domainkey.example.com

SendGrid

  • SendGrid provides a CNAME-based DKIM setup
  • Publish CNAMEs at s1._domainkey.example.com and s2._domainkey.example.com

Application Email (via SES, Postmark, etc.)

  • Each service has its own DKIM setup process
  • Some use CNAME records, others use TXT records
  • Follow each provider's documentation exactly

Verify Each Service

After setting up DKIM for each service, send a test email and check the Authentication-Results header:

dkim=pass header.d=example.com header.s=google

The header.d should match your domain (or subdomain), and the header.s should match the selector you configured.

Step 4: Deploy DMARC

Start with Monitoring

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1

Use fo=1 to get forensic reports for any authentication failure, not just complete failures.

Analyze Reports for 2–4 Weeks

Look for:

  • Services you forgot to authenticate
  • Third-party integrations sending email as your domain
  • Legacy systems or scripts still sending unauthenticated email
  • Alignment issues (SPF passes but doesn't align, DKIM passes but wrong domain)

Common SaaS Findings

  • Staging/development environments sending email as the production domain
  • Webhooks and integrations that trigger email from third-party services
  • Customer-facing features that send email on behalf of users (e.g., "share this report")
  • Partner integrations where another company sends email using your domain

Step 5: Use Subdomains Strategically

For SaaS companies, subdomains are your best friend:

example.com           — Business email (Google Workspace)
notify.example.com    — Product notifications (SES/Postmark)
marketing.example.com — Marketing campaigns (SendGrid/Mailchimp)
support.example.com   — Support responses (Zendesk/Intercom)

Benefits:

  • Reputation isolation: Marketing issues don't affect transactional deliverability
  • SPF simplification: Each subdomain has fewer includes
  • Flexible DMARC policies: You can enforce DMARC on your main domain while keeping a subdomain at p=quarantine during testing
  • Clearer reporting: DMARC reports are organized by subdomain

Step 6: Handle Application-Sent Email

If your SaaS application sends email directly (not through a third-party ESP), ensure:

  1. The sending server's IP is in SPF (or the subdomain's SPF)
  2. DKIM signing is implemented in your application code or mail transfer agent
  3. The From address domain aligns with your DMARC-authenticated domain
  4. Return-Path (envelope sender) is set correctly for SPF alignment

Common Application Email Patterns

Direct SMTP sending: Your app connects to an SMTP relay (Postmark, SES, SendGrid API). Authentication is handled by the relay — you just need their SPF include and DKIM keys.

Self-hosted mail server: Your app sends through your own SMTP server. You need to manage SPF (add the server's IP), DKIM (generate and configure keys), and ensure proper header alignment.

Step 7: Enforce Gradually

Follow the standard enforcement path:

  1. p=none — Monitor (2–4 weeks)
  2. p=quarantine; pct=25 — Soft enforcement (1–2 weeks)
  3. p=quarantine — Full quarantine (2 weeks)
  4. p=reject; pct=25 — Reject ramp (1–2 weeks)
  5. p=reject — Full enforcement

For subdomains, you can enforce at different speeds. Your main domain (business email) is usually the easiest to enforce because it has the fewest senders.

Ongoing Maintenance

When Adding New Services

Before connecting any new service that sends email:

  1. Check if it supports custom DKIM
  2. Add its SPF include to the appropriate domain/subdomain
  3. Configure and verify DKIM
  4. Send test emails and check authentication headers
  5. Monitor DMARC reports for the first week

When Removing Services

Remove the SPF include and clean up DKIM DNS records. Stale SPF includes waste your lookup budget. Stale DKIM records don't cause harm but are messy.

Quarterly Review

  • Audit all email-sending services
  • Check SPF lookup counts on all domains/subdomains
  • Review DMARC reports for unexpected sources
  • Verify DKIM keys haven't been rotated by providers without your knowledge

Summary

SaaS companies face a unique email authentication challenge: many services, many subdomains, many stakeholders. The solution is systematic — inventory everything, use subdomains strategically, authenticate every source, and enforce gradually.

The payoff is significant: better deliverability, brand protection, and the confidence that no one can impersonate your domain to your customers.