SPF, DKIM and DMARC setup for SaaS founders: a 10-minute guide

SPF, DKIM and DMARC are three DNS records that prove your emails really come from your domain. For most startups the setup is short. Your email provider gives you a few CNAME records (DKIM and a return path) and you add them at your DNS host. You leave your existing root SPF record alone. You publish one DMARC record at _dmarc.yourdomain.com. Then you send a test email to a Gmail address and check that SPF, DKIM and DMARC all say PASS.

The typing takes about ten minutes. DNS can take longer to update. This guide shows each step with example records, the mistakes we made while launching LuneaMail this month, and a checklist to confirm it works.

What each record does

A few terms first. DNS is the public address book for your domain. An ESP (email service provider) is the service that sends your app and marketing email, such as SendGrid, Postmark or Amazon SES.

• SPF (Sender Policy Framework) lists the servers allowed to send mail for a domain. Receivers check it against the hidden "return path" address, not the From address people see.
• DKIM (DomainKeys Identified Mail) adds a signature to every email. The receiver checks the signature with a public key published in your DNS. If the email was changed on the way, the check fails.
• DMARC tells receivers what to do when an email fails, and asks them to send you reports. It also checks alignment: the domain in the visible From address must match the domain that passed SPF or DKIM.

Alignment is the part most people miss. An email can pass SPF and DKIM for your provider's domain and still fail DMARC for yours.

Before you start: list everything that sends as your domain

Write down every service that sends email with your domain in the From address. A typical early-stage SaaS has two or three:

Sender	Example	How it authenticates
Team mailboxes	Google Workspace	MX records, an include: in the root SPF, its own DKIM key
App and marketing email	SendGrid, Postmark, SES	CNAME records the provider gives you
Support or CRM tool	Help desk, sales tool	Varies; check its docs

Every sender on this list needs DKIM for your domain. If one is missing, DMARC will fail for its emails once you enforce a policy.

Step 1: Check your root SPF record (and usually leave it alone)

Look up the TXT records on your root domain. If you use Google Workspace, you probably have something like this:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

Two rules matter here. A domain must have only one SPF record, and SPF evaluation stops after 10 DNS lookups. Breaking either rule gives a "permerror", which counts as a fail (RFC 7208, sections 3.2 and 4.6.4).

Many older guides tell you to add your ESP to this record, for example include:sendgrid.net. With modern setups you often don't need to. When we connected SendGrid with "automated security" turned on, SendGrid's SPF lived on its own subdomain (the return path, em1234.example.com in the example below). Receivers check SPF on that subdomain, not on the root. So our root SPF record for Google Workspace stayed exactly as it was. One fewer lookup, and nothing to break for the team's mailboxes.

If your provider does ask you to edit the root SPF, merge its include: into the existing record. Never add a second v=spf1 record.

Step 2: Add your provider's DKIM and return-path records

In your ESP's dashboard, find "domain authentication" (the name varies). Enter your domain and it shows the records to add. In SendGrid with automated security, you get CNAME records like these (placeholder values; copy yours exactly):

Type	Name / Host	Value
CNAME	em1234.example.com	u1234567.wl123.sendgrid.net
CNAME	s1._domainkey.example.com	s1.domainkey.u1234567.wl123.sendgrid.net
CNAME	s2._domainkey.example.com	s2.domainkey.u1234567.wl123.sendgrid.net

The em1234 record is the return path, used for SPF and bounces. The two _domainkey records point to DKIM keys that SendGrid manages. A CNAME means you never paste a long key yourself.

The GoDaddy mistake (and Route 53, Namecheap...)

This is the mistake we made. GoDaddy adds your domain to whatever you type in the Name field. If you paste the full host name em1234.example.com, GoDaddy saves em1234.example.com.example.com. The record exists, but at the wrong name, so verification fails.

Type only the part before your domain:

You want	Type in the Name field
em1234.example.com	em1234
s1._domainkey.example.com	s1._domainkey
_dmarc.example.com	_dmarc

SendGrid's own docs warn that GoDaddy, Amazon Route 53 and Namecheap append your domain in this way. Other hosts, like Cloudflare, accept either form. When in doubt, look up the record after saving (see Step 5).

Step 3: Publish a DMARC record

DMARC is one TXT record at _dmarc.yourdomain.com. If you don't have one yet, start with a policy that only monitors:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• p=none means "don't block anything, just report". Gmail and Yahoo accept it as the minimum for bulk senders.
• rua= is where receivers send daily summary reports. Without it, you get no reports.
• Later, after the reports show all your real email passing, move to p=quarantine (failures go to spam) and then p=reject.

