Skip to content
Sales Pitch
Menu
English

Start DMARC With p=none: SPF and DKIM Setup for Outreach Teams

, 12 min read

Start DMARC With p=none: SPF and DKIM Setup for Outreach Teams

Decorative DMARC email authentication title card

SPF authorizes which servers can send mail for your domain, DKIM signs message content with a cryptographic key, and DMARC ties both results to the visible From address and tells receivers what to do when they fail. Publish SPF and DKIM first, then add a DMARC record with p=none so you can watch what happens before you enforce anything.

TL;DR:

  • Implement SPF with a single v=spf1 record at your domain’s root, ensuring no more than 10 DNS lookups to avoid permerrors.
  • Use 2048-bit DKIM keys and publish the selector-based public key DNS record to enable signature verification.
  • Set DMARC policy initially to p=none with aggregate report addresses, then escalate to quarantine or reject after monitoring for two to four weeks.
  • Use the Authentication-Results header in test emails and direct DNS queries to verify SPF, DKIM, and DMARC are correctly configured and actively passing.
  • Prioritize fixing DKIM signing across all platforms first, as it withstands forwarding better than SPF, and continually review reports before tightening enforcement.
Usesalespitch
Strengthen Your Outreach Deliverability
Sales Pitch provides practical insights, templates, scripts, and tools for B2B professionals improving cold email strategies and sales effectiveness.
Explore Sales Pitch

Table of Contents

What SPF, DKIM, and DMARC Each Do

Each protocol solves a different half of the authentication problem, and none of them works alone the way most people assume.

  • SPF (Sender Policy Framework) lists which IP addresses and servers are allowed to send mail for your domain. Its limitation: it checks the sending server, not the message content, so it breaks easily when mail gets forwarded.
  • DKIM (DomainKeys Identified Mail) attaches a digital signature to a message so the receiver can confirm it wasn’t altered in transit. Its limitation: the signature can break if an intermediary modifies signed headers or body content.
  • DMARC ties SPF and DKIM results to the domain in the visible “From” field, then tells receivers what to do with a failure and where to send reports.

A message passes DMARC when either SPF or DKIM passes and aligns with the From domain. That “either/or” detail is the one most beginners miss, and it’s the reason implementing all three matters more than getting any single one perfect.

How Do I Set Up an SPF Record Correctly?

An SPF record is a single TXT record at your root domain that starts with v=spf1 and lists authorized sources. A typical spf record example looks like this:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~all

Each mechanism does something specific:

  • ip4 / ip6 authorize a specific IP address or range.
  • a and mx authorize servers tied to your domain’s existing A or MX records.
  • include pulls in another domain’s SPF record, common when you use a marketing platform or CRM to send mail.

Pro Tip: Count your lookups before you publish. Every include can nest more lookups inside it, and RFC 7208 caps SPF at 10 total DNS lookups per check — cross that line and receivers return a permerror, which can mean outright rejection rather than a soft fail.

For spf record setup, use ~all (soft fail) while you’re auditing which servers actually send your mail. Only switch to -all (hard fail) once you’ve confirmed every legitimate sender is accounted for. Too many DNS lookups is one of the most common causes of SPF failure, usually from stacking multiple third-party includes without ever pruning old ones.

Illustration of SPF sender inventory and pruning

How Does DKIM Signing Actually Work?

DKIM signing happens on the sending server: a private key signs specific headers and the message body, producing a signature stamped into the DKIM-Signature header. The receiving server then looks up your public key in DNS to verify that signature matches.

  • The public key lives at a hostname built from a selector, formatted as selector._domainkey.yourdomain.com.
  • You’ll find your selector by opening a sent message’s raw headers and reading the s= value inside the DKIM-Signature line.
  • Use a 2048-bit key where your provider supports it. Older 1024-bit keys still work but offer weaker protection.

