← All articles

Stop Email Spoofing with SPF, DKIM and DMARC: A Step-by-Step Setup

28 August 2026

Stop Email Spoofing with SPF, DKIM and DMARC: A Step-by-Step Setup

The email protocol (SMTP) was designed without verifying who the sender is. By default, anyone can send a message that appears to come from your domain (“From: billing@yourcompany.com”). This is the root of business email compromise (BEC) and brand-impersonation attacks. SPF, DKIM and DMARC are three DNS-based controls that close this gap and are now effectively the industry standard.

What each control does

  • SPF (RFC 7208): Publishes, in a DNS TXT record, the list of servers authorised to send email for your domain. The receiver compares the sending IP against this list.
  • DKIM (RFC 6376): Adds a cryptographic signature to every outgoing message; the public key is published in DNS. The receiver verifies that the message is authorised and unaltered.
  • DMARC (RFC 7489): Aligns the SPF and DKIM results with the domain in the From header, sets a policy for what to do on failure, and sends you reports.

They work together: SPF and DKIM produce signals; DMARC turns those signals into policy and visibility.

Step 1 — Inventory your senders

The most common mistake is publishing incomplete records and pushing your own legitimate mail to spam. First, list every source that sends on behalf of your domain: corporate email (Google Workspace, Microsoft 365), marketing tools, billing/CRM systems, application email from your servers.

Step 2 — Publish SPF

Add authorised senders to your root TXT record:

v=spf1 include:_spf.google.com include:provider.example -all
  • include: pulls in the provider’s own SPF record.
  • The final qualifier matters: -all (hardfail — “reject anything not listed”) is the secure target; ~all (softfail) is a safe starting point.
  • Note: SPF has a 10 DNS lookup limit; too many includes invalidate the record.

Step 3 — Enable DKIM

DKIM signing is enabled in your email provider’s console. The console gives you a selector and a public key, which you publish in DNS as selector._domainkey.yourdomain.com; then you activate signing.

Step 4 — Start DMARC in monitoring mode

Starting with a strict policy is risky. Begin with p=none, which blocks nothing and only collects reports. Add a TXT record on the _dmarc subdomain:

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

The rua aggregate reports show who is sending as your domain — both legitimate and spoofed.

Step 5 — Read reports, then tighten

Review reports for a few weeks, confirm that all legitimate senders pass SPF/DKIM, then gradually tighten the policy: p=quarantine → p=reject (the end goal).

Common mistakes

  • Alignment ignored: SPF/DKIM may pass technically, but if the validated domain does not align with the From domain, DMARC fails.
  • Multiple SPF records: A domain must have only one SPF TXT record.
  • Getting stuck at p=none: Monitoring mode is a transition step; a DMARC that never reaches reject does not actually stop spoofing.

Summary

SPF authorises the sender, DKIM protects message integrity, and DMARC aligns both while adding policy and visibility. The correct order is: inventory → SPF → DKIM → DMARC (p=none) → read reports → quarantine → reject.

Sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), dmarc.org.

Want to see whether your SPF/DKIM/DMARC records are set up correctly? CyberTestify’s external surface scan checks these records and common misconfigurations for you.