SPF, DKIM and DMARC Explained — and How to Stop Email Spoofing

If your domain has no DMARC policy — or a DMARC policy set to p=none — anyone on the internet can send email that appears to come from you. Your customers see billing@yourcompany.com in the From line, and nothing in the message tells them it's a forgery. This is how most phishing and business-email-compromise attacks start.

The fix is three DNS records: SPF, DKIM and DMARC. They work together, and getting them right is a genuinely high-leverage hour of work. Here's how each one works and how to deploy them without torching your legitimate email.

SPF: which servers may send as you

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers allowed to send email for your domain. When a receiving server gets a message claiming to be from you, it checks whether the sending server's IP is on your SPF list.

A minimal SPF record for a domain that sends through Google Workspace:

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

• include:_spf.google.com pulls in Google's authorised servers.
• ~all (soft-fail) means "anything not listed is suspicious." Use -all (hard-fail) once you're confident the list is complete.

Two rules people break: you may only have one SPF record per domain, and SPF is limited to 10 DNS lookups — pile on too many include: mechanisms and SPF silently breaks.

DKIM: a cryptographic signature

SPF proves the sending server is authorised. DKIM (DomainKeys Identified Mail) proves the message content wasn't tampered with. Your mail server signs each outgoing message with a private key; the matching public key lives in DNS. The receiver verifies the signature.

A DKIM record is published at a selector subdomain, e.g. selector1._domainkey.yourdomain.com:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

You don't usually write this by hand — your email provider (Google Workspace, Microsoft 365, Postmark, SES, etc.) generates the key pair and gives you the record to publish. The critical part is actually enabling signing in the provider dashboard after you publish the record; a published key that isn't signing anything does nothing.

DMARC: the policy that ties it together

Here's the piece most people miss. SPF and DKIM on their own don't tell receivers what to do when a message fails. DMARC (Domain-based Message Authentication, Reporting & Conformance) does two things:

1. It sets a policy — none, quarantine, or reject — for messages that fail authentication.
2. It requests reports, so you can see who's sending as your domain.

A DMARC record lives at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

DMARC also enforces alignment: it's not enough for SPF or DKIM to pass — the domain they authenticate must match the domain in the visible From address. This is what actually stops spoofing, because attackers can pass SPF for their own domain but can't align it to yours.

Why p=none means you're still spoofable

This is the single most important sentence in this article: p=none provides no protection. It tells receivers "authenticate my mail, send me reports, but deliver failures anyway." It's a monitoring mode — useful for the first couple of weeks so you can see your legitimate senders — but if you leave it there, an attacker's forged mail still lands in the inbox.

Protection only begins at p=quarantine (failures go to spam) and is complete at p=reject (failures are refused outright). A huge fraction of domains publish DMARC, feel protected, and never move past p=none.

Rolling out enforcement without breaking deliverability

Do it in stages, and don't skip the reporting phase:

1. Publish SPF and DKIM first, and confirm your legitimate mail passes both.
2. Publish DMARC at p=none with a rua= reporting address. Collect aggregate reports for one to two weeks.
3. Read the reports. They'll reveal every service sending as you — your CRM, your invoicing tool, your marketing platform — many of which you forgot about. Add each legitimate one to SPF and enable DKIM for it.
4. Move to p=quarantine, optionally with pct=25 to apply the policy to only a quarter of mail at first, then ramp to 100%.
5. Move to p=reject once quarantine is clean.

Rushing to p=reject before step 3 is how teams accidentally send their own password-reset and invoice emails to spam.

The hard part is staying protected

Email authentication isn't set-and-forget. Selectors rotate, a new SaaS tool starts sending on your behalf, someone "simplifies" the SPF record and breaks alignment, or a well-meaning admin drops your DMARC policy back to p=none. Any of these silently reopens the spoofing hole — and you won't know until a customer forwards you a phishing email.

Standalone DMARC monitoring products charge $20–90/month for exactly this. CompleteStatus bundles continuous SPF/DKIM/DMARC monitoring — including flagging p=none and alerting on record changes — into every plan, free tier included.

Check your domain right now with the free DMARC / SPF / DKIM checker, or start monitoring free so you're alerted the moment your email authentication weakens.