Rich Gibbs

SPF, DKIM, DMARC for indie founders: the 20-minute checklist

email · dns · spf · dkim · dmarc · deliverability · indie-founder · saas

You shipped a product. Stripe sends receipts. Postmark sends magic links. Mailchimp blasts your launch list. You replied to a support ticket from your own founder address.

Then someone said “hey, your password reset went to spam.”

This guide is for that moment.

It is not a deliverability bible. It is the smallest correct version of the SPF / DKIM / DMARC story for a solo founder or a 2-3 person SaaS team, with one custom domain and two-to-five tools that send email on its behalf. If you can edit DNS and copy a record, you can finish it tonight.

We are also not selling you a deliverability platform. The point of this post is for you to do it yourself, correctly, in one sitting.

What “set up email DNS” actually means in 2026

Mailbox providers — Gmail, Yahoo, Outlook, Apple, ProtonMail — use three DNS-anchored signals to decide whether a message is plausibly from your domain at all:

  • SPF says “these IP addresses / hostnames are allowed to send mail using my domain in the envelope sender.”
  • DKIM says “messages from my domain will carry a cryptographic signature in the headers, signed by a key whose public half lives in DNS.”
  • DMARC says “if SPF and DKIM both fail to align with my visible From: domain, here is what you should do — nothing, quarantine to spam, or reject — and please send me reports.”

In 2024–2025 Gmail and Yahoo started requiring all three from any sender shipping more than 5,000 messages a day to their users, and they have been quietly tightening the rules for low-volume senders ever since. In practice, by 2026:

  • If your domain has no SPF and no DKIM, password resets and receipts will sometimes silently disappear into spam.
  • If your domain has no DMARC at all, anyone can spoof “from your domain” until enough recipients complain.
  • If your DMARC record is malformed, mailbox providers behave the same as if it isn’t there — except now your reports vanish too.

You do not need to be perfect. You need to be not broken.

The 20-minute checklist

Before you touch DNS, do the boring inventory step. This is the part most founders skip and most spam problems come from.

1. List every tool that sends mail “from” your domain (3 minutes)

Open a notes file. Write the domain you want to fix at the top. Then list every place that sends email as that domain. Real examples for a typical indie SaaS:

  • Founder mail (you replying from you@yourdomain.com) — Google Workspace or Fastmail.
  • Transactional / product mail — Postmark, Resend, Mailgun, AWS SES, SendGrid, Mailtrap.
  • Marketing / newsletter — ConvertKit, Mailchimp, Beehiiv, Buttondown, Substack custom domain.
  • Helpdesk — Help Scout, Front, HubSpot, Zendesk, Plain.
  • App-platform notifications — Vercel/Render/Heroku notifications using your domain, GitHub on a custom domain.
  • Stripe receipts and Tally form notifications, when configured to “send from” your domain rather than the platform default.

If you cannot remember, search your inbox for from:@yourdomain.com and note every “tool integration” message you find from the last 90 days.

This list is the single most useful artifact in this entire process. If anyone ever asks you “do you know who sends as your domain?”, you can answer in one screen.

2. Pick exactly one SPF record (5 minutes)

SPF is one TXT record at the apex of your domain (yourdomain.com, not mail.yourdomain.com). You are allowed exactly one. If there are two SPF TXT records in DNS, every conforming mailbox server treats the result as permerror and ignores both.

A working SPF for the example list above might be:

v=spf1 include:_spf.google.com include:spf.mtasv.net include:_spf.mailgun.org include:_spf.constantcontact.com -all

Rules:

  • Start with v=spf1.
  • One include: per provider, taken from each provider’s docs. Do not invent them.
  • End with -all (hard fail) or ~all (soft fail). Use ~all while you are setting up DMARC, then move to -all once DMARC reports are clean.
  • Do not put +all anywhere. Ever. That tells the world anyone can send as you.
  • Do not exceed 10 DNS lookups across all the include: and redirect= directives combined. Tools like Google Workspace + Mailgun + Mailchimp + Constant Contact + Help Scout will quietly exceed 10. If you see permerror reports, this is usually why.

If you use mail.yourdomain.com as a separate sending subdomain (some providers configure it that way), publish a separate SPF record at that subdomain.

3. Add DKIM for each sending tool (5 minutes)

DKIM is per-provider. Every provider that sends mail for you should give you one or more selector._domainkey.yourdomain.com CNAME or TXT records to add.

Examples of selectors you’ll see in a real indie SaaS:

  • Google Workspace: google._domainkey
  • Postmark: <assigned>._domainkey (Postmark assigns the selector when you verify the domain)
  • Mailgun: mailo._domainkey and pic._domainkey
  • ConvertKit / Mailchimp: their dashboard prints the exact CNAMEs.
  • Resend: resend._domainkey

Two rules that catch people:

  • DKIM records do not show up in plain dig TXT yourdomain.com. You have to query the selector explicitly: dig TXT selector._domainkey.yourdomain.com. If you cannot remember selectors, you cannot validate your own DKIM from public DNS — write them down.
  • “DKIM is set up” is not the same as “messages are being signed.” Each provider has its own toggle for “sign outbound mail with this key.” If signing is off in the provider dashboard, the selector record alone is useless.

The Authentication-Results header in any actual sent email is the source of truth. If it says dkim=pass from your visible domain, signing is real.

4. Publish a cautious DMARC (3 minutes)

DMARC is one TXT record at _dmarc.yourdomain.com. Start safe:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100

