SPF, DKIM & DMARC explained — without the sysadmin jargon

The short version

Email was built without a way to prove who sent a message. SPF, DKIM and DMARC are the three standards that bolt identity onto it. You publish them as DNS records on your sending domain, and receiving servers — Gmail, Outlook, every corporate mail system — read them to decide whether to trust your mail.

Here is the one-line version of each:

• SPF says which servers are allowed to send mail for your domain.
• DKIM attaches a cryptographic signature that proves the message was not forged or altered.
• DMARC ties the first two to the domain your reader actually sees, and tells receivers what to do when a check fails.

If you run B2B outbound, you do not need to become a deliverability engineer. You need to know what these records do, recognize a broken one, and make sure all three are published and enforced. That is the whole job.

SPF — who is allowed to send

The problem it solves: anyone on the internet can type your domain into the "from" envelope of a message. SPF (Sender Policy Framework) is your published list of the mail servers you actually authorize, so a receiver can reject the ones you didn't.

SPF is a single TXT record published at your domain's apex (the root, e.g. yourcompany.com). A real one looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Reading it left to right: v=spf1 marks the version; each include: pulls in the authorized servers for a sending platform (here, Google Workspace and SendGrid); and the final ~all is the catch-all rule — ~all means "soft-fail anything else" while -all means "hard-fail anything else." Every B2B domain we tested had SPF, so this is rarely the weak link — but a sloppy SPF record that forgets to authorize your outbound platform will quietly fail.

SPF's blind spot: it checks the hidden envelope sender, not the From address your reader sees. That gap is exactly what DMARC closes later.

DKIM — proof the message wasn't tampered with

The problem it solves: SPF only vouches for the sending server, not the message itself. DKIM (DomainKeys Identified Mail) cryptographically signs each message with a private key, so the receiver can verify nothing was forged or altered in transit.

You publish the matching public key in DNS at a special name: selector._domainkey.yourcompany.com. The "selector" is just a label you choose so you can rotate keys. A published DKIM record looks like this:

s1._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

The p= value is the public key. Receivers use it to check the signature your mail server stamped on the outgoing message. One trap worth knowing: an empty p= value means the key has been revoked — any mail signed with that selector will fail DKIM until a valid key is republished. DKIM is the most commonly missing piece we found: 18.5% of the B2B domains we checked had no detectable DKIM at all.

DMARC — the policy that ties it together

The problem it solves: SPF and DKIM can both pass on a server that has nothing to do with the brand in the From line. DMARC (Domain-based Message Authentication, Reporting & Conformance) fixes that by demanding alignment, and by telling receivers what to do when alignment fails.

DMARC is a TXT record published at _dmarc.yourcompany.com. A real one looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; adkim=s; aspf=s

The key tag is p=, the policy — your instruction to receiving servers:

• p=none — monitor only. The receiver does nothing; you just collect reports.
• p=quarantine — send failing mail to the spam folder.
• p=reject — bounce failing mail outright. This is full enforcement.

The rua= tag is where aggregate reports get sent, so you can see who is sending mail in your name before you tighten the policy.

How they actually work together: alignment

This is the part most explainers skip, and it is the part that matters. DMARC does not pass just because SPF or DKIM passed. It passes only when at least one of them passes and aligns with the domain in the visible From address.

Alignment simply means: the domain that authenticated is the same domain your reader sees in the From line.

• SPF alignment — the domain SPF checked (the envelope sender) matches your From domain.
• DKIM alignment — the domain in the DKIM signature matches your From domain.

So a message can have a perfectly valid SPF pass and still fail DMARC — if that SPF pass belonged to some shared sending platform's domain instead of yours. DMARC's whole job is to say: prove it with my domain, not someone else's. You only need one of the two to align, which is why publishing both SPF and DKIM gives you a safety margin.

Across the 130 B2B domains we tested, about half had at least one of these gaps — a missing DKIM, a misaligned setup, or a DMARC record that exists but isn't enforced.

The practical takeaway: publish all three, then enforce

The standards are only useful when they are all present and the policy actually does something. The most common failure we see is not a missing record — it is a DMARC record stuck on monitor-only. Roughly 37% of the domains we checked had DMARC published but set to p=none, which protects nothing. A further 5.4% had no DMARC at all.

Your checklist is short:

• Publish SPF and confirm it authorizes every platform you actually send from.
• Publish DKIM with a valid, non-empty p= public key for each selector.
• Publish DMARC, start at p=none only to read the reports, then move to p=quarantine and finally p=reject.

This is not optional housekeeping anymore. Google and Yahoo's 2024 bulk-sender rules require SPF, DKIM, DMARC, one-click unsubscribe, and a spam-complaint rate under 0.3% for anyone sending at volume. If you run outbound and your DMARC is still on p=none, you are sending on borrowed time. The full data and methodology behind these numbers is at our 2026 B2B deliverability benchmark.

How MeetForge fits

We run B2B outbound end-to-end — including the SPF, DKIM and DMARC setup that has to be right before a single email goes out. You don't manage records or chase deliverability; we do, as part of the work. And you only pay for qualified conversations, billed on a public ledger. No pressure either way: the explainer above stands on its own.