DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that helps protect your domain from being used in phishing and spoofing attacks. It builds on SPF and DKIM, adds a reporting mechanism, and tells receiving mail servers what to do when authentication fails. It is now required by major providers including Google and Microsoft for bulk senders.

SPF (Sender Policy Framework) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. When a server receives an email from your domain, it checks the SPF record: if the sending IP is listed the email passes SPF, otherwise it fails. SPF has a strict limit of 10 DNS lookups.

DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails. Your mail server signs messages with a private key and you publish the matching public key in DNS, so recipients can verify the message has not been altered and truly came from your domain. 2048-bit keys are recommended.

What are the DMARC policies (p=none, quarantine, reject)?

The DMARC policy tells receivers what to do with mail that fails authentication. p=none monitors only and delivers normally while still sending reports; p=quarantine treats failing mail with suspicion, usually delivering it to spam; p=reject blocks failing mail outright. The recommended approach is to start at p=none, monitor for 2-4 weeks, fix issues, then move to p=quarantine and finally p=reject.

How do I set up DMARC?

Audit every service that sends email on your behalf, publish an SPF record listing all authorized senders, enable DKIM signing in each service, then add a DMARC TXT record at _dmarc.yourdomain.com starting with p=none to collect data. Review the aggregate reports, fix SPF and DKIM issues for each sender, then move to p=quarantine and finally p=reject once all legitimate mail passes.

Learn Email Authentication - DMARC, SPF, DKIM Guide

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that helps protect your domain from being used in phishing and spoofing attacks.

Why DMARC matters

Prevents attackers from sending emails that appear to come from your domain
Improves email deliverability by building sender reputation
Provides visibility into who is sending email on your behalf
Required by major email providers (Google, Microsoft) for bulk senders

DMARC builds on two existing authentication mechanisms: SPF and DKIM. It adds a reporting mechanism and tells receiving mail servers what to do when authentication fails.

Example DMARC record:

v=DMARC1; p=reject; np=reject; rua=mailto:[email protected]

Updated for RFC 9989 (DMARCbis, May 2026): the pct tag was removed (use t=y to stage enforcement), and np sets a policy for non-existent subdomains.

SPF Explained

SPF (Sender Policy Framework) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain.

How SPF works

You publish an SPF record in your DNS
When someone receives an email from your domain, their server checks your SPF record
If the sending server's IP is listed, the email passes SPF
If not listed, the email fails SPF authentication

Example SPF record:

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

SPF mechanisms

include:

Reference another domain's SPF record

ip4: / ip6:

Authorize specific IP addresses

a / mx

Authorize your A or MX record IPs

-all / ~all

What to do with non-matching senders

Important: 10-lookup limit

SPF has a strict limit of 10 DNS lookups. Each include:, a, mx, ptr, and exists: mechanism counts as one lookup. Exceeding this limit causes SPF to fail.

DKIM Explained

DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails. Recipients can verify this signature to confirm the email hasn't been altered and truly came from your domain.

How DKIM works

Your email server signs outgoing messages with a private key
You publish the corresponding public key in DNS
Recipients fetch your public key and verify the signature
If the signature matches, DKIM passes

Example DKIM record (selector1._domainkey.example.com):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

DKIM components

Selector

A name that identifies which key to use (e.g., "google", "selector1"). Allows key rotation without breaking existing emails.

Key length

2048-bit keys are recommended. 1024-bit keys are still common but considered less secure.

Signature header

Added to each outgoing email, contains the cryptographic signature.

How They Work Together

DMARC uses SPF and DKIM results to make a final authentication decision. For an email to pass DMARC, it must pass either SPF or DKIM and be aligned with the domain in the "From" header.

DMARC alignment

"Alignment" means the domain in the authentication check matches the domain in the visible "From" header.

SPF alignment

The domain in the "Return-Path" matches the "From" domain

DKIM alignment

The domain in the DKIM signature (d=) matches the "From" domain

Scenario	DMARC Result
SPF pass + aligned	Pass
DKIM pass + aligned	Pass
SPF pass but not aligned, DKIM pass + aligned	Pass
SPF pass but not aligned, DKIM fail	Fail
Both SPF and DKIM fail	Fail

DMARC Policies

The DMARC policy (p=) tells receiving servers what to do when an email fails authentication.

p=none

Monitor only

Emails are delivered normally regardless of authentication result. Use this to gather data before enforcing. Reports are still sent.

p=quarantine

Quarantine

Failing emails should be treated with suspicion. Usually delivered to spam/junk folder. Good intermediate step.

p=reject

Reject

Failing emails should be rejected outright. Maximum protection. Only use after confirming all legitimate senders are authenticated.

Recommended approach

Start with p=none, monitor reports for 2-4 weeks, fix any issues, then gradually move to p=quarantine and finally p=reject.

Implementation Guide

Audit your current senders

Before implementing DMARC, identify all services sending email on your behalf:

- Your mail server (Microsoft 365, Google Workspace, etc.)
- Marketing tools (Mailchimp, HubSpot, Sendgrid, etc.)
- Transactional email (your application, CRM, helpdesk)
- Third-party services (invoicing, HR systems, etc.)

Set up SPF

Add a TXT record at your domain root with all authorized senders:

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

Set up DKIM

Enable DKIM signing in each service that sends email. Each service will give you a DNS record to add. Example for Google Workspace:

google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGf..."

Add DMARC record

