← All articles

SPF, DKIM and DMARC Explained for Sales Teams

September 28, 2026 · 11 min read · by the 0effort team

TL;DR: SPF lists which servers may send for your domain. DKIM proves the domain in its d= tag signed the message unaltered — often the tool's domain, not yours. DMARC checks whether either aligns with your From address and applies your policy if not. Sales teams break this by adding a tool's SPF include without also aligning its DKIM or Return-Path.

Most explainers treat SPF, DKIM and DMARC as one DNS chore: paste three records, done. That framing survives right up until a sales team adds a fourth sending tool and mail from it starts landing in spam with zero error message in sight. The three records aren't a chore you finish. They're a running permission list, and every new tool that sends from its own infrastructure or an ESP has to be added to it by hand. The exception is a tool that sends through your team's already-connected Gmail or Microsoft 365 mailbox over OAuth or SMTP; that mail rides on the mailbox's existing authentication and needs no new SPF include or DKIM selector.

Here's what each record actually does, and where the list quietly goes stale.

What do SPF, DKIM and DMARC each actually prove about an email you send?

Each answers a narrow, mechanical question — none judges whether the email is good, wanted, or written by a human.

A tool reporting "SPF: pass" has confirmed one thing: the sending IP was on the list for whichever domain sat in the Return-Path. It says nothing about the address your prospect reads in their inbox — that link is what DMARC checks, and only DMARC checks it.

Why did authentication become mandatory for outbound sales teams in 2024–2025?

Because mailbox providers got tired of policing spam after delivery and started requiring proof of sender identity before it. Since February 2024, Google's email sender guidelines (accessed 2026-09-28) require anyone sending 5,000+ messages a day to Gmail addresses to publish SPF, DKIM and a DMARC record (at minimum p=none), support one-click unsubscribe on marketing mail, and keep spam complaints under 0.3%. Yahoo enforces a parallel bulk-sender bar through its Sender Hub (accessed 2026-09-28) without publishing an equivalent volume figure, so don't assume Yahoo's cutoff matches Google's. Microsoft published its own bulk-sender rules for Outlook.com, Hotmail and Live addresses in a Microsoft Defender for Office 365 Tech Community post (accessed 2026-09-28), published 2025-04-02 and enforced from 2025-05-05: senders of more than 5,000 messages a day need SPF, DKIM, and a DMARC record at least at p=none aligned with SPF or DKIM — the same 5,000-message threshold as Google's.

Two qualifiers get dropped constantly. First, the bulk threshold isn't the whole obligation: Google requires SPF or DKIM from every sender delivering to Gmail, bulk or not, so 400 messages a day split across Gmail, Outlook and a dozen smaller domains still needs basic authentication. A sub-bulk sender is exempt from the DMARC record and one-click unsubscribe requirements, which only kick in at the 5,000-message bulk threshold; the 0.3% spam-rate cap in Postmaster Tools applies to every sender regardless of volume. Second, none of this requires p=reject. p=none satisfies the DMARC-record portion of the mandate as a monitoring policy — but the mandate also requires the SPF or DKIM pass to align with your visible From domain, the same alignment DMARC always checks. A 5,000+/day sender using a tool that signs with its own domain (d=tool.com, unaligned) and whose Return-Path also isn't covered by your SPF record fails the mandate even with p=none published: neither DKIM's d= nor the Return-Path domain aligns, so the policy record exists but has nothing passing to apply to. p=none is a legitimate first step, not a loophole — it satisfies the record requirement while you find and fix the senders that don't align yet, not a reason to treat the alignment requirement as optional.

How do you find every tool that is sending email as your domain?

This is the part a DNS-focused checklist skips, and it's the real point of failure for a sales org. You cannot authorize a sender you don't know exists, and nobody keeps a master list by hand: sales connects a sequencer this quarter, someone spins up an AI SDR, the meeting scheduler starts sending its own confirmations, and DNS never hears about any of it.

