DMARC for indie developers: what to monitor and when to act

The hard part of DMARC isn't the DNS record: it's knowing what to watch afterward. You need to monitor alignment, because misalignment is what tanks your deliverability. Here's what that actually means and why it matters.

What DMARC actually does

DMARC builds on two older email authentication standards: SPF and DKIM. SPF says which IP addresses are allowed to send mail from your domain. DKIM cryptographically signs outgoing messages so receivers can verify they weren't tampered with.

DMARC adds two things. First, it introduces the concept of alignment: your SPF and DKIM results only "count" toward DMARC if the authenticated domain matches your From address domain. This prevents a common bypass where a spammer uses your domain in the From header but authenticates using their own domain.

Second, DMARC lets you publish a policy (p=none, p=quarantine, or p=reject) that tells receivers what to do with messages that fail your checks. And it provides the rua= address for aggregate reports so you can see what's actually happening.

The three policy levels

p=none means monitor only. Messages that fail DMARC are still delivered. Reports still arrive at your rua= address. This is where most people start, and where many indie developers stay forever.

p=quarantine means messages failing DMARC should go to spam. This is the first policy with real teeth. You should only move here once your aggregate reports show 95%+ alignment across all your legitimate sending sources.

p=reject means refuse delivery entirely. This is the end state that provides meaningful spoofing protection. You need very high confidence in your sending sources before enabling it.

The path from none to reject typically takes a few months of monitoring to complete safely. Moving too fast breaks legitimate email.

What you need to configure

For each domain you send from, you need:

1. SPF: a TXT record at the root of your domain listing your authorized sending IPs and services. Most ESPs give you the include: mechanism to add. Keep SPF records under the 10-lookup limit.

2. DKIM: your ESP generates a keypair, you add the public key as a TXT record at a subdomain like selector._domainkey.yourdomain.com. Most modern ESPs require this and will walk you through setup.

3. DMARC: a TXT record at _dmarc.yourdomain.com. Minimum viable: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. Replace the rua= with wherever you want reports delivered. Use the DMARC record checker to verify the record resolves correctly. The SPF, DKIM, and DMARC checker checks all three layers in one pass and flags misconfigurations that would cause DMARC to fail.

If you use multiple sending services (transactional email via Postmark or Resend, marketing via Mailchimp, plus Google Workspace for your own email), each service needs its own DKIM configuration and should appear in your SPF record.

The part everyone skips (and then regrets)

The rua= address receives reports. Most developers add a real email address, watch 50 gzipped XML files arrive in the first week, open zero of them, and never think about it again.

But this is where silent failures hide. While you're not reading reports, alignment can be dropping. A new ESP isn't configured right. SPF record limits got hit. Someone's spoofing your domain, or your sending IP ended up on a blocklist from a previous tenant. You won't know any of this happened until deliverability breaks and your customers tell you their messages aren't arriving.

The practical answer is to use a monitoring tool that ingests the reports, parses the XML, and tells you your alignment rate and unexpected senders in plain language. For a walkthrough of what's actually inside one, see what's in a DMARC aggregate report. The DMARC report analyzer lets you upload a report manually to see what it says. For ongoing monitoring across every report your domain receives, DMARCdrift ingests them automatically and alerts you when alignment drops or an unrecognized sender appears.

Either way, the reports are useless if you don't read them, and the XML format ensures that almost nobody does.

If you're serious about protecting your email deliverability (your side projects do send email to real users), you need ongoing alignment monitoring. Not "maybe I'll set this up someday." Today. It takes five minutes and it catches the problems that would otherwise blindside you.

Not sure which monitoring tool fits? See the DMARC monitoring tool comparison.