Add a TXT record at _dmarc.yourdomain.com. Start with p=none to collect data:

v=DMARC1; p=none; np=none; rua=mailto:[email protected]

Monitor and fix

Review DMARC reports to identify authentication failures. Fix SPF and DKIM issues for each sender. Once all legitimate mail passes, move to p=quarantine, then p=reject.

Common Mistakes

Exceeding SPF lookup limit

SPF allows only 10 DNS lookups. Adding too many includes will cause SPF to fail for all emails. Use IP addresses directly or SPF flattening services if needed.

Jumping to p=reject too quickly

Implementing reject policy before fixing all senders will cause legitimate email to be blocked. Always start with p=none and monitor for at least 2 weeks.

Forgetting third-party senders

Marketing platforms, CRMs, and other services often send email on your behalf. Each one needs proper SPF and DKIM configuration.

Not monitoring reports

DMARC reports are essential for understanding your email ecosystem. Without monitoring, you won't know when something breaks or when attackers try to spoof your domain.

Using weak DKIM keys

1024-bit DKIM keys are technically valid but considered weak. Use 2048-bit keys when possible for better security.

DMARC record tags (RFC 9989)

Every tag a DMARC record can carry, with its status under RFC 9989 (DMARCbis, May 2026). Generated from Blankitt's shared DMARC spec registry (2026.08.0), the same source of truth our monitoring product uses.

v=Standard

Unchanged across the transition, DMARC1 remains the only valid version under RFC 9989, so existing records stay syntactically valid.

p=Standard

Unchanged. Note RFC 9989's interoperability guidance: strict policies damage mailing-list traffic, where list traffic matters, pair enforcement with the t= test mode rather than the removed pct= ramp.

sp=Standard

Unchanged, and still load-bearing during the transition: RFC 7489-era receivers ignore the new np= tag and fall back to sp=, so keep sp= correct even after publishing np=.

adkim=Standard

Unchanged (r/s alignment mode for DKIM).

aspf=Standard

Unchanged (r/s alignment mode for SPF).

fo=Standard

RETAINED by RFC 9989 (values 0/1/d/s), contrary to some transition summaries. Only meaningful alongside ruf=, which RFC 9991 discourages on privacy grounds.

rua=Standard

Unchanged mechanics; RFC 9990 carries forward the external-destination rule: when rua= points at a different organisational domain, the destination must publish {your-domain}._report._dmarc.{destination} (no organisational-domain fallback, each subdomain needs its own record).

ruf=Situational

RFC 9991 discourages failure reports on privacy grounds, they can carry message headers, subjects and recipient addresses. Few large receivers send them. Prefer omitting ruf=; if you keep it, point it at a restricted mailbox and treat the contents as personal data.

pct=Removed in RFC 9989replaced by t=

Removed by RFC 9989 (Appendix A.6). Still honoured by RFC 7489-era receivers; RFC 9989-era receivers ignore it and apply your policy at full strength. Do not use in new records, use t=y to stage enforcement, and remove it at your next DNS edit.

rf=Removed in RFC 9989

Removed by RFC 9989 (failure-report format selector; AFRF is the only format anyway). Harmless but dead weight, remove at your next DNS edit.

ri=Removed in RFC 9989

Removed by RFC 9989 (requested aggregate interval; receivers effectively always sent daily regardless). Remove at your next DNS edit.

t=New in RFC 9989

Test mode (y/n), replacing the pct= ramp. Under t=y an RFC 9989-era receiver applies the next-weaker handling (reject behaves as quarantine; quarantine as none). RFC 7489-era receivers IGNORE it and enforce your policy at full strength, so stage policy changes as if t= were absent, during low-risk windows.

np=New in RFC 9989

Policy for NON-EXISTENT subdomains (same syntax as p=). Ignored by RFC 7489-era receivers, which fall back to sp=, purely additive, safe to publish now; keep sp= correct alongside it. Recommended as np=reject for parked and defensive registrations.

psd=Situational

Public-suffix-domain marker (y/n/u, default u) used during policy discovery, folds RFC 9091 into the core spec. Only public-suffix operators should publish psd=y; ordinary domains leave it absent.

Glossary

DMARC

Domain-based Message Authentication, Reporting & Conformance - an email authentication protocol that uses SPF and DKIM results.

SPF

Sender Policy Framework - a DNS record listing authorized mail servers for your domain.

DKIM

DomainKeys Identified Mail - a method of digitally signing emails to verify authenticity.

Alignment

When the domain used in authentication (SPF/DKIM) matches the domain in the visible From header.

RUA

Reporting URI for Aggregate reports - the email address where DMARC aggregate reports are sent.

RUF

Reporting URI for Forensic reports - the email address for detailed failure reports (less common).

Aggregate report

Daily/weekly summary of all emails claiming to be from your domain, grouped by result.

Policy (p=)

What receivers should do with failing emails: none (report only), quarantine (spam), or reject. See the tag table above for the full RFC 9989 tag set.

MTA-STS

Mail Transfer Agent Strict Transport Security - enforces TLS encryption for email in transit.

TLS-RPT

TLS Reporting - provides reports on TLS connection failures between mail servers.

BIMI

Brand Indicators for Message Identification - displays your logo in email clients (requires DMARC p=reject).

Ready to secure your email?

Check your domain's current status with our free tool, or start monitoring with Blankitt DMARC.

Check your domain free View pricing

Email Authentication Guide