DKIM signatures are more resilient to forwarding than SPF, but they’re not bulletproof. Mailing lists, ticketing systems, and any intermediary that rewrites subject lines or adds footers can invalidate a signature by altering signed content. ARC (Authenticated Received Chain) exists specifically to preserve authentication history across these intermediaries, letting the final receiver see that a message passed authentication earlier in its journey even if the signature itself broke.

How Does DMARC Decide Pass or Fail?

DMARC doesn’t run its own authentication check. It reads the SPF and DKIM results and asks one question: does either of those checks align with the domain in the visible From address? A message passes DMARC when SPF or DKIM passes and aligns — you don’t need both to succeed, just one.

Two tags control how strict that alignment check is:

  • aspf and adkim can be set to relaxed (r) or strict (s). Relaxed allows a subdomain match (mail.yourdomain.com aligns with yourdomain.com); strict requires an exact match.
  • The p tag sets policy: p=none monitors without affecting delivery, p=quarantine sends failures to spam, p=reject blocks them outright.
  • The rua tag specifies where aggregate reports get sent, which is how you discover every server currently sending mail as your domain before you lock the door on any of them.

Skip the reporting step and you’re enforcing blind. Read it first.

Where Do These Records Live in DNS?

All three records are TXT records, but they sit at different hostnames, and getting the hostname wrong is the single most common setup mistake.

  • SPF: published at your root domain (often entered as @ in your DNS host’s interface).
  • DKIM: published at selector._domainkey.yourdomain.com, where the selector matches what your sending provider assigns.
  • DMARC: published at _dmarc.yourdomain.com.

Watch your TTL (time to live) during changes. A long TTL means old records linger in resolver caches for hours after you’ve updated them. And never publish two separate v=spf1 TXT records on the same domain. Combine every sender into one record. Multiple SPF records cause an automatic permerror, regardless of how correct each individual record is.

How Do I Check If SPF, DKIM, and DMARC Are Working?

Run these checks in order before you trust any record you’ve published:

  1. Open a test message’s raw source. In Gmail, use “Show original” to see the Authentication-Results header, which reports spf=pass, dkim=pass, and dmarc=pass (or their failure states) for that specific message.
  2. Query DNS directly. Run dig TXT yourdomain.com for SPF, dig TXT selector._domainkey.yourdomain.com for your DKIM public key, and dig TXT _dmarc.yourdomain.com for your DMARC policy. nslookup works the same way if you prefer it.
  3. Use an online validator or DMARC report parser to sanity check your syntax and to turn raw aggregate XML reports into something readable, since manually inspecting rua data isn’t practical once you’re getting daily reports from multiple mailbox providers.

Setting Up SPF, DKIM, and DMARC Step by Step

A staged rollout protects delivery while you tighten enforcement. Rushing straight to p=reject is how legitimate mail gets blocked.

  1. Inventory every sending source. List your email provider, CRM, marketing platform, helpdesk, and any transactional mail service. Anything sending as your domain needs a place in SPF or a DKIM signature.
  2. Publish one SPF record with ~all. This authorizes known senders without hard failing on anything you missed.
  3. Enable DKIM signing for each sender individually. Most platforms generate their own selector and give you the CNAME or TXT record to publish. Use 2048-bit keys wherever the provider offers the option.
  4. Publish DMARC at p=none with an rua address. This monitors without touching delivery, and it’s the step most guides skip past too quickly.
  5. Read the aggregate reports for two to four weeks. Fix any gaps: add missing IPs to SPF, or enable DKIM for a service you forgot.
  6. Move to p=quarantine, then p=reject. Only escalate once reports show consistently clean alignment across every real sender.

Pro Tip: When a third-party service (like a CRM or marketing platform) can’t send using your domain’s DKIM key, ask if it supports an aligned “return path” or custom sending domain — that’s often the only way to get DMARC alignment for mail you don’t control.

Only tighten SPF to -all once you’re confident the inventory step caught everything. A hard fail on an incomplete record blocks legitimate mail, not just spoofed mail.

Why Is My Authenticated Email Still Failing?

