What is a DMARC record?
What is a DMARC record?
DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication policy that works with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to protect your domain from spoofing and phishing.
A DMARC record is a TXT record published in your DNS settings at _dmarc.yourdomain.com. It does three things: checks that authenticated mail actually matches the From address people see, tells receiving servers what to do with mail that fails, and sends you reports about who is sending email as your domain.
The current DMARC standard is RFC 9989, published in May 2026. It replaces the original RFC 7489. Learn more at dmarc.org.
How does DMARC work?
- Authentication: The receiving server checks SPF and DKIM on the incoming message.
- Alignment: DMARC checks whether the domain that passed SPF or DKIM matches the domain in the visible From address. A message passes DMARC if at least one of them both passes and aligns. You don't need both.
- Policy: If a message fails DMARC, the receiver applies your policy: do nothing, send it to spam, or reject it.
- Reporting: Receivers send aggregate reports to the address you specify, showing which sources sent mail as your domain and whether it passed.
| Alignment mode | What must match | Example |
|---|---|---|
| Relaxed (default) | The same organizational domain | news.example.com aligns with example.com |
| Strict | The exact same domain | news.example.com must match news.example.com |
What a DMARC record looks like
Here's an example of a DMARC record:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1
DMARC tags
| Tag | Required? | What it does |
|---|---|---|
v | Yes | Always DMARC1, listed first |
p | Yes | Your policy for mail that fails: none, quarantine or reject |
rua | Recommended | Where receivers send daily aggregate reports |
sp | Optional | A separate policy for subdomains |
np | Optional (new) | A policy for subdomains that don't exist, a common target for spoofing |
adkim / aspf | Optional | DKIM and SPF alignment mode: r (relaxed, default) or s (strict) |
ruf | Optional | Where to send individual failure reports (few providers send them) |
fo | Optional | When to generate failure reports: 0 (default, both SPF and DKIM fail to align), 1 (either fails), d (DKIM fails) or s (SPF fails) |
t | Optional (new) | Test mode: t=y asks receivers to apply the next-lower policy while you test |
psd | Optional (new) | Used only by public suffix operators, not by typical businesses |
RFC 9989 retired the pct, rf and ri tags. Existing records that include them still work, but next time you update your DMARC record, remove them. Use t=y instead of pct for gradual rollouts.
Choosing a DMARC policy
| Policy | What happens to failing mail | When to use it |
|---|---|---|
p=none | Delivered normally; you receive reports | Starting out, to find every service sending as your domain |
p=quarantine | Sent to the spam or junk folder | Once legitimate mail is passing; our recommended minimum |
p=reject | Refused entirely | The strongest protection, once you're confident everything legitimate passes |
A safe rollout looks like this:
- Publish
p=nonewith aruaaddress and review reports for a few weeks. - Set up SPF and DKIM for every legitimate service you find, such as your email platform, CRM and help desk.
- Move to
p=quarantine, optionally witht=yat first. - Move to
p=rejectonce reports show legitimate mail consistently passing.
We recommend reaching at least p=quarantine. A p=none policy satisfies the minimum Gmail and Yahoo bulk-sender requirement, but it doesn't stop anyone from spoofing your domain.
Why DMARC matters for deliverability
Gmail and Yahoo require bulk senders (5,000+ messages a day) to publish a DMARC record and align their From domain with SPF or DKIM. Since May 5, 2025, Microsoft also rejects high-volume mail to Outlook.com, Hotmail and Live addresses that fails SPF, DKIM or DMARC.
Sources: Google sender guidelines, dmarcian on Microsoft's requirements. Learn more about the Gmail and Yahoo inbox protection rules.
DMARC is also a prerequisite for BIMI and Google's verified checkmark, which require a quarantine or reject policy.
Benefits of DMARC
- Protection from spoofing: An enforced policy stops scammers from sending phishing email that appears to come from your domain.
- Visibility: Reports show every service sending as your domain, including ones you didn't know about.
- Better deliverability: Authenticated, aligned mail is more trusted by mailbox providers and required for bulk senders.
- Brand trust: DMARC enforcement opens the door to displaying your logo in supporting inboxes through BIMI.
Setting up DMARC with DailyStory
DailyStory sends from a dedicated subdomain and provides the SPF and DKIM records that make your email align. Your DMARC record is published on your main domain at _dmarc.yourdomain.com. See Configuring SPF, DKIM and DMARC and Setting up your email domain for step-by-step instructions.
How does DMARC relate to DKIM2?
DKIM2 is a proposed next-generation authentication protocol being developed by the IETF's DKIM working group. It adds chain-of-custody signing across forwarding hops, envelope binding to prevent replay attacks, and secure delayed bounces.
As of September 2026, DKIM2 is still a set of Internet-Drafts, not a finished standard, and mailbox providers don't require it. DMARC remains the current requirement. Keep your policy at p=quarantine or p=reject with reporting in place.
Frequently asked questions
Does DMARC require both SPF and DKIM to pass?
No. A message passes DMARC if either SPF or DKIM passes and aligns with the From domain. Setting up both is still best practice, because DKIM survives forwarding when SPF doesn't.
Is p=none good enough?
It meets the minimum Gmail and Yahoo bulk-sender requirement and gives you reports, but it doesn't protect your domain from spoofing. Treat it as a starting point and move to quarantine or reject.
Do I need to update my DMARC record for RFC 9989?
Not immediately. Existing v=DMARC1 records still work. When you next change your record, remove the retired pct, rf and ri tags, and consider adding np to cover subdomains that don't exist.