Email authentication has a reputation for being an enterprise-security-team problem: the kind of thing with a dedicated vendor, a procurement process, and a five-figure annual contract. If you're a solo developer or a small team shipping a product, none of that applies to you, and none of it needs to. Here's a complete DMARC setup you can run for free, with one optional step that costs a dollar a month.
Step 1: SPF and DKIM for whatever you're actually sending from (free)
Before DMARC can do its job, the mail you send needs to authenticate cleanly. If you're sending transactional email through a provider (Postmark, SES, Resend, SendGrid, pick whichever), they'll give you the exact SPF include and DKIM CNAME records to add. This step is free regardless of which provider you use; it's just DNS records, and every provider's onboarding walks you through it.
If you're also sending from Google Workspace or a similar business email tool, make sure that's included in the same SPF record: you can only have one SPF TXT record per domain, so multiple include: mechanisms need to live together in it, not in separate records (a second v=spf1 record is invalid and will break the whole thing).
Watch the lookup count while you do this. SPF allows a maximum of 10 DNS lookups per check. Each include: can add multiple lookups once it's expanded, so combining several providers can reach that limit faster than you'd expect. Stack a transactional provider, Google Workspace, and a marketing tool like Mailchimp, and you can reach that limit surprisingly quickly. Go over, and SPF doesn't fail loudly: it returns a permerror, which most receivers treat as an outright fail, so mail that should authenticate cleanly starts landing in spam with no obvious error to point at. If you're stacking more than two or three providers, run the record through MyDMARC's free SPF checker, which resolves every nested include and gives you the actual lookup count before it becomes a problem.
Step 2: A DMARC record at p=none (free)
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
This is one DNS record. It costs nothing and it's the only step required to start seeing who's sending mail as your domain. Point rua= at an address you'll actually monitor. If you're using MyDMARC, you can point it directly at your MyDMARC reporting address from day one, more on that next.
Step 3: A way to actually read the reports (free tier available)
This is the step people skip, and it's the one that makes everything before it useful. Most DMARC reports arrive as gzipped XML: readable, but not something you'll keep up with by hand for more than a week. MyDMARC has a free tier built for exactly this scale: point your rua= reporting address at it and it parses every report into a dashboard showing your sending sources and pass/fail trends, no manual XML wrangling required. It's capped at one domain and a 7-day rolling window of history: enough to identify every sender in the first couple of weeks, which is the actual job at this stage. (Longer retention and the policy-readiness view that tells you when it's safe to tighten enforcement come with the paid plans.) For an indie project or small team, that's usually all you need to get through the identification step without a budget line item.
Step 4: Move to p=quarantine once everything legitimate is passing (free)
Once you've watched reports for a couple of weeks and every sending source you recognize is passing, tighten the record:
_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"
Still free: it's the same TXT record, just a different value. This is also the point where a spoofed "from [email protected]" phishing attempt targeting your users is much more likely to be routed to spam instead of landing in their inbox.
Step 5: DNS change monitoring, if you want it (one dollar a month)
This is the only step on this list that isn't free, and it's optional, but it's worth the dollar. DNS records don't announce when they change. If a registrar migration, a typo, or a compromised account silently drops or alters your DMARC, SPF, or DKIM record, you won't find out from an error message; you'll find out weeks later when someone mentions your emails are going to spam, or worse, you won't find out at all. OneDollarDNS watches your DNS records and alerts you the moment one changes, for a dollar per domain per month, cheap enough that skipping it isn't really about the money.
The whole stack
- SPF + DKIM: free, from your existing email provider.
- DMARC record: free, one DNS TXT entry.
- Report monitoring: free, on MyDMARC's free tier (1 domain, 7-day report history).
- Change alerting: $1/month, on OneDollarDNS.
When you'll outgrow the free tier
The free tier is genuinely enough to get through everything above, but it has real limits, and it's worth knowing what they are before you hit them:
- A second domain. Free covers one. If you're running a product and a marketing site on separate domains, or you pick up a second project, you'll need Basic (5 domains) or Pro (20 domains).
- More than 7 days of history. A 7-day window is fine for spotting who's sending mail in the first couple of weeks, but it's tight for confidently watching a
pctrollout over several weeks. Basic extends that to 30 days, Pro to 90. - A teammate. Once someone else needs to check in on reports or DNS status, both paid plans add team member access, the free tier doesn't.
None of this needs to happen on day one. The whole point of starting free is not paying for headroom you don’t need yet, but if you cross one of these lines, upgrading is a plan change, not a new tool to learn.
Getting all of this in place doesn’t require a security team, a vendor call, or a budget approval. It requires about an hour of DNS work, spread over a few weeks as the reports come in.