Email Authentication: How SPF, DKIM, and DMARC Work Together

The email spoofing problem

Email was designed in the 1970s without authentication. By default, anyone can send an email claiming to be from any address. There is nothing in the base protocol that verifies the sender is who they claim to be.

This makes email spoofing trivially easy. Attackers exploit it for phishing, business email compromise (BEC), and brand impersonation. The FBI reports BEC attacks caused over $2.9 billion in losses in 2023 alone.

Three protocols fix this: SPF, DKIM, and DMARC. Each serves a different purpose, and all three are needed for complete protection.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and mail servers authorized to send email for your domain.

When a receiving server gets an email from your domain, it checks your SPF record. If the sending server's IP is not on the list, SPF fails.

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

**Limitation:** SPF checks the envelope sender (Return-Path), not the From header that users see. An attacker can spoof the visible From address while using a different envelope sender to pass SPF.

DKIM: cryptographic proof

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing email. The sending server signs the message with a private key, and publishes the corresponding public key in DNS.

The receiving server retrieves the public key, verifies the signature, and confirms the email has not been tampered with in transit.

**Limitation:** DKIM proves the email was signed by the claimed domain, but it does not tell the receiving server what to do if the signature is missing or fails.

DMARC: the policy layer

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and adds a policy. It tells receiving servers: "If an email claims to be from my domain and fails both SPF and DKIM alignment, here is what to do with it."

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

DMARC policies:

DMARC also requires **alignment**: the domain in the From header must match the domain checked by SPF or DKIM. This closes the loophole that SPF alone leaves open.

How they work together

1. Email arrives claiming to be from you@example.com

2. Receiving server checks **SPF** — is the sending IP authorized?

3. Receiving server checks **DKIM** — is the signature valid?

4. Receiving server checks **DMARC** — do SPF or DKIM pass with alignment? If not, follow the DMARC policy.

All three must be configured correctly. SPF without DMARC is incomplete. DKIM without DMARC is incomplete. DMARC without SPF and DKIM has nothing to evaluate.

Implementation roadmap

Week 1: Audit

Use [CQwerty Shield's DMARC Checker](/tools/dmarc-checker) and [SPF Checker](/tools/spf-checker) to see your current state. Identify all services that send email on your behalf (Google Workspace, Mailchimp, SendGrid, HubSpot, etc.).

Week 2: Configure SPF and DKIM

Add all legitimate senders to your SPF record. Enable DKIM signing for each sending service. Most providers have documentation for this.

Week 3: Deploy DMARC in monitor mode

Add a DMARC record with p=none and a reporting address. Monitor the reports for 2-4 weeks to identify any legitimate senders you missed.

Week 4+: Tighten the policy

Once reports show clean results, move to p=quarantine, then p=reject.

Common mistakes

[Check your email authentication now](/tools/dmarc-checker)