Live Direct Marketing
Home → Blog → Deliverability

SPF, DKIM, DMARC: The Authentication Setup Every Sending Domain Needs

July 7, 2026 · 11 min read · Guide: Deliverability

Since Google and Yahoo tightened bulk-sender requirements, unauthenticated email is not just risky — for many recipient domains it is simply rejected or shunted to spam on arrival. If you send B2B outreach from your own domain, SPF, DKIM and DMARC are the entry ticket, not an optimization. This guide explains what each protocol verifies, the exact records to publish, and the mistakes that quietly break authentication months later.

Key takeaways
  • SPF says which servers may send for your domain, DKIM cryptographically signs each message, DMARC ties both to the visible From address and sets the policy for failures.
  • All three live as DNS TXT records; a full setup takes under an hour, and no cold email campaign should launch without it.
  • The most common breakages: exceeding SPF's 10 DNS lookup limit, forgetting DKIM alignment for a third-party relay, and leaving DMARC at p=none forever.
  • Start DMARC at p=none with report collection, then move to quarantine and reject once reports show all legitimate mail passing.
  • Authentication gets you judged fairly — it does not make you look good. Reputation still comes from volumes, bounces, and recipient behavior.

Why three protocols exist and what each one actually proves

Email's original design lets anyone put anything in the From field. The three authentication protocols were bolted on to fix specific pieces of that problem, and they only deliver full value together.

SPF (Sender Policy Framework) answers: is the server that delivered this message allowed to send mail for the domain in the envelope sender? You publish a DNS record listing your legitimate sending sources — your mail server, your SMTP relay, your CRM's sending service — and receiving servers check the connecting IP against it.

DKIM (DomainKeys Identified Mail) answers: was this message actually authorized by the domain and unmodified in transit? Your sending server signs each message with a private key; the matching public key sits in your DNS, and receivers verify the signature. Unlike SPF, a DKIM signature survives forwarding, which matters in corporate mail environments where messages hop through gateways.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that makes the first two meaningful to humans. SPF and DKIM can both pass on domains the recipient never sees. DMARC requires that at least one of them passes for a domain aligned with the visible From address, tells receivers what to do when neither does (nothing, quarantine, or reject), and sends you aggregate reports about who is sending mail claiming to be you.

Setting up SPF without hitting its hidden limits

SPF is one TXT record on your domain. It enumerates permitted senders through mechanisms like ip4, ip6, and include, and ends with a policy for everything else — almost always ~all (softfail) or -all (hardfail).

The trap that bites growing teams is the 10 DNS lookup limit. Every include, a, mx, and redirect in your record triggers lookups, and includes nest: one vendor's include can expand into four more. Exceed ten and receivers return permerror, which many treat as a failure — your SPF silently stops working while the record still looks fine to the eye. Audit the lookup count whenever you add a vendor, and remove services you no longer use.

Two more rules from practice. First, one SPF record per domain — publishing two TXT records both starting with v=spf1 is invalid, and merging them is the fix. Second, do not authorize more than you use: a record that includes half the internet's sending services is an invitation for anyone on those platforms to pass your SPF.

Example

A typical record for a domain sending via Google Workspace plus one SMTP relay: v=spf1 include:_spf.google.com include:relay.example-provider.com ~all

DKIM: keys, selectors, and the alignment detail everyone misses

DKIM setup is done on the sending side, not written by hand. Your mail platform or relay generates a key pair, gives you a TXT (or CNAME) record to publish under a selector — something like s1._domainkey.yourdomain.com — and starts signing outgoing messages. Use 2048-bit keys; 1024-bit is still seen in the wild but is weak by current standards.

The detail that quietly ruins deliverability: signing domain alignment. If a third-party service signs your mail with its own domain (d=provider.com) instead of yours, DKIM technically passes but DMARC alignment fails, because the signature domain does not match your From domain. Any serious provider lets you configure custom DKIM so the signature carries your domain — do it during onboarding, not after the first campaign underperforms.

Rotate keys periodically (selectors make this painless: publish a new selector, switch signing, retire the old one) and delete DNS records for services you have decommissioned. Old keys for abandoned vendors are an attack surface nobody monitors.

DMARC: policy, alignment, and the road from none to reject

DMARC is a TXT record at _dmarc.yourdomain.com. The minimum viable record sets a policy and a reporting address: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. With p=none nothing changes for delivery yet — but receivers begin sending you aggregate XML reports showing every source that sends mail as your domain and whether it passes authentication.

Run at p=none for two to four weeks and read the reports (a parsing tool or service helps; raw XML is miserable). You will typically discover forgotten senders — a billing system, an old marketing tool, a colleague's integration — that need SPF or DKIM fixed before you tighten policy. Then move to p=quarantine, optionally with pct= to phase in, and finally to p=reject once reports show all legitimate mail aligned and passing.