Two sources surface the full list. Your DMARC aggregate reports are XML files that most large mailbox providers — and fewer small ones — mail daily to the address in your record's rua= tag; they show nearly every sending IP that claimed your domain, whether it passed, and whether it aligned. A free parser from Postmark, dmarcian or Cloudflare turns the XML into a readable table in minutes. The second source is a plain walk through your revenue stack: sequencer, CRM, calendar tool, AI SDR, transactional ESP, anything legacy. Ask which of them send as your domain, then cross-reference against your SPF include: list and DKIM selectors. Anything on the report that isn't on either list is a sender you forgot to add or should shut off.

What does a correct SPF record look like when you use several sales tools, and how does it break?

A domain may publish exactly one SPF TXT record — never two. When a sales team adds a third tool, the record doesn't get a second entry; it gets a new include: mechanism appended to the existing one, e.g. v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.yourtool.com -all.

It breaks two predictable ways. Someone who doesn't know the one-record rule adds a competing second SPF TXT record, and having two produces a permanent error that fails SPF for every sender listed in either. Or the record survives but keeps growing, and SPF caps lookups at 10 per check (include, a, mx, ptr, exists and redirect each count). Cross that ceiling and the entire record returns permerror, failing SPF for the tool that pushed it over and every tool already there. The fastest way to blow past that ceiling isn't adding an eleventh tool — it's a nested include, where one vendor's SPF record itself includes another vendor's, which burns through the 10-lookup budget faster than your own tool count suggests.

How DKIM signing works for a sequencer or AI SDR that sends on your behalf

A third-party sending tool signs your mail one of two ways, and which one it uses changes what you configure. Some tools sign with their own domain in the DKIM d= tag. That's valid, but it proves their domain sent the mail, not yours, which matters the moment DMARC checks alignment against your From address. Better-integrated tools let you delegate signing: add a CNAME pointing their DKIM selector at their DNS, and the tool signs with your domain in d=, aligned with your From address by design.

A CNAME to paste during setup isn't proof on its own — tools also hand out CNAMEs for custom-tracking domains and Return-Path/bounce addresses, which have nothing to do with DKIM. Check that the host it asks you to point looks like a <selector>._domainkey record; then confirm in a real message's Authentication-Results header that the d= domain is actually yours. A tool that "just works" with no DNS step at all is often signing with its own domain instead.

What is DMARC alignment, and why can an email pass SPF and DKIM yet still fail DMARC?

Alignment is the check DMARC adds that SPF and DKIM don't perform alone: whichever one passed also has to match (under the default "relaxed" mode, share the same registrable domain as) your visible From header. DMARC needs either SPF or DKIM to align, not both. That matters because SPF tends to break on a forwarded message, while a DKIM signature usually survives a clean forward since it travels with the body and headers rather than depending on which server relayed it.

The common sales-team failure: SPF passes, but against the tool's own bounce domain in the Return-Path (say bounces.tool.com), not yours. DKIM passes too, but the d= domain is tool.com, also not yours. Both records are green, and neither one aligns with the domain the recipient actually saw in From, so DMARC fails.

Running cold outreach from a secondary domain, and how to authenticate it

Many teams run cold outreach from a domain adjacent to their primary (trycompany.com next to company.com) so a reputation hit doesn't touch the domain running invoices and password resets. That isolation only holds if the secondary domain gets treated as a full, separate identity in DNS.

DMARC protects the exact domain in the From header and its genuine subdomains; nothing else inherits coverage automatically. A secondary domain needs its own SPF record, its own DKIM selectors, and its own DMARC record with its own policy and rua= address. Leave that DMARC record at p=none, or skip it, and the domain stays open to direct-domain spoofing — aligned DKIM plus DMARC at enforcement (quarantine or reject) is what actually closes that gap.

How do you move DMARC from p=none to enforcement without blocking your own sales emails?

Ramp it in a fixed sequence, reading the reports before each step rather than racing to a deadline.

