SPF, DKIM, and DMARC for SaaS founders, in plain English

Setting up SPF, DKIM, and DMARC is the one piece of email infrastructure every SaaS founder eventually has to touch, and almost nobody enjoys it. The guides that rank for it are written for full-time email administrators managing dozens of domains. This one is for a founder with 30 minutes, one domain, and a product to ship. By the end you will know what each record does in a single sentence, the exact DNS entries to add, the order in which to turn on enforcement, and the handful of mistakes that break authentication with no error message to warn you.

The one-sentence version of each.

Before the DNS syntax, get the mental model straight. Email authentication is three separate mechanisms that answer three different questions about a message claiming to be from you. SPF and DKIM each try to prove the message is legitimate. DMARC decides what happens based on those proofs and reports back to you. If you remember nothing else, remember the plain-English line for each.

This guide goes deep on authentication specifically. It is the companion to our broader guide on email deliverability for SaaS, which covers sender reputation, list hygiene, and why behavior triggered sending protects your inbox placement. If you want the full picture, read both. If you just need the DNS done right, stay here.

SPF: which servers may send for your domain.

SPF is a single DNS TXT record that lists every service authorized to send mail for your domain. When a receiving server gets a message claiming to be from yourapp.com, it looks up your SPF record and checks whether the connecting server appears in the list. If it does, SPF passes. If it does not, SPF fails, and what happens next is decided by DMARC.

The record itself is short. A domain sending through AWS SES looks like this: v=spf1 include:amazonses.com ~all. The include: mechanism pulls in the range of servers that SES publishes, so you never have to list individual IP addresses. The ~all at the end is a soft fail, meaning mail from servers not in the list should be treated as suspicious rather than rejected outright. Use ~all while you are getting set up; once DMARC is at enforcement, the difference between soft fail and hard fail (-all) matters less because DMARC is doing the rejecting.

The critical rule with SPF is that you get exactly one record. If you send through more than one service, you merge them into a single record, for example v=spf1 include:amazonses.com include:_spf.google.com ~all for a domain that sends product email through SES and uses Google Workspace for the team's own mail. Two separate SPF records is not additive; it is an error that breaks SPF for both.

DKIM: a signature that proves the message was not altered.

DKIM is stronger than SPF because it does not care which server relayed the message; it cares whether the message is intact and genuinely from you. Your ESP generates a public and private key pair. The private key signs the headers and body of every message you send. The public key lives in a DNS record at a selector, a subdomain like resend._domainkey.yourapp.com. A receiving server fetches that public key, verifies the signature, and confirms the message has not been tampered with in transit.

There are two ways ESPs hand you the DKIM record, and it helps to know which you are dealing with. Some give you a raw TXT record containing the public key, which starts v=DKIM1; k=rsa; p= followed by a long base64 string. Others, AWS SES in particular, use CNAME records: they give you three CNAMEs at selector hosts that point back to keys SES hosts on its own side, which means SES can rotate the keys for you without you touching DNS again. Either way, a 2048-bit key is the current standard, and DKIM is the check that survives forwarding, where SPF frequently breaks.

DMARC: what to do when the first two fail.

DMARC is the decision-maker. It is a TXT record at _dmarc.yourapp.com that does two jobs. First, it tells receiving servers what to do with mail that fails both SPF and DKIM: p=none (do nothing, just watch), p=quarantine (send it to spam), or p=reject (refuse it). Second, through the rua tag, it asks receivers to send you aggregate reports listing every source that sent mail as your domain and whether each one passed. A minimal starting record looks like v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com; adkim=r; aspf=r.

One subtlety worth understanding is alignment. DMARC does not just check that SPF or DKIM passed; it checks that the domain they passed for matches the domain in your visible From address. The adkim and aspf tags control how strict that match must be, and relaxed (r, the default) is what you want so that sends from a subdomain still align with a root-domain From address. If a legitimate service is passing SPF or DKIM but still failing DMARC, misaligned From domains are almost always the reason.

