How to Set Up SPF and DMARC Without Breaking Email

Last updated: June 10, 2026

Most email authentication disasters happen the same way. Someone reads about DMARC and sees that p=reject is the destination. They publish a reject record on Monday. By Friday they are fielding angry calls because none of their cold email is reaching prospects. The protocols themselves work fine. The rollout broke them.

This guide walks through a phased seven-step deployment that protects legitimate mail flow at every stage. It assumes you understand what SPF, DKIM, and DMARC each do. If you do not, start with our companion article on SPF, DKIM, and DMARC explained. This piece is the practical how-to. The differentiator is the recovery section at the end. If you have already broken email, that is where to start.

The Setup Order That Doesn’t Break Anything

The safe rollout order is SPF first, then DKIM, then DMARC. Within DMARC, start at p=none for two to four weeks. Move to p=quarantine when aggregate reports are clean. Move to p=reject after another clean window. The order prevents breaking legitimate mail.

The sequence is not arbitrary. Each protocol depends on the ones before it. DMARC checks whether SPF or DKIM passed and whether the authenticated domain aligns with the visible From address. Publishing DMARC before SPF and DKIM are solid means DMARC has nothing to evaluate. Rushing to p=reject before alignment is consistent means DMARC rejects your own legitimate mail.

The realistic timeline matters. A 2024 Valimail report found that only 28.5 percent of domains with a published DMARC record have reached p=reject enforcement. That statistic is not about technical difficulty. It is about how long careful monitoring takes. Six to ten weeks is realistic for a small organization with five to ten sending sources. Larger environments with many third-party senders typically need three to six months.

Step 1: Inventory Every System That Sends Mail for Your Domain

Before changing any DNS record, list every system that sends mail using your domain. This includes your primary mail provider, marketing automation, transactional email services, CRMs, help desks, and monitoring systems. This inventory is the foundation. Skipping it causes most breakage.

Walk through your stack and list everything that sends email. Be exhaustive. The systems that quietly send a few messages per week are the ones you forget about. They are also the ones that break when you advance DMARC.

Categories to cover in your inventory:

• Primary mail provider — Google Workspace, Microsoft 365, Zoho Mail, or self-hosted infrastructure.
• Transactional email services — SendGrid, Postmark, Mailgun, Amazon SES, SparkPost. These handle password resets, receipts, and other automated mail.
• Marketing automation — Mailchimp, HubSpot, ActiveCampaign, Klaviyo, Constant Contact.
• CRM and sales tools — Salesforce, HubSpot CRM, Pipedrive, Apollo, Outreach.
• Help desk and ticketing — Zendesk, Intercom, Help Scout, Freshdesk.
• Survey and form tools — SurveyMonkey, Typeform, Google Forms.
• Webinar and event platforms — Zoom Webinar, Eventbrite.
• Monitoring and alerting — PagerDuty, Datadog, server monitoring scripts.
• Internal tools — anything that calls sendmail or an SMTP relay from your own infrastructure.

Document each entry with three pieces of information. The service name. The sending domain or subdomain it uses. And whether the service has its own DKIM key in your DNS. This list becomes your authentication checklist for the next three steps.

Step 2: Build (or Fix) Your SPF Record

Your SPF record is a single DNS TXT record listing every authorized sender. Build it by combining the include: mechanisms from each provider in your inventory. Keep it under the 10-DNS-lookup limit. End with ~all (softfail) in most cases.

SPF is published as a TXT record at your domain root. There can be only one. If you already have an SPF record, you edit it. You do not publish a second one.

A typical multi-provider SPF record looks like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org ip4:198.51.100.10 ~all

Each include: mechanism references another SPF record (your providers’ records) whose authorized senders merge into yours. The ip4: mechanism adds specific server IPs. The trailing ~all tells receivers what to do with senders not on the list.

Choosing Between ~all and -all

The trailing mechanism controls SPF’s failure mode. -all is hard fail. Mail from unlisted senders should be rejected outright. ~all is soft fail. Mail from unlisted senders is suspicious but not rejected at the SPF layer.

Use ~all for most deployments. SPF breaks during legitimate forwarding because the IP changes. Hard fail at the SPF layer can reject mail that DMARC would have handled correctly through DKIM alignment. Soft fail defers the policy decision to DMARC, which is where it belongs.

The 10-DNS-Lookup Limit

RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups. Each include:, a, mx, ptr, and exists mechanism counts. The ip4: and ip6: mechanisms do not. Exceeding 10 lookups produces a permerror result, which most receivers treat as an SPF failure.

A few mature stacks naturally cross 10 lookups. The fix is SPF flattening. This replaces include: mechanisms with their resolved IP addresses. A managed flattening service maintains the record and updates it as upstream IPs change. Verify your current lookup count with our SPF Record Lookup tool. Generate compliant records with our SPF/DMARC Generator.

Step 3: Enable DKIM at Every Sending Source

Configure DKIM at every system in your inventory. Each system publishes its own public key in your DNS using a selector. Most managed providers handle key generation automatically. Verify each by sending a test message and checking for dkim=pass in the Authentication-Results header.

