Updated on 19 Jun 2026: We updated this guide for the current DMARC standard, bulk sender requirements, and safer handling of test-only domains.
Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are the three DNS-based email authentication standards that help receiving mail servers decide whether an email using your domain is legitimate. SPF checks whether the sending server is allowed to send for the envelope domain. DKIM checks whether the message carries a valid cryptographic signature. DMARC ties those checks to the visible From domain and tells receivers what to do when the message fails.
The shortest useful answer is this: SPF says which servers can send, DKIM proves the message was signed by a trusted domain, and DMARC turns those signals into a policy. Treat them as one system, not three separate DNS chores, because the policy only works when the sources, signatures, domain matches, and reporting are monitored together.
- SPF: Publish one TXT record that lists approved sending systems for your domain.
- DKIM: Turn on signing in each sender and publish the matching public key in DNS.
- DMARC: Publish a policy at _dmarc, send aggregate reports to a monitored address, and review reports before enforcing rejection.
- Monitoring: Use reports to find every legitimate sender before moving to stricter policy.
The direct answer
A domain needs all three records because they answer different questions. SPF asks, "Did this server have permission to send for the envelope domain?" DKIM asks, "Did a trusted domain sign this message, and is the signature still valid?" DMARC asks, "Does at least one successful check match the visible From domain, and what policy should the receiver apply if it fails?"
That last part is the key. A message can pass SPF for one domain while showing a different domain to the recipient. A message can pass DKIM for a vendor domain while showing your company domain in the visible From address. DMARC forces the authenticated domain to match the domain people see in the inbox, called the Author Domain in the current standard. That is what helps stop direct domain spoofing and many phishing attempts. It does not stop every misleading display name or lookalike domain, but it gives receivers a domain-level result they can enforce when your actual domain is abused.
Email authentication flowchart showing SPF, DKIM, DMARC policy, and receiver action.
|
|
|
|
|---|---|---|---|
SPF | Sending IP | Approved senders | Forwarding changes IP |
DKIM | Signature | Message integrity | Content changes |
DMARC | Domain match | Policy control | Wrong match or no report review |
The three standards at a glance.
To check a delivered message, open the message details or original source and read the Authentication-Results header added by the receiving system. Look for spf=, dkim=, and dmarc= results, then compare smtp.mailfrom, header.d, and header.from values to see whether the authenticated domain matches the visible From domain.
All three records are published in DNS, usually as TXT records, but not at the same host name. SPF sits at the envelope sender domain, DKIM sits under a selector such as selector._domainkey.example.com, and DMARC sits at _dmarc.example.com.
How SPF works
SPF is a TXT record at your domain that lists the servers or services allowed to send mail for the envelope sender. The envelope sender is the return path used during SMTP delivery. It is not always the same as the visible From address shown to a person reading the message.
A basic SPF record starts with v=spf1 and usually ends with -all or ~all. The strict ending says mail not listed should fail. The softer ending says it should be treated as suspicious. Use a clear sender inventory before using a strict ending, because one forgotten billing system or support tool can create delivery trouble.
Example SPF recorddns
example.com TXT "v=spf1 include:send.example -all"
The SPF lookup limit matters
SPF has a 10 DNS lookup limit for mechanisms such as include, a, mx, ptr, exists, and redirect. Too many nested includes can make SPF return a permanent error, even when the record looks reasonable at first glance.
- Inventory: List every system that sends mail before editing the live SPF record.
- Prune: Remove old includes for services no longer sending mail.
- Flattening: Use managed SPF when the record keeps hitting DNS lookup limits.
Some advanced SPF records use macros such as %{i} for the connecting IP or %{d} for the domain being evaluated. These values are not stored as separate DNS records; the receiver expands them during SPF evaluation, so debugging requires a real client IP, envelope sender, HELO name, and the exact mechanism being checked. If a macro appears in exists, query the expanded A record; if it appears in include or redirect, query the expanded TXT record.
SPF is useful, but it is not enough by itself. It breaks easily during forwarding because the forwarder becomes the sending server. That is why DKIM is important: the signature can survive forwarding when the message content stays unchanged.
How DKIM works
DKIM adds a digital signature to outgoing mail. The sending system signs selected headers and the message body with a private key. Receivers fetch the public key from DNS and check whether the signature is valid. If the message was changed after signing, DKIM fails.
A DKIM record lives under a selector. The selector lets a domain publish more than one key, which is useful for key rotation and multiple sending systems. In the DKIM-Signature header, d= identifies the signing domain and s= identifies the selector used to find the public key. Each vendor or internal mail system usually has its own selector. Use 2048-bit DKIM keys where the sender and DNS host support them.
Example DKIM public keydns
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIB..."
What DKIM proves
- Signer: A domain with a matching DNS key signed the message.
- Integrity: The signed parts of the message were not changed after signing.
- Continuity: Forwarded mail can still pass when the signature stays valid.
What DKIM does not prove
- Permission: DKIM does not list which servers are approved.
- Visibility: DKIM alone does not require the signer to match the visible From domain.
- Policy: DKIM does not tell receivers whether to reject failed mail.
The most common DKIM mistake is enabling signing in one place and assuming every sender is covered. Marketing mail, invoices, helpdesk replies, and web app notifications often use different infrastructure. Each one needs a valid signature tied to your domain or a closely related domain.
How DMARC makes the decision
DMARC sits on top of SPF and DKIM. It looks at the visible From domain and asks whether SPF or DKIM passed with a matching domain. Only one of them needs to pass for DMARC to pass. A domain does not need both SPF and DKIM to pass on every message, but it should configure both because real mail flows are messy.
DMARC alignment is relaxed by default, so a subdomain such as mail.example.com can match example.com at the organizational domain level. Strict alignment requires the authenticated domain and visible From domain to be exact matches.
If that distinction matters for your rollout, the deeper explanation is here: both SPF and DKIM. The practical rule is simple: configure both, monitor both, and expect DMARC to pass when at least one authenticated domain matches the visible sender domain.
Starter DMARC recorddns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
A p=none record is monitoring mode: it can generate reports, but it does not ask receivers to quarantine or reject failed mail.
Policy strength by stage
A simple way to read the three DMARC policies before changing DNS.
Monitor
p=none
Collect reports and fix legitimate senders.
Filter
p=quarantine
Ask receivers to place failed mail in spam.
Reject
p=reject
Ask receivers to reject failed mail during SMTP delivery.
The reporting address in the rua tag receives aggregate XML reports. Those reports show sources, volumes, pass rates, policy outcomes, and authenticated domains. They do not include full message bodies. Failure reports sent through ruf are less consistently supported and can include message-level details, so treat them as sensitive. The value of DMARC comes from reading reports and fixing the gaps before enforcing a stricter policy.
What changed in DMARC in 2026
DMARC is now defined by RFC 9989, a Proposed Standard published in May 2026. It obsoletes RFC 7489 and RFC 9091. Aggregate reporting and failure reporting now sit in RFC 9990 and RFC 9991, so current docs usually separate the policy record from the report formats.
- RFC 9989: Defines the current DMARC policy record, domain matching rules, DNS Tree Walk policy discovery, and domain owner actions.
- RFC 9990: Defines aggregate report XML, including source IP, count, policy result, header From, envelope From, and authentication results.
- RFC 9991: Defines failure reports for message-level authentication failures, which should be handled as sensitive data.
The change most likely to affect a simple rollout is that pct is no longer the way to stage partial enforcement. Use p=none, then p=quarantine, then p=reject. Use t=y only as an explicit testing signal where receivers support it. The newer np tag can set policy for non-existent subdomains, and psd is mainly for public suffix domain handling, so most ordinary domains do not need it.
Practical impact
For a normal business domain, the safest current pattern is still simple: publish explicit DMARC records for active author domains, keep relaxed alignment unless strict matching is a clear requirement, and avoid old examples that rely on pct for gradual rollout.
A clean setup path
A staged setup path works because DNS changes are easy to publish and hard to trust without evidence. The goal is to map every real sender first, then tighten policy once the reports show that normal mail passes consistently.
- Inventory: List every system that sends mail using the domain, including apps, servers, vendors, and automated alerts.
- Publish SPF: Create one SPF record with only active senders and keep the DNS lookup count under 10.
- Enable DKIM: Turn on DKIM signing in each sending system and verify the public selector record.
- Start DMARC: Publish DMARC at p=none with aggregate reporting so you can see real traffic.
- Send and inspect: Send a real message from each mailstream and check Authentication-Results for SPF, DKIM, DMARC, selectors, and domain matches.
- Fix gaps: Resolve sources that fail, use the wrong return path, miss DKIM, or sign with the wrong domain.
- Enforce: Move to quarantine and then reject after normal mail is passing and reports stay clean.
For bulk senders, Gmail and Yahoo requirements put SPF, DKIM, DMARC, TLS, valid forward and reverse DNS, low spam complaint rates, and one-click unsubscribe into the launch checklist. Gmail requires bulk senders to authenticate with SPF and DKIM, publish DMARC at least at p=none, and match the From domain with either the SPF domain or the DKIM domain for direct mail. Gmail says to keep spam rates below 0.10% and avoid 0.30% or higher; Yahoo requires bulk senders to keep spam rates below 0.3% and accepts relaxed matching.
Before raising policy, check the live DNS record with a focused DMARC checker. A syntax mistake can stop reports or make receivers ignore the policy. For a wider scan across SPF, DKIM, and DMARC, use a domain health check and review every warning before changing policy.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A generator is also useful when a domain has no DMARC record yet. Start with p=none, send reports to a monitored mailbox or platform, and keep the record short. If the report destination uses a different domain, publish the required authorization record for that destination.
For a test-only or blackhole email domain that only receives mail, make DNS say that clearly: publish v=spf1 -all, use a reject DMARC policy, and avoid sending production traffic from that domain. If the same domain sends test mail, treat it as a sending domain and configure SPF, DKIM, and DMARC reports like any other source.
Use one policy owner
Most DMARC projects fail because no one owns sender inventory. Give one team responsibility for approving new senders, checking DNS changes, and reviewing reports. That keeps marketing, finance, support, and engineering from adding senders that pass in isolation but fail DMARC in production.
How subdomains fit
A sending subdomain, such as mail.example.com, should be treated as its own sender identity. Parent-domain records do not automatically create SPF, DKIM selectors, provider verification records, or MX routing for the subdomain.
- SPF: Publish SPF where the platform uses the return-path or envelope sender domain.
- DKIM: Publish each selector under the signing domain, often with provider-supplied TXT or CNAME records.
- DMARC: Publish an explicit DMARC record on active sending subdomains when you need separate reporting or policy control.
- MX and A records: Add MX only when the subdomain receives replies or bounces, and add A or AAAA only when a host must resolve to an IP address.
DMARC policy discovery can use a parent policy when the subdomain has no valid DMARC record. A parent record can also set a subdomain policy with sp. For important mailstreams, publish a direct subdomain DMARC record so reports and policy changes are easier to control.
Where Suped fits
Raw DMARC aggregate reports are XML files, and they are painful to read by hand. Suped's product turns those reports into source groups, authentication rates, issue lists, and specific fix steps. That gives teams a practical way to replace "this domain has failures" with "this sender needs a DNS or signing change."
The same workflow connects DMARC, SPF, DKIM, blocklist (blacklist) monitoring, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and multi-tenant MSP reporting. The practical value is that the platform points to the next fix instead of leaving you with a pile of raw records.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
If you are moving a domain toward enforcement, Suped's DMARC monitoring workflow shows which sources are passing, which are failing, and which policy changes are ready to stage next. Suped also has Hosted DMARC for simpler policy management when DNS access is slow or split across teams.
That does not change the basics. You still need an accurate sender list, working SPF, valid DKIM, and a DMARC policy. Suped reduces the manual analysis work and makes the rollout easier to operate after the first policy change.
Common failure patterns
When a domain has DMARC failures, start with a small set of repeat causes first. Most issues are sender inventory gaps, a mismatch between the visible From domain and the authenticated domain, broken DKIM, or SPF records that became too complex.
Likely cause
- Forwarding: SPF fails because the forwarding server is now the sender.
- Modified mail: DKIM fails after a footer, subject tag, or body change.
- Wrong domain: The authenticated domain differs from the visible From domain.
- DNS limit: SPF fails because nested includes exceed the lookup limit.
- SPF macro path: A macro-created lookup expands to the wrong DNS name or record type.
Practical fix
- Forwarding: Make sure DKIM survives and passes for forwarded mail.
- Modified mail: Sign after modification or stop changing signed content.
- Wrong domain: Configure the sender to authenticate with your domain.
- DNS limit: Remove unused includes or use managed SPF flattening.
- SPF macro path: Recreate the SMTP context and query the expanded DNS name directly.
A failing source should be fixed before policy enforcement unless it is clearly unauthorized. For a more diagnostic approach, use this guide to troubleshoot DMARC failures and compare the report data with the message headers.
The simplest path forward
Start with SPF and DKIM because DMARC needs those signals. Publish DMARC at p=none so you can see the traffic. Fix the sources that fail. Move to quarantine only when normal mail is passing, then move to reject when the remaining failures are unauthorized or acceptable to block.
The work is less about writing one perfect DNS record and more about operating a clean sending program. Once the domain is monitored, the pattern becomes predictable: add senders carefully, keep SPF under the lookup limit, rotate DKIM keys when needed, and review DMARC reports before every policy change.