Most authentication failures trace back to one of four causes, and each has a specific fix.

  • Forwarding breaks SPF. When a message gets forwarded, receivers see the forwarding server’s IP, not your original sender’s IP, and SPF fails. DKIM survives forwarding more reliably than SPF, which is the main reason to lean on DKIM alignment rather than SPF alone for domains with heavy forwarding traffic.
  • Multiple SPF records or too many includes cause permerror. Merge every sender into a single record and remove unused includes from old vendors.
  • DKIM signatures break from content changes. Check which headers your provider signs, and confirm no intermediary (a mailing list, a security gateway) is rewriting the subject line or body after signing.
  • DMARC reports reveal senders you forgot. Aggregate rua reports will show IPs failing authentication that you didn’t know existed. Add legitimate ones to SPF or enable aligned DKIM rather than ignoring the failures.

What This Means for Cold Email Deliverability

Authentication is the floor, not the ceiling, for inbox placement. Large mailbox providers now require SPF, DKIM, and DMARC for high-volume senders, but passing all three doesn’t guarantee an inbox; reputation, engagement, and content still weigh heavily on where a message lands. That distinction matters most for outreach teams sending cold email at volume, where a clean deliverability setup has to pair authentication with list hygiene and sending patterns that don’t look like spam.

A working checklist for outreach teams:

  • Confirm your sending domain and From address are the same domain your SPF and DKIM authorize.
  • Enable DKIM signing on every platform you use to send outreach, not just your primary inbox provider.
  • Watch DMARC aggregate reports weekly during any campaign ramp-up, not just once at setup.
  • Send test messages to a Gmail address before scaling volume, and read the Authentication-Results header on each one.

What I’d Prioritize First

If you only fix one thing this week, fix DKIM signing across every sending platform. It survives forwarding better than SPF, and DMARC monitoring shows you exactly what’s still failing before you flip enforcement on. Run the test: publish records, send to a Gmail address, open “Show original.” Authentication earns trust; it doesn’t buy you an inbox by itself.

— Samuel

Where to Go Next for Deliverability and Outreach

Fixing SPF, DKIM, and DMARC solves the authentication half of the deliverability equation. The other half is what you send and how often, which is where most cold email programs actually lose ground even after their DNS is clean. There are platforms built around exactly that gap. It’s the practical alternative to sifting through vendor documentation and forum threads for advice on what actually predicts a spam folder placement versus what just sounds plausible.

Usesalespitch

If you’re running outreach and want to know what happens after authentication passes, the deliverability guide on what actually predicts the spam folder breaks down the engagement and content signals mailbox providers weigh once SPF and DKIM checks clear. And once your domain is sending clean, pull from 12 cold email templates that convert to make sure the messages landing in that authenticated inbox are worth opening. Start with the deliverability guide, then swap in a template for your next send.

Sources

FAQ

What Is SPF, DKIM, and DMARC?

SPF authorizes which servers can send mail for your domain, DKIM signs message content to prove it wasn’t altered, and DMARC ties those results to the visible From address while setting policy for failures. DMARC passes when either SPF or DKIM passes and aligns with that From domain.

How Do I Check SPF, DKIM, and DMARC?

Open a test message’s raw headers (Gmail’s “Show original”) and read the Authentication-Results line for spf=pass, dkim=pass, and dmarc=pass. You can also run dig TXT against your domain, your DKIM selector’s _domainkey hostname, and _dmarc.yourdomain.com to confirm what’s actually published in DNS.

How Do I Set Up SPF, DKIM, and DMARC?

Inventory every sending source first, then publish one SPF TXT record with ~all, enable DKIM signing per sender with a published selector, and add a DMARC record at _dmarc starting with p=none and an rua reporting address. Watch reports for a few weeks before moving to p=quarantine and eventually p=reject.

Does DMARC Need Both SPF and DKIM?

No. DMARC only needs one of the two, SPF or DKIM, to pass and align with the visible From domain. Most practitioners still implement both because SPF frequently fails when messages are forwarded, and DKIM offers a more reliable backup in that scenario.

More from the blog