Step-by-Step: Configuring DMARC, SPF, and DKIM to Stop Email Spoofing

Why SPF, DKIM, and DMARC Matter for Stopping Email Spoofing

Email was never designed with sender verification in mind. The core SMTP protocol lets anyone put any "From" address on a message, which is why domain spoofing remains one of the cheapest and most effective tricks in a phishing attacker’s playbook. A criminal doesn’t need to breach your network — they just need to send an email that *looks* like it came from your CEO, your payroll provider, or your own helpdesk.

This is the mechanism behind most Business Email Compromise (BEC) attacks: an employee receives a message that appears to come from a trusted internal or partner domain, and acts on it — wiring funds, resetting credentials, or opening an attachment. The FBI’s Internet Crime Complaint Center (IC3) has consistently flagged BEC as one of the most financially damaging cybercrime categories reported each year, precisely because it doesn’t need malware — it needs trust, and spoofed sender identity is how that trust is manufactured.

Before locking down your sending infrastructure, it’s also worth checking whether your email is already public without you knowing — exposed metadata and reused addresses often make spoofing even easier for attackers.

Three DNS-based standards close this gap:

• SPF (Sender Policy Framework) — declares which mail servers are allowed to send mail for your domain.
• DKIM (DomainKeys Identified Mail) — cryptographically signs outgoing mail so recipients can verify it wasn’t altered and really came from an authorized signer.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) — tells receiving mail servers what to do when SPF or DKIM fail, and sends you reports showing who is sending mail using your domain.

None of these are optional add-ons anymore. Major receivers (Google, Yahoo, Microsoft) now require DMARC alignment for bulk senders, and a domain without any of these records is significantly easier to spoof convincingly. This guide shows you how to configure DMARC, SPF, and DKIM step by step, in the right order, with verification at each stage.

Prerequisites for Configuring SPF, DKIM, and DMARC

Before starting, make sure you have:

• DNS management access for the domain in question (registrar panel, Cloudflare, Route 53, Azure DNS, etc.) with the ability to add TXT and CNAME records.
• A complete inventory of everything that sends email as your domain — your main mail provider (Google Workspace, Microsoft 365, on-prem Exchange), plus any third-party services: marketing platforms (Mailchimp, HubSpot), transactional mail (SendGrid, Amazon SES, Mailgun), helpdesk tools (Zendesk, Freshdesk), and CRM/ERP systems that send on your behalf. Missing one of these is the #1 cause of broken mail delivery during this process.
• Admin access to your mail provider’s console to enable DKIM signing and retrieve selector keys.
• Command-line access to dig or nslookup (or an equivalent online DNS lookup tool) for verification.
• A test mailbox on an external provider (e.g., a personal Gmail account) to inspect message headers.
• Roughly 2–5 weeks of calendar time. This is not a one-afternoon task if done safely — DMARC enforcement should be rolled out gradually, which is covered in Steps 7–10.

If you run your own mail server on Linux rather than a hosted provider, this guide pairs well with hardening SSH on Linux servers, since DNS and mail server access are common targets once spoofing defenses go up and attackers look for other ways in.

Step-by-Step: Configuring SPF, DKIM, and DMARC

Step 1: Audit your current DNS records

Check what’s already published before changing anything.

dig TXT example.com +short
dig TXT _dmarc.example.com +short

What this does: Lists any existing SPF record (a TXT record starting with v=spf1) and any existing DMARC record. Verify: You should see either nothing (a clean slate) or an existing record you need to account for — never leave two SPF records on the same domain; DNS allows it, but mail servers will treat it as invalid.

Step 2: Build your sender inventory

List every system that sends mail using your domain’s "From" address. For each one, note whether it supports SPF (an IP range or include mechanism) and DKIM signing (most modern platforms do). Example inventory for a mid-size company:

Google Workspace     - SPF include, native DKIM
SendGrid             - SPF include, native DKIM
Mailchimp            - SPF include, native DKIM
On-prem app server   - static IP, needs manual SPF entry + custom DKIM setup

What this does: Prevents the single most common outage in this process — legitimate mail (newsletters, invoices, transactional receipts) failing authentication because a sender was forgotten.