Here is what those three records look like side by side for a domain called yourapp.com. Your ESP will give you the real values; these show the shape of each entry so you recognize them in your DNS dashboard.

The p=none, p=quarantine, p=reject progression.

The biggest mistake founders make with DMARC is publishing p=none and calling it done. A policy of none protects nobody. It does not stop anyone from spoofing your domain; it only watches and reports. It exists so you can safely observe before you enforce. The whole point of DMARC is to reach enforcement, and getting there is a deliberate three-step progression.

Start at p=none for two to four weeks. Read the aggregate reports (there are free and paid services that turn the raw XML into something readable) and make a list of every source sending as your domain. You are looking for the surprises: a support desk, an invoicing tool, a form service, an old ESP you forgot about. For each legitimate one, confirm SPF or DKIM aligns. Once every source you recognize is passing, you are ready to enforce.

Move to p=quarantine next. A useful trick here is the pct tag: p=quarantine; pct=25 applies the policy to only 25 percent of failing mail, so you can watch for collateral damage before ramping to 100 percent. When quarantine is clean, move to p=reject. At reject, spoofed mail claiming to be from your domain is refused at the door, which is the actual protection you set all of this up to get. A typical, careful SaaS reaches p=reject four to eight weeks after starting, depending on how many stray sending sources turn up in the reports.

What Google and Yahoo now require.

Since February 2024, Google and Yahoo have made email authentication a hard requirement rather than a best practice for anyone sending in volume. If you send roughly 5,000 or more messages a day to their users, you must have SPF and DKIM both passing, a DMARC record on your domain (a policy of p=none satisfies the minimum), a working one-click unsubscribe in bulk mail, and a spam complaint rate kept below 0.30 percent. Fall short and your mail is throttled or rejected outright, not filtered politely into spam.

The important shift for founders is that the old either-or advice is dead. For years the guidance was that SPF or DKIM was enough; now the large mailbox providers want both, aligned under DMARC. Even if you are nowhere near 5,000 messages a day, treat full authentication as the baseline. The threshold is where enforcement becomes automatic, not where it starts to matter, and you do not want to be reconfiguring DNS in a panic the week a launch pushes you over the line.

One domain, two reputations: the subdomain strategy.

Once authentication is working, the next decision is how to structure your sending so that one type of email cannot damage another. The standard approach is subdomains. Send transactional mail, your password resets and receipts, from one subdomain, and send marketing and lifecycle campaigns from a different one. A common layout is notify.yourapp.com for transactional and news.yourapp.com for marketing, with the root domain kept out of bulk sending entirely so its reputation stays pristine.

The reason this works is that mailbox providers track reputation at the subdomain level. If a marketing campaign draws spam complaints, the damage is contained to the marketing subdomain, and your password resets keep landing in the inbox from the transactional subdomain. Your most important mail, the messages a locked-out user is desperate to receive, is insulated from the messier reputation of promotional sending.

The catch is that each sending subdomain needs its own SPF and DKIM records. SPF and DKIM do not flow down from the root. DMARC does flow down: a subdomain inherits the organizational domain's DMARC policy unless you override it with the sp (subdomain policy) tag. That inheritance is exactly why the next section matters, because it is the source of one of the nastier footguns.

Four footguns that break authentication silently.

Authentication rarely fails with a helpful error. It fails quietly, and you find out when your open rates sag or a customer says they never got the reset email. These are the four traps that catch SaaS teams most often, all of which are easy to avoid once you know they exist.

01. Two SPF records instead of one.

A domain may have exactly one SPF TXT record. Publish a second (usually left over from a previous provider) and receivers see the conflict and return a permanent error, which fails SPF for all of your mail. When you add a sending service, merge its include: into your existing record. Never add a fresh SPF record alongside the old one.

02. Blowing past the 10-lookup limit.

