SPF Record Patterns for SaaS Applications

If you run a SaaS application, your product sends email. Signup confirmations, password resets, invoice receipts, activity notifications, team invitations -- these transactional messages are critical to your user experience. When they land in spam or get rejected, users think your app is broken.

SPF is the first step to making sure those emails actually reach your users' inboxes. But SaaS email has unique challenges that set it apart from a typical business setup. You're sending high volumes of transactional email alongside team communication, and you need a strategy that keeps both streams healthy without one affecting the other.

The SaaS Email Problem

Most SaaS companies have two distinct email streams:

1. Application email -- Automated transactional messages sent by your product (signups, resets, notifications, alerts). High volume, sent through services like SendGrid, Amazon SES, or Postmark.
2. Corporate email -- Day-to-day team communication sent through Google Workspace or Microsoft 365. Lower volume, person-to-person.

Both streams use your domain. If you put everything on yourdomain.com, a deliverability problem with one stream affects the other. A spike in bounces from your transactional email can damage the domain reputation that your sales team relies on for outreach. A misconfigured marketing campaign can tank deliverability for your application's password reset emails.

The Subdomain Strategy

The recommended pattern for SaaS applications is to separate email streams using subdomains. Your corporate email stays on the root domain, and your application email goes on a dedicated subdomain.

Root domain (yourdomain.com) -- corporate email:

v=spf1 include:_spf.google.com -all

Application subdomain (mail.yourdomain.com) -- transactional email:

v=spf1 include:sendgrid.net -all

This separation gives you several advantages:

• Independent SPF records. Each domain/subdomain gets its own 10 DNS lookups. You'll never hit the lookup limit with this pattern.
• Isolated reputation. Deliverability issues on one subdomain don't affect the other.
• Clearer monitoring. You can track bounces, complaints, and deliverability metrics for each stream separately.
• Easier debugging. When something goes wrong, you know exactly which stream is affected.

Common subdomain choices for SaaS application email include mail.yourdomain.com, app.yourdomain.com, notify.yourdomain.com, or transactional.yourdomain.com. Pick one that makes sense for your team and stick with it. Learn more in our guide on SPF records for subdomains.

Common SaaS Email Stacks

Here are SPF records for the most popular SaaS email configurations. Use the free SPF record generator to build a custom record for your specific setup.

SendGrid + Google Workspace

The most common SaaS stack. SendGrid handles transactional email from your app, Google Workspace handles team email.

On yourdomain.com:

v=spf1 include:_spf.google.com -all

On mail.yourdomain.com:

v=spf1 include:sendgrid.net -all

Amazon SES + Google Workspace

Popular with AWS-native SaaS companies. Amazon SES is tightly integrated with AWS infrastructure and priced for high volume.

On yourdomain.com:

v=spf1 include:_spf.google.com -all

On mail.yourdomain.com:

v=spf1 include:amazonses.com -all

Postmark + Microsoft 365

Postmark is known for exceptional deliverability and is a favorite among SaaS teams that prioritize inbox placement for transactional email.

On yourdomain.com:

v=spf1 include:spf.protection.outlook.com -all

On mail.yourdomain.com:

v=spf1 include:spf.mtasv.net -all

Everything on the Root Domain (Small SaaS)

If you're a small SaaS company with modest email volume, you might not need the subdomain approach yet. You can keep everything on the root domain as long as you stay within the lookup limit:

v=spf1 include:_spf.google.com include:sendgrid.net -all

This works fine until you add a marketing tool, a helpdesk, or a second transactional provider. At that point, move to the subdomain pattern.

Dedicated IP Considerations

Most transactional email providers send your email from shared IP addresses by default. For SaaS companies with higher volumes (typically 50,000+ emails per month), a dedicated IP address can make sense.

With a dedicated IP, your sending reputation is entirely your own -- other senders' behavior doesn't affect you. You can add this IP directly to your SPF record using an ip4 mechanism, which doesn't count toward the lookup limit:

v=spf1 ip4:198.51.100.25 -all

However, dedicated IPs require you to maintain your own sending reputation from scratch, and they need enough consistent volume to maintain a positive reputation. If your volume is low or inconsistent, shared IPs through your provider are usually the better choice.

Setting Up SPF for Your SaaS Application

Don't Forget Non-Sending Subdomains

If you create mail.yourdomain.com for transactional email, what about staging.yourdomain.com, dev.yourdomain.com, or cdn.yourdomain.com? Any subdomain without an SPF record is a potential spoofing target. Add v=spf1 -all to every subdomain that should never send email. See our guide on SPF records for parked domains for more on protecting non-sending domains.