SPF, DKIM and DMARC Explained: A Plain-English Guide

SPF, DKIM and DMARC at a glance

All three are DNS TXT records on your domain. Nothing gets installed on laptops or mail clients: the receiving server looks them up to decide how far to trust a message.

Think of SPF as the guest list at the door, DKIM as a tamper-evident seal, and DMARC as your standing instruction to the receiving mail room, plus a regular report on what turned up.

SPF: which servers may send for you

A typical small-business record on Microsoft 365, with a web server sending contact-form mail and an online store using a transactional email service:

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 include:spf.transactional.example -all"

• v=spf1 must come first.
• include: hands off to another domain's list. Microsoft 365 needs include:spf.protection.outlook.com, Google Workspace include:_spf.google.com, and most sending platforms give you their own.
• ip4: and ip6: authorise specific addresses, such as your web server.
• The final term covers everyone else: -all means “not authorised”, ~all “probably not authorised”. ?all and +all protect nothing.

Two limits matter: SPF checks the envelope sender, not the From address people see, and it breaks on auto-forwarding, because the forwarding server isn't on your list.

DKIM: a signature on every message

The sending server signs each message with a private key. The receiver reads the signing domain (d=) and selector (s=), fetches the public key from DNS and checks nothing was altered in transit:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

• The sending service (mailbox provider, newsletter tool, helpdesk) generates the key; you publish the record. Each service has its own selector, so several keys can coexist on one domain.
• Gmail requires keys of at least 1024 bits and recommends 2048. A 2048-bit key exceeds the 255-character limit of a single TXT string; if your DNS panel rejects it, split it into several quoted strings in one record, which receivers join back together.
• DKIM usually survives forwarding, but breaks when content is rewritten, for example by a mailing list that adds a footer.

DMARC and alignment: the part most setups miss

A scammer can send from their own server, pass SPF for their own domain and still put yours in From. DMARC closes that gap: a message passes only if SPF or DKIM passes and is aligned with the From domain. Under relaxed alignment, the default, the same organisational domain is enough, so mail.example.com aligns with example.com.

This is where setups fail quietly. A marketing platform using its own bounce domain passes SPF for its domain, not yours, so DMARC still fails. Enable DKIM signing with your domain on that platform, or a custom Return-Path on your subdomain. Your first DMARC record should only monitor:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• p= is the policy: none (monitor only), quarantine (usually the spam folder) or reject.
• rua= is where aggregate reports go: periodic XML files, typically daily, showing who sent as your domain, from which IPs, with what result. No rua, no reports. Use a dedicated mailbox or a report-processing service.
• sp= sets a subdomain policy; adkim= and aspf= pick relaxed (r, default) or strict (s) alignment.

Common mistakes that break authentication

1. Two SPF records on one domain, usually because whoever set up the newsletter added a record instead of editing the existing one. Under RFC 7208 that returns permerror, a permanent failure. Merge everything into one record.
2. More than 10 DNS lookups. include, a, mx, ptr, exists and redirect each count, and nested includes add theirs; ip4, ip6 and all don't. Past 10, SPF returns permerror. Fixes: drop retired services, move bulk mail to a subdomain, and swap an include for ip4/ip6 ranges only when the vendor's IPs are stable and documented.
3. The ptr mechanism, which RFC 7208 says should not be published, and syntax slips such as a trailing dot or include= instead of include:.
4. Forgotten senders: invoicing app, online store, CRM, helpdesk. Each must be in SPF or, better, sign with DKIM as your domain.
5. Contact forms that send as the visitor. If a WordPress form puts the visitor's Gmail address in From, the message fails DMARC, and Google explicitly asks senders not to impersonate Gmail From headers. Send from your own domain and put the visitor in Reply-To.
6. Jumping straight to p=reject and losing legitimate mail nobody had inventoried.
7. Parked domains with no records. Microsoft recommends v=spf1 -all; add DMARC at p=reject and they become far less useful for spoofing.

A staged DMARC rollout: p=none to p=reject

RFC 9989 advises publishing p=none for at least a month, then p=quarantine for as long again before p=reject, comparing reports along the way. Treat that as a floor: many third-party senders or seasonal campaigns call for more time.

1. Prepare: one SPF record under 10 lookups and DKIM on every sending service. Google suggests waiting 48 hours after SPF and DKIM before publishing DMARC.
2. Monitor at p=none for at least four weeks and list your legitimate sources. Every unknown IP is a forgotten service or someone using your domain.
3. Fix DKIM or alignment for each legitimate source that fails.
4. Move to p=quarantine and keep reading reports and feedback from colleagues and customers.
5. Move to p=reject: receivers that enforce DMARC refuse unauthenticated mail using your domain in From.
6. Maintain: configure each new sending service before it goes live, not after the first bounces.

Gmail, Yahoo and Outlook.com sender requirements

Gmail's rules apply to mail sent to personal accounts (@gmail.com and @googlemail.com), not to Google Workspace mailboxes. Here's the picture from the official pages, checked in October 2026:

Two details matter for agencies. Gmail counts your primary domain and its subdomains together, and once you cross the threshold you stay a bulk sender with no expiry. And it's about volume, not company size: one campaign to more than 5,000 Gmail addresses is enough. Google's target spam rate is below 0.1%.

How to check your setup

# SPF: exactly one line starting with v=spf1
dig +short TXT example.com

# DMARC
dig +short TXT _dmarc.example.com

# DKIM: the selector is in your provider's settings or the signature (s=)
dig +short TXT s1._domainkey.example.com

# Windows
nslookup -type=TXT _dmarc.example.com

• Send a test to a Gmail mailbox and choose More > Show original: the Authentication-Results header should show spf=pass, dkim=pass and dmarc=pass.
• Repeat from every service that sends as your domain: website, newsletter tool, invoicing app, online store.
• Check the passing DKIM signature is for your domain (header.i=@example.com), not only the platform's.
• Verify your domain in Google Postmaster Tools to track spam rate, authentication and delivery errors at Gmail.
• Review DMARC reports weekly while monitoring, then at least monthly.
• Keep a shared list of every service sending for the domain and its DKIM selector.

If you manage mail for a portfolio of client domains and would like us to review the DNS records while you set up each service, the lubemy support team can work through it with you.