SPF, DKIM and DMARC explained: why email gets rejected

SPF authorises sending systems, DKIM signs messages and DMARC checks alignment with the visible sender domain. Inventory legitimate senders, monitor results and tighten policy gradually after correcting alignment.

Three mechanisms with different responsibilities

SPF publishes which systems may send for a domain and is checked against the technical Envelope-From domain. DKIM adds a cryptographic signature whose public key is published in DNS. DMARC connects authentication to the visible From domain and publishes a requested policy for failures.

A message passes DMARC when at least one of SPF or DKIM succeeds and that authenticated domain aligns with the visible sender domain. Alignment prevents an attacker from using an unrelated visible sender merely because they control a different authenticated sending domain.

Read these illustrative DNS records

These example.com records illustrate syntax rather than a configuration to copy blindly. The abbreviated DKIM key is not a working key. Actual records must match the authorised services and keys for the domain.

SPF: example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all"
DKIM: default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
DMARC: _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
p=none requests monitoring without a DMARC-based quarantine or rejection policy; p=quarantine requests suspicious handling; p=reject requests rejection.

Do not set reject without checking senders

A controlled rollout commonly begins with p=none and a reporting mailbox. Reports reveal legitimate sources, forgotten newsletter systems and abuse. Correct sources and DKIM setup, then introduce quarantine or reject gradually, including a limited percentage where appropriate. Tighten only after legitimate traffic aligns reliably.

Publish one SPF record per domain and respect its DNS-lookup limit. Long include chains are an operating risk. Use adequately strong DKIM keys and plan rotation. Subdomains, forwarding and third-party senders require an intentional design instead of isolated DNS changes. Multiple SPF records, incorrect includes and missing alignment are common failures.

Authentication supports trust but is not a spam filter

SPF, DKIM and DMARC improve the basis for recipient trust. Authentication works alongside consistent sending patterns, maintained lists and low complaint rates. Passing checks does not guarantee inbox placement, while incorrect setup can seriously disrupt legitimate mail.

Monitor DNS changes, DKIM signatures and DMARC reports. A new sending service should enter production only after testing the sender domain, Return-Path, DKIM and bounces. An invalid or absent signature requires investigation in context rather than assuming every message without DKIM has necessarily been altered.

Practical checklist

01
Inventory legitimate sending sources and sender domains.
02
Consolidate SPF into one record and check DNS lookups.
03
Enable DKIM for every sending service and plan rotation.
04
Start DMARC reporting, inspect reports and fix alignment.
05
Increase policy progressively toward quarantine and reject.

Frequently asked questions

Is SPF sufficient on its own?

No. Forwarding can break SPF, and without DMARC alignment it does not adequately protect the visible From address. DKIM and DMARC supply complementary properties.

What does p=none mean?

Recipients are not asked to quarantine or reject based on DMARC policy yet. The policy supports observation; SPF, DKIM and DMARC results are still evaluated and reported.

SPF, DKIM and DMARC explained: why email gets rejected

Knowledge you can put to work.