← All guides

Avoid Blocking Mail: Staged DMARC, SPF, and DKIM for Email Teams

Step by step SPF, DKIM, and DMARC setup for email teams. Safe staged DMARC rollout, quick troubleshooting, and an optional managed path.

By LeadPilot
Avoid Blocking Mail: Staged DMARC, SPF, and DKIM for Email Teams

Avoid Blocking Mail: Staged DMARC, SPF, and DKIM for Email Teams

Engineer reviewing email authentication settings

SPF authorizes which servers can send mail for your domain, DKIM cryptographically signs each message, and DMARC enforces alignment between them while telling receiving servers what to do with mail that fails. Together they stop the two most common spoofing tricks: a stranger’s server pretending to be your domain, and a tampered message riding on your reputation. None of the three guarantees inbox placement on its own.

TL;DR:

  • Ensuring all legitimate third-party senders are included in SPF is critical, as exceeding DNS lookup limits causes validation failures even for authorized emails.
  • Proper DKIM setup requires assigning unique selectors per service, rotating keys periodically, and ensuring signatures cover essential headers to prevent forgery.
  • Achieving DMARC alignment with relaxed settings balances security and deliverability, but strict alignment may cause more legitimate emails to fail.
  • Starting with a DMARC policy of p=none and monitoring reports for two to four weeks reduces the risk of blocking valid emails during enforcement transition.
  • Forwarding frequently breaks SPF validation, but pairing DKIM with Sender Rewriting Scheme can mitigate forwarding issues more effectively.

Table of Contents

What SPF, DKIM, and DMARC actually check

SPF (Sender Policy Framework) checks whether the server that sent a message is authorized to use your domain in the envelope sender, the address hidden behind the visible “From” field. It lives as a TXT record at your root domain.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, generated with a private key. The matching public key sits in a DNS TXT record at a subdomain tied to a “selector,” so receivers can verify the message wasn’t altered in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) checks whether SPF or DKIM aligns with the domain shown in the visible From header, then applies a policy and sends aggregate reports back to you. All three live as DNS TXT records, and Cloudflare’s overview is a good reference for exactly where each one sits.

  • SPF: authorizes sending IPs against the envelope sender
  • DKIM: signs the message with a private key, verified via a public key at a selector subdomain
  • DMARC: aligns SPF/DKIM results with the visible From domain and reports back to you

How SPF works: envelope sender, syntax, and limits

SPF validates the SMTP MAIL FROM address against a list you publish in a v=spf1 TXT record. A typical record looks like v=spf1 ip4:203.0.113.5 include:_spf.google.com ~all.

  • ip4 / ip6: authorize specific IP addresses
  • include: pulls in another domain’s authorized senders (common with ESPs)
  • mx / a: authorize servers listed in your MX or A records
  • ~all (soft fail) vs -all (hard fail): soft fail flags unauthorized senders as suspicious; hard fail tells receivers to reject them outright

Pro Tip: Start with ~all while you’re still discovering every sending source. Move to -all only after weeks of clean SPF passes.

SPF has a hard ceiling of 10 DNS lookups per check, and every include counts against it. Exceed that and SPF fails validation entirely, even for legitimate senders. Its biggest structural flaw is forwarding: when a message gets forwarded, the envelope sender often changes, breaking SPF completely regardless of your record’s accuracy.

How DKIM works: signing, selectors, and key rotation

DKIM signs specified headers and the message body using a private key held by your sending service. The public key lives at selector._domainkey.yourdomain.com, where “selector” is an arbitrary string your provider assigns (often something like s1 or google).

  • Each sending service gets its own selector, so you can run Google Workspace, an ESP, and a cold outreach tool simultaneously without collisions
  • Rotate keys periodically by publishing a new selector’s public key before retiring the old one, avoiding a gap where signatures can’t validate
  • Signing more headers (Subject, Date, To) makes forgery harder but also makes the signature more fragile if a forwarder rewrites those fields

Pro Tip: Keep two active selectors during rotation, one live and one staged. Cut over only after confirming the new key validates cleanly in test sends.

DKIM tends to survive forwarding better than SPF because the signature travels with the message itself rather than depending on the sending IP, provided the forwarder doesn’t alter signed content.

How DMARC works: alignment, policy tags, and reporting

DMARC only returns a pass if either SPF or DKIM produces an aligned result. Alignment means the domain in the SPF or DKIM check matches the domain in the visible From header, at least loosely.

  • Relaxed alignment (aspf=r, adkim=r, the defaults) allows subdomain matches, so mail.yourdomain.com aligns with yourdomain.com
  • Strict alignment (aspf=s, adkim=s) requires an exact domain match, which is safer but breaks more easily with third-party senders
  • Policy progresses through three stages: p=none (monitor only), p=quarantine (send failures to spam), p=reject (block them outright)

A working DMARC TXT record at _dmarc.yourdomain.com might read: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; pct=100. The rua tag is what sends you aggregate reports, and without it you’re flying blind on what’s actually passing or failing. RFC 9989 spells out exactly how alignment modes interact with the underlying SPF and DKIM results.

Why you need all three, not just one

