DMARC Explained: How to Stop Email Spoofing and Protect Your Domain

The email trust problem

Email was designed in 1971 with no concept of authentication. The "From" field in an email is entirely self-reported — any server can claim to send email from any address. This is why phishing attacks are so common: sending a spoofed email from no-reply@yourbank.com requires no access to that domain whatsoever.

Three DNS-based standards were developed to fix this: SPF, DKIM, and DMARC. They work as a layered system — each one adds a different verification check, and DMARC ties them together with enforcement policy.

SPF: Sender Policy Framework

SPF lets you publish a list of authorized mail servers for your domain in DNS. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record to see if the sending server is on the allowed list.

A basic SPF record looks like this:

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

• v=spf1 — declares the record type
• include: — authorizes all servers listed in another domain's SPF record
• ~all — soft fail: mark emails from unlisted servers as suspicious but don't reject
• -all — hard fail: reject emails from unlisted servers outright

SPF's limitation: it checks the envelope sender (the technical return-path address), not the "From" address the user sees. Spoofers exploit this gap by using a different envelope sender while displaying a fake "From" address. That's where DKIM helps.

DKIM: DomainKeys Identified Mail

DKIM uses public-key cryptography to prove an email wasn't tampered with in transit and that it was sent by a server authorized by the domain owner.

When your mail server sends an email, it generates a cryptographic signature of the message headers and body using a private key you control. That signature is added as a header. The receiving server looks up your public key in DNS and uses it to verify the signature.

A DKIM DNS record looks like:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

If an email is intercepted and modified after signing, the signature check fails and the receiving server knows the message was tampered with. DKIM also survives forwarding — unlike SPF, which breaks when a server forwards email from a different IP.

DMARC: the enforcement layer

SPF and DKIM independently can fail or be bypassed. DMARC (Domain-based Message Authentication, Reporting, and Conformance) adds two critical things:

1. Alignment — requires that SPF or DKIM aligns with the "From" header domain the user actually sees, closing the spoofing gap
2. Policy enforcement — tells receiving servers what to do with emails that fail: nothing, quarantine them, or reject them outright

A DMARC record is published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s

DMARC reporting

The rua tag in your DMARC record specifies an email address where aggregate XML reports are sent daily by receiving mail servers. These reports show:

• Which servers sent email claiming to be from your domain
• Whether each message passed or failed SPF and DKIM
• How many messages each server sent
• What policy was applied

Start at p=none, collect a week of reports, confirm all your legitimate senders (email marketing, CRM, support tools) are passing, then move to p=quarantine and eventually p=reject.

Setting up DMARC: step by step

1. Publish an SPF record — add a TXT record at your root domain listing all authorized sending servers. Check with your email provider (Google Workspace, Microsoft 365, SendGrid, etc.) for their specific include directives.
2. Enable DKIM signing — your email provider will give you a public key to publish as a TXT DNS record. This is usually done in the provider's admin panel with a guided setup.
3. Publish a DMARC record at _dmarc.yourdomain.com — start with p=none and a rua address for reports.
4. Review reports for 1–2 weeks — identify any legitimate senders failing DMARC and fix their SPF/DKIM configuration.
5. Escalate to p=quarantine — monitor for false positives (legitimate mail going to spam) for another week.
6. Move to p=reject — your domain is now fully protected from spoofing.

Common DMARC mistakes

• Jumping straight to p=reject without reviewing reports first. If you have forgotten sending services (old CRM, invoice tool, monitoring alerts), they'll stop delivering silently.
• Not covering subdomains — add sp=reject to your DMARC record to apply policy to subdomains too, or spoofers will use mail.yourdomain.com instead.
• SPF record with too many DNS lookups — the SPF spec limits records to 10 DNS lookups. Exceeding this causes SPF to fail. Flatten your record if you have many include: directives.
• Ignoring reports — DMARC reports tell you about active spoofing attempts. Review them weekly, especially in the first month.

How to verify DMARC in email headers

When you receive an email, the raw headers contain authentication results. In Gmail, click the three-dot menu → "Show original" to see the full headers. Look for lines like:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=selector ...;
  spf=pass (google.com: domain of sender@example.com designates ...) smtp.mailfrom=sender@example.com;
  dmarc=pass (p=REJECT sp=REJECT) header.from=example.com;

Use our Email Header Analyzer to parse raw email headers instantly — it highlights SPF, DKIM, and DMARC results along with the full message routing trace.