DKIM operates per sending source. Each provider in your inventory generates its own RSA key pair. The provider gives you a DNS record to publish at selector._domainkey.your-domain.com. The selector name varies by provider. Google Workspace uses google. Mailchimp uses something like k1. SendGrid uses a UUID-based selector.

For most managed providers, the workflow is identical. Open the admin console. Find email authentication or DKIM settings. The provider generates a key and gives you a TXT record to publish. Add the record to your DNS. Return to the admin console and click verify.

Key Length in 2026

Use 2048-bit RSA keys where the provider supports it. RFC 8301 still permits 1024-bit keys, but treat them as a legacy fallback only. Google strongly recommends 2048. Microsoft 365 defaults to 2048. Some providers also support Ed25519 (RFC 8463), which produces shorter records and faster signing. Microsoft 365 and Yahoo do not verify Ed25519 signatures yet, so dual-sign if you adopt it.

For self-hosted infrastructure, generate keys with at least 2048-bit RSA. Rotate them on a yearly schedule. Most managed providers handle rotation automatically.

Verifying DKIM Works

Send a test message from your domain to a Gmail or Outlook address you control. Open the message and view the original source. Look for the DKIM-Signature header on the message and a dkim=pass result in the Authentication-Results header. Repeat for every sending source in your inventory.

Step 4: Publish DMARC at p=none and Wait

Publish a DMARC record at _dmarc.your-domain.com with p=none and a valid rua= reporting address. The record activates aggregate reporting without affecting mail delivery. Aggregate reports arrive within 24 hours. Run at p=none for two to four weeks of monitoring.

The DMARC record is a single TXT record at the _dmarc subdomain. A starter record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1; adkim=r; aspf=r

Each tag has a specific purpose:

• v=DMARC1 — declares the version. Always exactly this.
• p=none — policy. Monitoring mode. No action taken on failing mail.
• rua=mailto: — the address that receives aggregate reports. Use a dedicated mailbox.
• fo=1 — failure options. Generate a report if any auth check fails.
• adkim=r, aspf=r — relaxed alignment for DKIM and SPF. Allows subdomain matching.

Use a dedicated mailbox for the rua= address, not a person’s inbox. Aggregate reports arrive daily from every major provider. The volume builds up quickly. Some teams use a free reporting service like Postmark DMARC Digests, which generates the receiving address for you.

The Subdomain Question

If you do not include an sp= tag, subdomains inherit the p= value. If you publish p=none at the root, subdomains also operate at p=none by default. You can override this by adding an explicit sp= tag. For most early-stage deployments, omitting sp= is fine.

Step 5: Read Your Aggregate Reports (What to Look For)

Aggregate reports arrive as XML attachments to your rua= address. Use a free service like Postmark DMARC Digests or dmarcian’s free tier to parse them. Look for unrecognized sending IPs, consistent SPF or DKIM failures, and the overall DMARC pass rate. Fix gaps before advancing.

Raw aggregate reports are XML files. Each one summarizes a single day of mail claiming to come from your domain at one receiver. Reading XML by hand is painful. The first practical move is to pipe the reports into a parsing service.

Free Parsing Services

• Postmark DMARC Digests — the lowest-friction option. Sign up, get a forwarding address, point your rua= at it, and receive weekly email digests. No login required. Free for unlimited domains.
• dmarcian Free Tier — one domain, dashboard-based, more visualization than Postmark. Good if you want to drill into specific senders.

Paid platforms like EasyDMARC and DMARC Analyzer start around eight dollars per month. They offer richer dashboards, alerting, and multi-domain management. For a single-domain organization, the free tier is usually enough.

What to Watch in Your Reports

Three patterns matter during the p=none monitoring phase:

1. Unrecognized sending IPs. Cross-reference the reported sending IPs against your inventory. Anything you do not recognize is either a third-party sender you forgot or a spoofing attempt. Both need attention before you advance.
2. Consistent SPF or DKIM failures from legitimate sources. A known sender failing repeatedly means the SPF record needs an update or the DKIM key is misconfigured. Fix at the source.
3. The DMARC pass rate. You want this consistently above 95 percent across at least 30 days before moving to p=quarantine. The metric is total messages passing DMARC divided by total messages.

For a domain-level health check during this phase, use our Email Auth Checker. It audits SPF, DKIM, and DMARC configuration in a single query.

Step 6: Move to p=quarantine When Reports Are Clean

Move to p=quarantine when reports show your DMARC pass rate consistently above 95 percent. Every legitimate sender must be authenticated. Update the policy tag in your DMARC record. Continue monitoring for two to four weeks before the final step.

The transition is a single edit. Change the policy tag in your DMARC record from p=none to p=quarantine. Everything else stays the same.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; fo=1; adkim=r; aspf=r

At p=quarantine, receivers send DMARC-failing mail to the spam folder rather than delivering normally. Legitimate mail that slipped past your monitoring still gets to recipients, just in a less prominent place. This is the safety net before p=reject.

Gradual Rollout After DMARCbis

