SPF, DKIM, and DMARC Explained for B2B Marketing Teams

Your sales team spent two weeks on a nurture sequence. The copy is clean, the offer is relevant, the list is scrubbed. Open rates crawl at 9%. Replies are ghosts. You check the email account of someone who clicked "this is spam" and notice the message landed in junk. The campaign died, but the campaign wasn't the problem. The domain was.

If you have ever opened a Mailchimp or HubSpot deliverability report and seen the line "SPF or DKIM authentication failed," this article is for you. SPF, DKIM, and DMARC are the three DNS records mailbox providers use to decide whether an email from your domain is actually from you. Get them wrong, and the rest of your marketing — the list, the copy, the offer — never gets a fair read.

We will keep this in operator language, not RFC lawyer language. No deep protocol history, no DNS theory, no reference to RFC 5321. Just what each record does, what breaks when it is missing or wrong, and the exact order to fix it in.

What SPF actually does (and the one mistake every growing B2B team makes)

SPF stands for Sender Policy Framework. It is a TXT record on your sending domain that lists the IP addresses and hosts allowed to send email on your behalf.

When a receiving mail server (Gmail, Outlook, Microsoft 365, Proofpoint) gets a message claiming to be from @yourcompany.com, it does a quick DNS lookup, finds your SPF record, and asks a simple question: "Is the IP that just connected to me listed as a permitted sender?" If yes, SPF passes. If no, SPF fails and the message starts its journey toward the spam folder or a hard rejection.

Here is the mistake we see in roughly 8 out of 10 B2B audits: the SPF record only includes the original ESP the company set up three years ago.

The team adds HubSpot Marketing. New record. They add Outreach or Salesloft for SDR cadences. New record. They add a transactional sender like Postmark or SendGrid for product emails. New record. They add a new SDR's cold outbound tool. New record. None of the old ones get removed. Eventually the record crosses the 10 DNS lookup limit — a hard technical ceiling defined in the SPF spec — and everything starts silently failing.

The fix is not to keep adding strings. The fix is to consolidate. Move every sending tool behind one of two well-managed envelopes:

• –One subdomain for marketing and lifecycle (e.g. mail.yourcompany.com or go.yourcompany.com)
• –One subdomain for transactional and product emails (e.g. notify.yourcompany.com)

Then write a clean SPF record for the apex domain and separate, simpler records for each subdomain. If you want to see this in context of an actual deliverability audit, the walkthrough in Mailchimp Emails Going to Spam? Start With This Deliverability Audit follows the same pattern from a different angle.

What DKIM actually verifies (it is not just "signed email")

DKIM stands for DomainKeys Identified Mail. Where SPF checks the envelope sender, DKIM checks the message itself.

When your sending platform transmits an email, it attaches a cryptographic signature to the message headers. That signature is generated using a private key stored on the sending server. The matching public key is published as a TXT record in your DNS under a specific selector name (something like s1._domainkey.yourcompany.com).

When the receiving server gets the message, it pulls your public DKIM key, verifies the signature against the message body and a defined set of headers, and decides: "Has this message been tampered with since it was signed? Was it signed by the right domain?"

If the signature checks out, DKIM passes. If the message was modified in transit (sometimes by a forwarding rule, sometimes by a buggy CRM appending tracking links), the signature breaks and DKIM fails.

Two things B2B teams get wrong here:

1. They rotate ESPs and never publish the new DKIM key. The old key sits in DNS, the new platform signs with a different selector, and nothing aligns.
2. They enable link tracking in a way that rewrites body content after signing. The signature was generated for the original message, then the ESP rewrites every link, and the signature no longer matches the body. Receivers treat this as a soft fail.

The fix is boring but specific: confirm each sending tool is publishing its own DKIM selector, then verify in a tool like MXToolbox or your ESP's free inspector that the signature is actually aligning with your From: domain. If you are running cold outbound at the same time, a signed domain for that subdomain is non-negotiable — see how this plays out in Why Meta Lead Ads Bring Bad Leads and How to Fix the Funnel for the upstream volume problem, then come back to authentication for the downstream fix.