SPF is capped at 10 DNS lookups when it is being evaluated, and every include: counts against that budget, sometimes several times over because includes can nest. Stack up enough services, your marketing tool, your CRM, your help desk, your ESP, and you quietly cross 10 lookups, at which point SPF returns a permerror and fails. The fix is SPF flattening or consolidating services; the first step is simply knowing the limit exists, because nothing in your DNS dashboard will warn you.

03. Forgetting DKIM on the marketing subdomain.

When you split marketing onto news.yourapp.com, it is easy to set up SPF for the subdomain and forget DKIM, or to assume the root domain's records apply. They do not. If the root domain is at p=reject and the subdomain inherits that policy but has no aligned DKIM, every marketing send fails DMARC and gets rejected. Set up SPF and DKIM on any subdomain before you send a single message from it, or set a temporary sp=none while you get it right.

04. Leaving DMARC at p=none forever.

The most common footgun is the one that feels safest: publishing p=none and never moving off it. Monitoring mode gives you the reports without the protection, so anyone can still spoof your domain. Set a calendar reminder when you publish p=none to revisit it in three weeks and start the climb to enforcement. A DMARC record stuck at none is a job half done.

SPF, DKIM, and DMARC, answered.

What is the difference between SPF, DKIM, and DMARC?

SPF names which servers are allowed to send email for your domain. DKIM attaches a cryptographic signature that proves a message was not altered on its way to the inbox and that it came from your domain. DMARC ties the two together: it tells a receiving server what to do when a message fails both checks (nothing, send to spam, or reject) and where to send reports about what is passing and failing. You need all three. SPF and DKIM do the proving; DMARC does the deciding and the reporting.

Do I need all three, or is one enough?

You need all three. As of February 2024, Google and Yahoo require both SPF and DKIM to pass, plus a DMARC record, for anyone sending in volume to their users. The old advice that either SPF or DKIM was sufficient is out of date. Even below the bulk threshold, mailbox providers increasingly treat full authentication as the baseline for reaching the primary inbox, so there is no real case for setting up only one of them anymore.

What DMARC policy should a SaaS start with?

Start with p=none. That is monitor-only mode: it changes nothing about how your mail is handled, but it turns on the aggregate reports that show you every source sending mail as your domain. Leave it there for two to four weeks until you have confirmed that all of your legitimate sending (your ESP, your own servers, any third party sending on your behalf) passes SPF or DKIM alignment. Then move to p=quarantine, and once that is clean, to p=reject. Do not stop at p=none: it protects nobody, it only watches.

Can I have more than one SPF record on a domain?

No. A domain may have exactly one SPF TXT record. If you publish two (for example, one from a previous provider and one from your current ESP), receiving servers see the conflict and return a permerror, and your SPF effectively fails for everyone. When you add a new sending service, you merge its include mechanism into your single existing SPF record rather than adding a second record. This is one of the most common ways authentication breaks silently.

How do I authenticate a subdomain I send marketing from?

A subdomain like news.yourapp.com needs its own SPF and DKIM records; it does not inherit them from the root domain. DMARC is different: a subdomain inherits the organizational domain's DMARC policy unless you set a separate subdomain policy with the sp tag. The practical consequence is that if you set p=reject on yourapp.com and then start sending marketing from news.yourapp.com without publishing SPF and DKIM for that subdomain, those sends fail DMARC and get rejected. Set up authentication on the subdomain before you send from it.

Authentication is a one-time setup with a long payoff. Add the three records, watch the DMARC reports until you trust them, climb to p=reject, and split your sending across subdomains so one mistake cannot sink everything. GetFluxly does not send your mail: it connects to the provider you choose, whether that is Resend, Postmark, AWS SES, Mailgun, or any custom SMTP relay, so the sending reputation you build with these records stays entirely yours. Our job is the triggering, the customer profile, and the analytics that tell you whether the email actually worked.