Older guides recommend the pct= tag for partial rollout. p=quarantine; pct=50 applied quarantine to half of failing messages. RFC 9989 deprecates pct= because receivers implemented it inconsistently. Remove it from your record at the next DNS edit.

The replacement is the t= flag. t=y tells receivers the policy is in testing mode. t=n (the default) signals full enforcement. For a truly gradual rollout, advance one subdomain at a time using the sp= tag instead.

Watch reports carefully during the first week. Look for any new failure pattern. If something legitimate starts failing, pause and fix the authentication before advancing. After two to four weeks of clean reports at quarantine, advance to the final step.

Step 7: Move to p=reject When You’re Confident

Move to p=reject when reports show stable pass rates after two to four weeks at p=quarantine. The final stage refuses delivery of mail that fails authentication. This is the gold standard for protecting your domain from spoofing. Most organizations target this state.

The final transition is another single edit. Change the policy tag from p=quarantine to p=reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; fo=1; adkim=r; aspf=r

At p=reject, any message that fails DMARC authentication is refused at the SMTP layer. The sending server receives a 5xx permanent failure. The recipient never sees the message. This is the maximum protection against domain spoofing.

Continue monitoring aggregate reports after the move. Email infrastructure changes over time. New tools get added. Old keys expire. Domains change ownership. Ongoing monitoring catches new gaps before they become deliverability incidents. Most organizations review reports at least weekly even after reaching p=reject.

Do not add the legacy pct=100 tag to new records. RFC 9989 deprecates pct=, and conformant receivers now ignore it. A clean record at p=reject needs no extra tags.

Common Setup Mistakes (and How to Recover)

If you have already broken mail by advancing DMARC too fast, the fix is to revert. Roll the policy back to p=quarantine rather than all the way to p=none. Read aggregate reports to identify which senders are failing. Fix authentication for each one. Then re-advance through the stages.

Five recovery patterns cover most disasters.

Pattern 1: You Went Straight to p=reject and Mail Is Bouncing

This is the most common scenario. Symptoms include sales reporting that prospects are not replying to cold email. Marketing seeing the open rate crater. Customer support tickets about missing receipts.

The immediate fix is a rollback. Do not go all the way to p=none. You lose all protection that way. Instead, move to p=quarantine, optionally with t=y to signal testing mode. This stops the hard rejections and routes failing mail to spam instead. Then read your aggregate reports for the next 48 hours to identify what is failing.

Pattern 2: A Third-Party Sender Is Misaligned

Symptom: a specific service (often a marketing platform) shows up in DMARC reports as failing alignment. SPF or DKIM passes, but the authenticated domain does not match your From address.

The fix is one of two options. Configure the platform to use a custom Return-Path domain that is a subdomain of yours. Or enable that platform’s custom DKIM signing with your domain. Most platforms support at least one of these. The custom DKIM option is usually easier to set up.

Pattern 3: SPF Is Past the 10-Lookup Limit

Symptom: intermittent SPF failures with a permerror result in Authentication-Results. This breaks SPF entirely.

The fix is SPF flattening. Replace deeply nested include: chains with the resolved IPs. Use a managed flattening service that keeps the resolved IPs current. Or consolidate by removing services you no longer use.

Pattern 4: Forwarded Mail Is Failing

Symptom: messages forwarded from one address to another are landing in spam or bouncing. SPF reports show fail. The receiving IP is the forwarder, not your original sending server.

SPF cannot survive forwarding because the IP changes. The fix is making sure DKIM is set up and aligned, because DKIM signatures travel with the message. With DKIM aligned, DMARC passes via the DKIM path even when SPF fails.

Pattern 5: Reports Stopped Arriving

Symptom: your rua= mailbox stops receiving aggregate reports for a few days. You feel blind.

Check the mailbox is not full or filtering reports as spam. Verify the DMARC record is still published and syntactically valid. Use a public DMARC checker to confirm the record parses correctly. Most outages here are mailbox-side, not protocol-side.

Related Tools & Resources

NetworkCheckr offers three tools that pair with this guide. The SPF/DMARC Generator builds compliant records at each stage. The SPF Record Lookup verifies your deployment. The Email Auth Checker audits your domain’s posture end to end.

• SPF/DMARC Generator — build compliant SPF and DMARC records for each stage of the rollout.
• SPF Record Lookup — verify your current SPF record and count its DNS lookups.
• Email Auth Checker — audit SPF, DKIM, and DMARC for any domain in a single query.
• TXT Record Lookup — query any TXT record, including DKIM selectors at selector._domainkey.
• DNS Propagation Checker — track DNS changes after publishing SPF, DKIM, or DMARC updates.
• SPF, DKIM, and DMARC Explained — the companion pillar piece that covers what each protocol does.
• How Long Does DNS Propagation Take? — understand the timing when changes are not yet visible.
• All NetworkCheckr Tools — the full set of free networking utilities.

Frequently Asked Questions

Six questions cover the practical edge cases during deployment. How long the rollout takes. What to do with multiple mail providers. How to handle subdomains. Whether DKIM is optional. The cost of DMARC reporting. And what actually happens at p=reject if you missed a sender.