1. Stay at p=none until the reports are clean. Treat two to three weeks as a floor, not a fixed calendar — keep collecting reports until every sender from the audit above shows its SPF include and DKIM selector in place, however long that takes.
2. Move to quarantine at a low percentage (pct=10) once every legitimate sender is aligning, and watch for mail that shouldn't be landing in spam. pct= isn't honored consistently by every receiver and is being phased out under the DMARCbis update, so don't rely on it alone to cap blast radius.
3. Rehearse on a subdomain first, if you want a lower-risk test. Publish a separate, stricter DMARC record on a subdomain you control (its own _dmarc.sub.yourdomain.com TXT record) and route a slice of sends through it — that record enforces independently of the domain your sales mail actually sends from. This isn't the same as the org domain's sp= tag, which only sets the inherited policy for subdomains that don't publish their own record: sp= can't test one subdomain in isolation, and it does nothing for the apex domain itself.
4. Go to reject only once quarantine holds clean on the domain sales mail actually sends from.

Jumping straight to reject before the reports are clean is the fastest way to cause a self-inflicted outage. A sender with neither aligned SPF nor aligned DKIM doesn't vanish quietly: the receiver rejects it outright at SMTP time with a 5xx (Gmail returns 550 5.7.26), which generates a bounce back to the Return-Path domain. The trap is where that bounce lands. For a third-party tool, the Return-Path is usually the tool's own bounce domain, not an inbox your sales team ever checks, so the failure still goes unnoticed until a prospect mentions never getting the email.

What passing authentication doesn't fix about cold email deliverability

Authentication is necessary, not sufficient. Passing SPF, DKIM and DMARC clears the first gate that reputation systems check, and reputation itself is partly keyed to the authenticated domain — but clearing that gate doesn't decide where mail lands after it. Whether a message then reaches the inbox or spam is also decided by sender reputation, engagement, list quality and volume. Clean, aligned records with a bad sending history still land in spam. Failing authentication is the sharper failure mode: Gmail and Yahoo increasingly reject bulk senders outright at SMTP time for it, and even below the bulk threshold, unauthenticated or misaligned mail is heavily penalized in spam filtering rather than weighed on equal footing. Our deliverability checklist covers what sits past this gate, and our cold email guide covers how authentication fits the rest of an outbound program.

FAQ

Do I need all three of SPF, DKIM and DMARC, or is one enough?

All three is the recommendation, not a universal requirement — the minimum varies by receiver (Google, for instance, accepts SPF or DKIM alone from senders below its bulk threshold). SPF and DKIM are the mechanisms that can pass; DMARC checks whether either aligns with your visible From domain and tells receivers what to do if not. Run SPF or DKIM alone and you get a pass/fail signal with no alignment check and no reporting — no way to spot a misconfigured sender until it fails loudly, which is why all three is worth doing regardless of which minimum applies to you.

Can I have more than one SPF record if I use multiple sending tools?

No — a domain publishes exactly one SPF TXT record. Two return a permanent error and fail SPF for everyone. Add each new tool as another include: inside your single existing record instead.

Does a DMARC policy of p=none still protect my domain?

It gives you visibility, not protection, and only if you set it up for that. p=none tells receivers to take no special action on mail that fails alignment, so nothing gets blocked or quarantined because of it. The aggregate reports come from a separate tag in the same record, rua=; publish p=none without rua= and you get a monitoring policy that generates no reports at all, which defeats the reason to start there.

Will setting up SPF, DKIM and DMARC keep my cold emails out of spam?

No — treating it as the fix is the most common mistake here. Authentication proves who sent the message; it says nothing about sender reputation, list quality, or whether the content reads as genuine. Passing all three earns a fair evaluation; it doesn't guarantee a good one.

Does my secondary outreach domain need its own SPF, DKIM and DMARC records?

Yes. DMARC protects only the exact domain in the From header and its true subdomains, so a secondary or lookalike domain gets zero coverage from your primary's records. Give it its own full set, including its own reporting address, or it's authenticated nowhere.

How long do DNS changes for SPF, DKIM and DMARC take to work?

Propagation itself usually finishes within a few hours, governed by the TTL on the record you changed. Verifying it is a different timeline: a single message's headers confirm the change immediately, but DMARC's aggregate reports — the ones that reveal senders you didn't know about — arrive roughly once a day, so give it at least a week before concluding you've found every sender using your domain.