Translation:

  • p=none — do not block anything yet, just ask for reports.
  • rua=mailto: — a real mailbox you actually read; not a personal Gmail you ignore. Many founders use a forwarding alias like dmarc-reports@yourdomain.com that lands in a labeled folder.
  • adkim=r; aspf=r — relaxed alignment. Strict alignment is for later.

A 14-day p=none window before you tighten anything is the difference between “I learned my newsletter platform sends as mail.mydomain.com” and “I broke my newsletter for two days.”

After 14 days of clean reports — meaning every legitimate sender shows up in the reports as passing SPF or DKIM aligned with yourdomain.com — move to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=25

The pct=25 ramp is intentional. It means “quarantine 25 % of messages that fail alignment” so you can detect any forgotten sender before going full p=quarantine or p=reject.

If you are an indie founder, you may stop at p=quarantine forever. p=reject is for senders who are confident no legitimate mail anywhere uses their domain incorrectly.

5. Verify the result with one real email (4 minutes)

Send one email to yourself at Gmail, Yahoo, and Outlook from each sending tool you care about most (founder mail, password reset, newsletter). Open the message header.

You are looking for an Authentication-Results line that says all three of:

  • spf=pass with smtp.mailfrom= matching a domain that contains yourdomain.com.
  • dkim=pass with header.d=yourdomain.com (alignment) — not header.d=postmarkapp.com or header.d=mailgun.org.
  • dmarc=pass.

dkim=pass header.d=mailgun.org while your visible From: is support@yourdomain.com is the most common deliverability bug among indie founders. The message is technically signed, but DMARC-wise it is unsigned by your domain. Fix it by completing the provider’s “Use my own domain” / “Custom domain DKIM” configuration. Postmark, Mailgun, Resend, SendGrid, Mailchimp, ConvertKit, and AWS SES all support this; they just don’t enable it by default.

Things to deliberately ignore in v1

You do not need:

  • BIMI. Useful only after DMARC is at p=quarantine or stricter for a long time, and even then it is a logo-display feature, not a deliverability feature.
  • ARC. Mailing-list specific.
  • DKIM key rotation. Whatever your provider gave you is fine until they tell you to rotate.
  • Per-subdomain DMARC strictness (sp=). Default is fine until you operate dedicated sending subdomains.

You also do not need:

  • A paid “deliverability platform” subscription.
  • A reputation-monitoring agency.
  • An IP warmup schedule (you are using shared IPs from your ESP; they handle warmup).

Common gotchas an indie founder will hit

These are the failure modes I see most often when reviewing single-domain setups:

  • Two SPF records. Often a leftover from when you were trying providers. Merge into one.
  • +all left over from a Google guide that said “for testing only.” Remove.
  • DMARC rua pointing at you@yourdomain.com itself. Your inbox will fill with unreadable XML aggregate reports. Use a sub-alias (dmarc-reports@) that auto-files.
  • DKIM “set up” but provider has signing disabled. Toggle it on in the provider, and confirm with a real test message header.
  • Marketing tool added later, but DKIM never aligned. New newsletter platform turns SPF green, leaves DKIM header.d= pointing at the platform’s domain. DMARC fails alignment for that one tool.
  • Personal Gmail “Send mail as” alias used to reply from you@yourdomain.com. Even if Workspace is fine, that alias often sends as gmail.com underneath. Reply-To is fine; the sending identity matters for alignment.
  • Subdomain forgotten. Stripe receipts sometimes go through mail.yourdomain.com. If subdomain SPF/DKIM is missing, mailbox providers can still apply the apex DMARC. Check at the exact subdomain.

If any of those sound like a problem you cannot debug from your provider’s dashboard alone, that is the moment a second pair of eyes is worth more than another deliverability article.

Next step: a $99 second pair of eyes

Once you’ve done the 20-minute pass above, the question is usually not “is the record there?” It’s “are all these records aligned with the way I actually send mail?” That answer lives partly in DNS and partly in a few real message headers.

If you’d like a written, prioritized fix list for one domain — SPF, DKIM, DMARC, MX, sender-tool inventory, and the obvious mistakes — that is exactly the Inbox/DNS QuickCheck we offer. $99, one domain, no DNS login needed, 24-hour turnaround. No managed retainers, no inbox-placement guarantees, no spam help.

If you’d rather DIY but want the printable, fillable Markdown version of the entire process — sender inventory template, SPF builder, DKIM provider reference, DMARC ramp, Authentication-Results decoder — that’s the Indie Founder Email DNS Pack, $19 (pay what you want, $9 minimum) on Gumroad.

That is also the point at which most founders realize there was one tool nobody remembered to align. That tool is almost always a marketing platform.

You don’t have to buy anything to follow the checklist above. The above is the whole working answer for most one-domain indie SaaS. The QuickCheck exists for when you’ve done the obvious and still have a quiet 5–10 % of legitimate mail disappearing into spam, and you want a second set of eyes before you tighten DMARC further.

Either way, the goal is the same: your password resets, your receipts, and your founder replies should reach the inbox. The boring DNS hygiene above is most of the answer.

If you’ve already finished the checklist above and tightened DMARC to p=quarantine, and now a specific sender — newsletter tool, Stripe receipts, a sub-domain — has started being quarantined or hard-bounced (Gmail 5.7.26, Microsoft 5.7.509 / 5.7.515), the DMARC Quarantine Pack is the focused diagnostic runbook for that exact moment. It includes a DSN decoder cheat-sheet, three real-world incident walkthroughs (marketing-tool DKIM drift, forgotten sub-domain, forwarding/ARC breakage), and a single-file Python aggregate-XML reader so you can read your own DMARC reports without paying for a SaaS dashboard.

DMARC Quarantine Pack — $29 on Gumroad · 14-day refund, no questions.