Step 3: Publish your SPF record

Combine every sender into one SPF TXT record at the domain apex.

Name: example.com
Type: TXT
Value: v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ip4:203.0.113.10 -all

What this does: include: mechanisms authorize mail relayed through each provider’s infrastructure; ip4: authorizes a specific server you control. -all is a hard fail, instructing receivers to reject mail from any source not explicitly listed. Verify:

dig TXT example.com +short

Confirm only one SPF record exists and all required senders are represented.

Step 4: Check the SPF lookup limit

SPF evaluation is capped at 10 DNS lookups (RFC 7208). Each include, a, mx, ptr, or exists mechanism counts.

# Use an SPF flattening/validation tool, or manually count mechanisms
dig TXT _spf.google.com +short

What this does: Checks nested includes you don’t control directly (e.g., Google’s own SPF record may itself contain further includes). Verify: If your total exceeds 10 lookups, mail servers will return a permerror and SPF will silently fail for everyone — consolidate or flatten includes before moving on.

Step 5: Enable DKIM signing at your mail provider

In Google Workspace Admin console: Apps → Google Workspace → Gmail → Authenticate email → generate a new DKIM key (2048-bit recommended). In Microsoft 365: use Enable-DkimSigningConfig via Exchange Online PowerShell.

New-DkimSigningConfig -DomainName example.com -Enabled $true

What this does: Instructs the provider to cryptographically sign every outgoing message with a private key and generates the public key you’ll publish in DNS. Verify: The provider’s console will display a pending or active DKIM selector once the DNS record below is published.

Step 6: Publish the DKIM TXT record

Each provider gives you a selector name and a public key.

Name: google._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (public key supplied by provider)

What this does: Publishes the public key at a predictable location (selector._domainkey.yourdomain.com) so receiving servers can verify the signature on incoming mail. Verify:

dig TXT google._domainkey.example.com +short

Then send a test email to your external test mailbox, open "Show original" (Gmail) and confirm:

DKIM: 'PASS' with domain example.com

Step 7: Publish DMARC in monitor-only mode

Do not jump to enforcement. Start with p=none to collect data safely.

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

What this does: p=none takes no action on failing mail but instructs participating receivers to send daily aggregate XML reports to the rua address, showing every IP sending mail as your domain and whether it passed SPF/DKIM alignment. fo=1 requests forensic detail on any failure. Verify:

dig TXT _dmarc.example.com +short

Within 24–48 hours, reports should start arriving at the rua mailbox (use a dedicated inbox or a free DMARC report parser — raw XML is not human-readable).

Step 8: Analyze reports for 2–4 weeks

Review aggregate reports for any legitimate source failing alignment. Common findings: an old marketing tool not in your original inventory, or a forwarding service that breaks SPF.

What this does: Confirms every real sender is authenticated before you start blocking failures. Pairing DMARC visibility with network-level monitoring — such as deploying Suricata IDS/IPS for real-time threat detection — gives you a clearer picture of spoofing attempts that get through other layers. Verify: You should see 100% of *known, legitimate* sending IPs passing SPF or DKIM alignment. If not, go back to Step 3 or Step 6 and add the missing source.

Step 9: Move to quarantine

Once reports are clean, escalate enforcement gradually.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

What this does: Sends 25% of failing mail to spam/quarantine instead of the inbox, limiting blast radius if something was missed. Verify: Monitor reports for a further 1–2 weeks, then increase pct to 50, then 100.

Step 10: Enforce with reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s

What this does: Instructs all compliant receivers to reject any mail failing DMARC alignment outright — this is full anti-spoofing protection. adkim=s/aspf=s enforce strict domain alignment (exact match, not subdomain). Verify: Use an external testing tool (see Free Resources) to confirm the domain now reports "DMARC: enforced" and send a spoofed test (from a tool like mail-tester.com) to confirm it is rejected, not delivered.

Common SPF, DKIM, and DMARC Pitfalls and Mistakes

