Email Authentication 101: SPF, DKIM, and DMARC Explained for SaaS Founders

If you're a SaaS founder sending transactional or outbound emails, there's a good chance your messages are landing in spam folders without you even knowing it. The culprit? Missing or misconfigured email authentication records.

In this guide, I'll break down the three pillars of email authentication: SPF, DKIM, and DMARC. No fluff, just what you need to know as a developer or technical founder to get your domain's email reputation right from day one.

Why Email Authentication Matters

Every time your server sends an email, the receiving mail server asks three questions:

1. Is this sender allowed to send on behalf of this domain? (SPF)
2. Was this message tampered with in transit? (DKIM)
3. What should I do if SPF or DKIM fails? (DMARC)

If you can't answer these questions with properly configured DNS records, inbox providers like Gmail, Outlook, and Yahoo are increasingly likely to reject or quarantine your messages.

According to Google's 2024 sender guidelines, bulk senders (5,000+ messages/day to Gmail) are now required to have SPF, DKIM, and DMARC configured. Yahoo has adopted similar requirements. This isn't optional anymore.

SPF: Sender Policy Framework

What It Does

SPF lets you declare which mail servers are authorized to send email on behalf of your domain. It's a DNS TXT record that receiving servers check against the IP address of the sending server.

How to Set It Up

Add a TXT record to your domain's DNS:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com include:sendgrid.net ~all

Breaking this down:

• v=spf1 declares this is an SPF record
• include:_spf.google.com authorizes Google Workspace servers
• include:sendgrid.net authorizes SendGrid's servers
• ~all soft-fails anything not listed (use -all for hard-fail once you're confident)

Key Constraints

• You can only have one SPF record per domain. Multiple records will cause validation failures.
• SPF has a 10 DNS lookup limit. Each include: counts as a lookup. Nested includes count too. Exceeding this limit silently breaks your SPF.

DKIM: DomainKeys Identified Mail

What It Does

DKIM adds a cryptographic signature to every outgoing email. The receiving server can verify this signature using a public key published in your DNS. This proves the message hasn't been altered in transit and that it originated from an authorized sender.

How to Set It Up

Your email service provider (ESP) will generate a DKIM key pair. You publish the public key as a DNS TXT record:

Type:  TXT
Host:  selector1._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA...

Breaking this down:

• selector1._domainkey is the selector name (provided by your ESP) plus the fixed _domainkey suffix
• v=DKIM1 is the DKIM version
• k=rsa is the key type
• p=... is your public key (the long base64 string your ESP gives you)

How to Verify

Send a test email to a Gmail address and open the original message headers. Look for:

Authentication-Results:
  dkim=pass header.d=yourdomain.com

You can also use command-line tools:

dig TXT selector1._domainkey.yourdomain.com

DMARC: Domain-based Message Authentication, Reporting & Conformance

What It Does

DMARC ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails, and where to send reports about it.

How to Set It Up

Add a TXT record:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Breaking this down:

• v=DMARC1 is the DMARC version
• p=none is the policy (monitor only, no action on failures)
• rua=mailto:... is where aggregate reports get sent
• pct=100 applies the policy to 100% of messages

The Three Policy Levels

Recommended rollout: Start with p=none for 2-4 weeks while reviewing reports. Move to p=quarantine, then p=reject once you're sure all legitimate sending sources are authenticated.

Common Mistakes to Avoid

1. Multiple SPF Records

Adding a second SPF TXT record instead of merging include: statements into one record. DNS returns both, and validators may reject them.

Wrong:

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

Right:

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

2. Exceeding the SPF Lookup Limit

Every include:, a, mx, and redirect mechanism counts toward the 10-lookup cap. If you use multiple ESPs, CRM tools, and support desk platforms, you can easily exceed this. Use an SPF flattening tool or consolidate your sending infrastructure.

3. Skipping DMARC Entirely

SPF and DKIM alone aren't enough. Without DMARC, there's no policy for what happens on failure, and you won't receive reporting data. Even p=none is better than no DMARC record at all.

4. Setting p=reject Too Early

Jumping straight to a reject policy before auditing all sending sources (marketing tools, transactional email, CRM, support platforms) will cause legitimate emails to bounce.

5. Forgetting Subdomains

If you send from mail.yourdomain.com or news.yourdomain.com, those subdomains need their own SPF and DKIM records. DMARC on the root domain can cover subdomains with the sp= tag, but SPF and DKIM don't inherit automatically.

Quick Verification Checklist

Once you've set everything up, validate your configuration:

1. MXToolbox (mxtoolbox.com/spf.aspx) for SPF syntax and lookup count
2. Mail-tester (mail-tester.com) for a test email deliverability score
3. Gmail headers by sending to Gmail, clicking "Show original," and checking Authentication-Results
4. DMARC reports by waiting 24-48 hours after setup and reviewing aggregate XML reports at your rua address

Simplifying the Setup

If you're building a SaaS that sends cold outreach or transactional email, getting authentication right is table stakes. But it's also the kind of infrastructure work that eats into time you'd rather spend on product.

That's one of the reasons I built ColdMail. It handles email infrastructure concerns like domain warm-up guidance and deliverability so founders can focus on writing emails that actually convert, rather than debugging DNS records.

TL;DR

Set up all three. Monitor your DMARC reports. Graduate your policy. Your deliverability will thank you.

Have questions about email authentication or cold email infrastructure? Drop a comment below.