A DMARC pass requires at least one aligned pass underneath it, either SPF or DKIM, so DMARC is genuinely dependent on the other two working correctly. Consider three real scenarios: a message forwarded through a mailing list (SPF breaks, DKIM often survives), a third-party marketing tool sending on your behalf (needs its own SPF include and DKIM selector), or a shared MAIL FROM across multiple departments (risks SPF lookup limits and alignment confusion).

Major mailbox providers now require all three for anyone sending in volume. Google and Yahoo’s bulk sender rules mandate SPF, DKIM, and DMARC for senders exceeding roughly 5,000 emails a day, with no exceptions for good intentions or clean lists.

  • Confirm SPF includes every third-party sender you actually use
  • Confirm DKIM is enabled and signing on each platform, not just your primary mailbox
  • Confirm your DMARC record has a working rua address you actually monitor
  • Remember authentication is the entry fee. Sender reputation built on complaint rates and engagement still decides whether you land in the inbox or the spam folder.

Where these records live and how to check them

SPF sits as a TXT record at your root domain (yourdomain.com). DKIM sits at selector._domainkey.yourdomain.com, where the selector varies by provider. DMARC sits at _dmarc.yourdomain.com.

  1. Run dig TXT yourdomain.com to confirm your SPF record is published and syntactically valid.
  2. Run dig TXT selector._domainkey.yourdomain.com, replacing “selector” with the string your provider gave you, to check the DKIM public key.
  3. Run dig TXT _dmarc.yourdomain.com to verify your DMARC policy and reporting address.
  4. In Gmail, open “Show original” on a received message and check the Authentication-Results header for spf=pass, dkim=pass, and dmarc=pass.
  5. Use an online checker or your provider’s Postmaster Tools to cross-verify before you tighten any policy. Linuxize’s walkthrough includes sample dig output worth comparing against your own.

Setting up SPF, DKIM, and DMARC in the right order

Publishing these records out of order is how people end up locking out legitimate mail. Follow this sequence:

  1. Inventory every sending source first. List your mailbox provider, ESP, CRM, help desk tool, and any cold outreach platform that sends as your domain.
  2. Publish SPF with ~all. Include every service from your inventory using include: mechanisms, and stay soft fail until you’re confident the list is complete.
  3. Enable DKIM per service. Most providers generate the key pair and give you a CNAME or TXT record to publish; do this for each sending source individually.
  4. Publish DMARC at p=none with rua set. Let it run for two to four weeks, per Microsoft’s guidance on staged rollout, while you collect reports.
  5. Move to p=quarantine, then p=reject. Only tighten once your aggregate reports show consistent, clean passes across every legitimate sender you found in step one.

Pro Tip: Set a calendar reminder to review your DMARC reports weekly during the monitoring phase. Skipping a week is how a legitimate sender gets silently blocked when you flip to enforcement.

Common pitfalls and how to fix them fast

Forwarding is the single most frequent cause of authentication failure, since it strips or rewrites the envelope sender that SPF depends on. Linuxize notes that DKIM signing, paired with Sender Rewriting Scheme where available, mitigates this better than SPF alone ever can.

  • SPF failing unexpectedly: check for exceeded lookup limits or a forgotten third-party include
  • DKIM failing: look for selector typos, an expired key, or a DNS TXT record truncated below its required length
  • DMARC failing despite passing SPF or DKIM: check alignment, not just pass/fail, since a non-aligned pass still produces a DMARC failure
  • If reports show a legitimate sender failing, add it to SPF and enable DKIM there before tightening your policy further

Running a safe, staged DMARC rollout

Starting at p=none isn’t caution for its own sake. It’s the only way to see every legitimate sender touching your domain before you risk blocking one. Parsing RUA data during this window, rather than eyeballing raw XML, makes the migration to enforcement far less risky.

  • Collect RUA reports for at least two to four weeks before any policy change, per operational guidance on staged rollout
  • Watch for volume spikes, sudden failure clusters, or a jump in complaint rate as your enforcement signal
  • Use relaxed alignment by default; reserve strict alignment for domains where you fully control every sending subdomain

Pro Tip: A dedicated RUA parser turns a wall of XML into a sortable table of sending IPs and pass rates, which is the difference between a five-minute weekly check and an afternoon lost to spreadsheets.

What managing this for client domains has taught me

Runleadpilot handles sending domain setup and DKIM rotation for every account we run, and the most common issue we catch isn’t a bad record. It’s a forgotten sender added months later that never got an SPF include, quietly failing DMARC until someone checks the reports.

— Harsh

A managed path if you’d rather not own this yourself

Getting SPF, DKIM, and DMARC right is a one-time technical project until you add a new sending tool, rotate a key, or onboard a client domain, then it becomes an ongoing maintenance job. Runleadpilot manages dedicated sending domains for every campaign it runs: rotating DKIM keys on a schedule, monitoring DMARC aggregate reports for failures, and handling inbox warmup so a new domain builds reputation before it sends at volume.

Runleadpilot

Doing it yourself works fine if you’re comfortable owning DNS changes and reading RUA reports weekly. If you’d rather hand off domain setup, monitoring, and warmup while you focus on replies instead of DNS records, you can build a free campaign preview and see how Runleadpilot’s managed outbound platform handles the infrastructure side before you commit to anything.

Sources

Recommended

See your next buyers before you launch.

LeadPilot finds the right people, researches each one, writes the outreach, and runs the follow-up.

Start freeHow LeadPilot works