• Multiple SPF records on one domain. DNS allows it; SPF spec does not. Receivers treat it as a permanent error and SPF fails entirely. Always merge into a single record.
• Exceeding the 10-lookup SPF limit. Nested includes from third parties add up fast. Flatten or remove unused includes.
• Forgetting a sending system. Marketing tools, CRMs, and ticketing systems are the most commonly missed senders — this is why Step 2’s inventory matters.
• Jumping straight to p=reject. Skipping the monitor and quarantine phases can silently block legitimate mail — invoices, password resets, partner communications — with no warning.
• DKIM/SPF domain misalignment. DMARC requires the signing/sending domain to align with the "From" header domain. A third-party sender using its own domain for SPF but your domain in "From" will fail alignment even if SPF itself passes — check aspf/adkim settings and use subdomain delegation where needed.
• Not rotating DKIM keys. Treat DKIM private keys like any credential; rotate periodically and immediately if a mail platform is compromised. For broader server-hardening practices that reduce credential exposure generally, see hardening a Linux server with CIS Benchmarks and Lynis.
• Ignoring mail forwarding. Forwarded mail often breaks SPF (the forwarding server isn’t in your SPF record) even though DKIM — which travels with the message — may still pass. This is why DMARC evaluates SPF *or* DKIM alignment, not strictly both.

Troubleshooting SPF, DKIM, and DMARC Failures

Symptom: SPF lookup returns permerror: too many DNS lookups

Count every include/a/mx/ptr/exists mechanism across your record and any nested includes. Reduce to 10 or fewer by removing unused includes or replacing a/mx mechanisms with static ip4/ip6 entries.

Symptom: DKIM header shows dkim=none or dkim=fail in message headers

Confirm the DKIM TXT record is published at the exact selector path (selector._domainkey.yourdomain.com) and that signing is actually enabled in the provider console — publishing the DNS record alone does not activate signing.

Symptom: DMARC aggregate reports show a known legitimate IP failing both SPF and DKIM

That sender isn’t in your SPF include list and isn’t configured to DKIM-sign with your domain. Add it to your sender inventory (Step 2) and configure authentication through that platform’s settings before enforcing quarantine or reject.

Symptom: No DMARC reports arriving at all

Confirm the rua mailbox exists and isn’t silently dropping incoming mail (check its own spam filtering). Some receivers only send reports for domains sending meaningful mail volume — a low-volume domain may receive sparse reports.

Symptom: Legitimate newsletter/forwarded mail disappears after enabling p=reject

Check whether the sending platform supports DKIM signing (preferred, since it survives forwarding) rather than relying solely on SPF. If a specific legitimate source cannot be fixed quickly, temporarily revert to p=quarantine; pct=50 while resolving it.

Symptom: dig shows no TXT record at all after publishing

DNS propagation can take minutes to hours depending on your provider and existing TTL values. Confirm the record was saved correctly in the DNS console, then wait out the TTL before re-checking.

Free SPF, DKIM, and DMARC Resources and Tools

• dmarc.org — the official DMARC specification site, overview, and deployment guidance.
• Google Workspace Admin Help – Authenticate email with SPF, DKIM, DMARC — official step-by-step setup for Google Workspace domains.
• NIST SP 800-177 Rev. 1, Trustworthy Email — federal guidance covering SPF, DKIM, DMARC, and STARTTLS implementation.
• CISA Binding Operational Directive 18-01 — background on why DMARC enforcement became a baseline requirement for federal domains, useful context for any organization.
• MXToolbox SPF/DKIM/DMARC Lookup Tools — free tools to validate live DNS records and diagnose alignment issues.

Key Takeaways

SPF, DKIM, and DMARC work together, not independently — publishing only an SPF record, or jumping straight to a DMARC reject policy without monitoring first, leaves gaps that attackers exploit or breaks legitimate mail delivery. The safe sequence is: inventory every sender, publish SPF and DKIM, launch DMARC in p=none monitoring mode, review reports for several weeks, then escalate gradually to quarantine and finally reject.

Pair this rollout with conducting your first internal vulnerability assessment to confirm there are no other authentication or exposure gaps across your mail and DNS infrastructure.

Next step: If your domain currently has no DMARC record, start today with Step 1 — run the dig audit and build your sender inventory. That single step determines whether the rest of this rollout goes smoothly or causes a mail outage.