What DMARC actually does (and why it is the most underused record)

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It ties SPF and DKIM together and tells receivers what to do when messages fail.

A DMARC record is a single TXT record published at _dmarc.yourcompany.com. It does three jobs:

1. Alignment check. It defines which domain has to match between the visible From: header and the authenticated SPF/DKIM domain. By default, this is relaxed (subdomains count) or strict (must match exactly).
2. Policy. It tells the receiver what to do with messages that fail. p=none means "report only, deliver anyway." p=quarantine means "send to spam." p=reject means "block entirely."
3. Reporting. It tells receivers where to send forensic reports (RUA — aggregate, RUF — forensic) so you can see who is sending as your domain and whether they are passing.

Most B2B teams we audit have p=none or no DMARC record at all. That is a missed opportunity. With p=none and reporting enabled, you can see exactly which services are impersonating your domain — your HR system, your CRM, your old newsletter tool that no one remembers. With reporting, you can clean up the legitimate senders and tighten policy to p=quarantine, then eventually p=reject.

DMARC at p=reject is the goal. It is the only record that actively tells mailbox providers, "Block anyone pretending to be us." It also makes your domain harder to spoof in phishing attacks against your customers, which matters more than most marketing teams realize.

The order to ship these in (and what to verify at each step)

Don't ship all three at once. You will have no idea which change moved the needle, and you risk breaking live campaigns.

Step 1 — Inventory every service that sends as your domain. Marketing automation, transactional email, SDR tools, calendar systems, HR platforms, finance tools, the CEO's personal CRM, the agency you fired in 2022. If you are already doing list hygiene or CRM cleanup, the muscle is the same — you cannot fix what you have not mapped. How to Segment a Messy CRM Into a Revenue-Ready Database walks that mindset for the contact layer; treat the sending layer the same way.

Step 2 — Consolidate senders onto subdomains. Marketing on one, transactional on one, cold outbound on a third. Each gets its own clean SPF and DKIM.

Step 3 — Verify SPF and DKIM pass independently for every sender. Use MXToolbox, your ESP's built-in checker, or a paid tool like Valimail or dmarcian. Fix every fail before moving on.

Step 4 — Publish a DMARC record with `p=none` and enable aggregate reporting. Read the reports weekly for 2–4 weeks. Identify unknown senders. Get them authenticated or get them off your domain.

Step 5 — Move DMARC to `p=quarantine`, then to `p=reject` once reporting shows clean. Expect a 2–3 week monitoring cycle at each stage.

Throughout this process, watch your inbox placement rate, not just open rate. Open rate is noisy. Placement is the upstream signal. If placement climbs from 70% to 90% and opens still look flat, the issue is downstream — subject line, list quality, send time, the message itself. Lead Scoring for Small B2B Teams: How to Focus on the Leads That Actually Convert is what to read once you have confirmed placement is healthy and you want to fix the next layer.

Sources worth checking

If you are making DNS changes, use your sending platform's exact instructions first, then cross-check the fundamentals against primary references:

• –Google Workspace SPF setup guide
• –Gmail email sender guidelines
• –RFC 7208: Sender Policy Framework
• –RFC 7489: DMARC

What changes when these are right

The visible KPIs move. Open rates climb. Reply rates on cold outbound stabilize. Spam complaints drop. Your domain's sender reputation stops decaying.

The invisible things also change. Microsoft 365 stops throttling your transactional email. Gmail stops rewriting your subject lines. Sales replies stop going to the prospect's "Promotions" tab by default. Customer service replies land in the inbox instead of being silently filtered.

If your team is generating leads and they are reaching out across email — through your CRM, through a nurture, through a trade show follow-up — every one of those touches is gated by these three records. Fixing them is the highest-leverage deliverability work a B2B marketing team can ship, and it does not require a rebrand, a new ESP, or a six-month roadmap. It is a DNS change.

We do deliverability audits for B2B teams every week as part of our growth system work, and authentication is almost always the first fix. If you want us to look at your SPF, DKIM, and DMARC, your sending domain setup, and your overall inbox placement, book a free audit and we will show you exactly what is breaking and what to ship first.