Getting to reject is worth the effort for a business domain: it shuts down direct spoofing of your exact domain, which protects your counterparties from fraud sent in your name and signals to mailbox providers that the domain is actively managed. For a dedicated cold-outreach sending domain, at minimum reach quarantine — major mailbox providers now expect a DMARC policy from senders of any meaningful volume, and its absence costs you inbox placement.

The cold outreach angle: authenticate the sending domain you actually use

B2B outreach teams usually send from dedicated domains or subdomains — outreach.company.com or a sibling domain — to separate campaign reputation from corporate mail. Every one of those sending domains needs the full trio configured independently. A perfect DMARC record on your main domain does nothing for the subdomain your campaigns actually use if that subdomain's own records are missing.

Corporate recipients raise the stakes: business mail gateways enforce authentication more aggressively than consumer inboxes, and a DMARC fail on an email to a target account's Microsoft 365 tenant often means silent quarantine — no bounce, no signal, just an email nobody ever saw. In address-based outreach, where a campaign might be forty emails to forty carefully chosen decision-makers, losing a third of them to a missing DKIM record is an expensive configuration error.

Keep perspective on what authentication buys you. SPF, DKIM and DMARC prove identity; they do not prove quality. A fully authenticated domain that blasts irrelevant mail still builds a bad reputation — authentication just ensures the reputation lands on the right domain. Inbox placement comes from the combination: verified identity, warmed domain, conservative per-mailbox volumes, low bounce rates, and recipients who reply. That last signal — real replies to genuinely relevant one-to-one email — is something no mass sender can fake, and it is the structural advantage of targeted outreach done properly.

Verification: prove it works before the first campaign

Never trust that records propagated correctly — verify end to end. DNS lookups confirm the records exist; a real test send confirms the whole chain signs and aligns.

The fastest full check: send a message from your outreach mailbox to a mailbox you control on a major provider, open the raw message source, and read the Authentication-Results header. You want three explicit passes: spf=pass, dkim=pass with d= equal to your domain, and dmarc=pass. Then repeat via every sending path you use — direct SMTP, relay, CRM sender — because each path signs differently.

Recheck on a schedule and after every infrastructure change. Most authentication failures in mature setups are regressions: someone migrated DNS and dropped a record, a vendor changed their include, a key rotation half-completed. A monthly automated check against a seed mailbox catches these before a campaign does.

Common failure patterns and how to avoid them

A few patterns account for most real-world authentication breakage. They are all cheap to prevent and expensive to discover mid-campaign.

Also resist the temptation to treat this as one-time setup. Sending infrastructure changes — new relays, new tools, domain migrations — and every change is a chance for a record to drift. Treat the trio as monitored infrastructure with an owner, the same way you treat TLS certificates.

FAQ

Do I need all three protocols, or is SPF plus DKIM enough?

You need all three. SPF and DKIM authenticate technical domains the recipient never sees; only DMARC ties authentication to the visible From address and sets a failure policy. Major mailbox providers now expect a DMARC record from any sender of meaningful volume — without it you lose inbox placement even if SPF and DKIM pass.

How long does setup take and does it require a developer?

For a single domain with one or two sending services, under an hour of actual work: three DNS TXT records plus enabling DKIM in each sending platform. Anyone comfortable editing DNS can do it. The longer phase is DMARC policy hardening — a few weeks of collecting reports before moving from none to quarantine to reject.

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

No — they are necessary but not sufficient. Authentication proves who you are so providers can apply your reputation accurately. Placement still depends on domain warm-up, sane per-mailbox volumes, bounce rates, content, and whether recipients engage. Think of authentication as the entry requirement, not the ranking factor.

Should I use a subdomain or a separate domain for outreach, and what does that change for authentication?

Either works; the non-negotiable part is that whatever domain appears in your From address must have its own complete SPF, DKIM and DMARC setup. A separate domain isolates campaign reputation fully. If you use a subdomain, remember DMARC on the organizational domain can cover subdomains via policy inheritance, but explicit records per sending subdomain are cleaner and easier to audit.

What is the difference between ~all and -all in SPF?

~all (softfail) asks receivers to treat non-listed sources with suspicion; -all (hardfail) declares them unauthorized outright. In practice, with DMARC deployed, the difference matters less than people think — DMARC's policy drives the final decision. A common robust choice is ~all on the SPF record combined with an enforcing DMARC policy.

What are DMARC reports and do I really need to read them?

Aggregate (rua) reports are XML summaries receivers send you, listing every IP that sent mail claiming your domain and the authentication results. They are how you discover forgotten legitimate senders before tightening policy — and how you spot spoofing attempts afterward. Use a parsing tool rather than reading XML by hand, and review monthly.

Important: this is not bulk email and not spam. We run targeted outreach: every message goes to a specific representative of a specific company for a legitimate business reason, in small daily volumes, personalised to the recipient. Every email identifies the sender and includes one-click opt-out; unsubscribes and stop-lists apply to all future campaigns without exception. Companies that ask not to be contacted are excluded permanently.

Want to apply this to your outreach?

We will map it to your segment and product — before any work starts.

Talk to us

More on this topic: Deliverability