Our domain already had a DMARC record:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; adkim=r; aspf=r"

It worked as-is. The DKIM signature was for our own domain, so DKIM was aligned. adkim=r and aspf=r mean relaxed alignment: a subdomain like em1234.example.com counts as a match for example.com. Relaxed is the default in the DMARC standard. Some guides suggest strict alignment (s). Don't copy that blindly. With aspf=s, a return path on em1234.example.com no longer aligns with example.com, so SPF stops counting for DMARC.

One more note. Older guides use pct=10 to roll out a policy gradually. The current DMARC standard, RFC 9989, removed the pct tag and added a t=y test flag instead.

Step 4: Brand your links (optional, but do it)

Most ESPs rewrite links to count clicks. By default the tracked links use the provider's domain. With link branding, they use a subdomain of yours, like url1234.example.com. SendGrid gives you two more CNAME records for this.

Turn on SSL for those links too. In SendGrid this is the "Auto provision SSL Certificate" option. Without it, your tracked links may load over plain http. We enabled it at launch so every tracked link uses our own subdomain over https.

Step 5: Verify that it works

First, check that the records exist at the right names. On macOS or Linux:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME em1234.example.com
dig +short CNAME s1._domainkey.example.com

On Windows, use nslookup -type=TXT _dmarc.example.com. An empty result usually means a typo or a doubled domain name.

Then click "Verify" in your ESP. Next, send a real email to a Gmail address you can read. Open it, click the three-dot More menu next to Reply, and choose Show original. You want to see:

SPF:   PASS with IP 203.0.113.10
DKIM:  'PASS' with domain example.com
DMARC: 'PASS'

Back in the message, click the small arrow under the sender's name. mailed-by and signed-by should both show your domain. There should be no "via sendgrid.net" next to the sender's name. Gmail shows "via" when the sending domain doesn't match the From domain, so its absence is a good sign.

Verification checklist

• Exactly one v=spf1 record on the root domain
• DKIM records resolve at selector._domainkey.yourdomain.com, not at a doubled name
• Return-path CNAME resolves
• DMARC TXT record at _dmarc.yourdomain.com with a rua address
• Gmail "Show original": SPF, DKIM and DMARC all PASS
• DKIM passes with your domain, not the provider's
• mailed-by and signed-by show your domain; no "via"
• Branded links open over https

From the LuneaMail team: Our first plan was simple: send straight from our own Gmail account. That didn't survive spam filters and the risk of misuse, so we moved to authenticated sending from our own domain through a reputable provider. Nobody thinks about SPF, DKIM and DMARC until they send an important email and the customer never receives it. Set them up before your first send, not after your first support ticket.

Common mistakes

• Two SPF records. Adding a new v=spf1 record instead of editing the existing one. Both fail.
• Full host names at GoDaddy-style hosts. You end up with em1234.example.com.example.com.
• Editing the root SPF when you don't need to. With CNAME-based setups, the ESP's SPF is on the return-path subdomain.
• DKIM for the wrong domain. "DKIM: PASS with domain sendgrid.net" is not aligned. DMARC needs your domain.
• Jumping to p=reject on day one. If a forgotten tool (a help desk, an invoicing app) sends as your domain without DKIM, its email disappears. Start with p=none, read the reports, then tighten.
• Strict alignment by copy-paste. adkim=s; aspf=s can fail mail that would pass under relaxed alignment.
• Sending from a free mailbox. A From address at gmail.com or yahoo.com sent through an ESP can't pass DMARC for that domain. Use an address on your own domain.

These records are also the base of the rules Gmail and Yahoo apply to anyone sending in volume. We cover those in Gmail and Yahoo's bulk-sender rules.

How LuneaMail handles this

If you send with LuneaMail, you don't need a separate SendGrid account. In Settings › Domains, you add your domain and LuneaMail lists the records to publish: the return path, two DKIM records and the branded-link records, each with a copy button. It also shows whether you already have a DMARC record. If you don't, it suggests a monitor-only one (v=DMARC1; p=none;). Click Check DNS, and the domain is verified once the required records pass. Branded links are optional and don't block sending.

Until your domain is verified, campaigns go out from LuneaMail's own sender address, with your address as Reply-To, so they still pass DMARC. Every send also gets a spam and delivery check that looks at your domain's SPF and DMARC. See the full list on the features page. If you send app email like receipts or license keys, the same domain covers your transactional email through the API.