DMARC Record Example: Templates for Every Policy

Here's the simplest working DMARC record:

Publish it as a TXT record at _dmarc.yourdomain.com. That's it. Your domain now has a valid DMARC record that satisfies the minimum requirement from Google, Yahoo, and Microsoft.

If you're in a hurry, that record is all you need right now. Come back to the rest of this guide when you're ready to understand what each tag does, how to move to stricter policies without breaking your mail, and why DMARC can still fail even when SPF and DKIM both pass.

For everyone else: let's walk through what the DMARC record actually means, what each policy level does, the alignment mistake that trips up most senders, and how DMARC fits into your broader deliverability setup as a B2B sender.

The Simplest DMARC Record (And What Each Part Does)

A DMARC record is a single DNS TXT record published at a specific subdomain of your domain:

The simplest useful record looks like this:

Three parts. That's all you need to get started.

v=DMARC1

This sets the version. Every DMARC record must start with this. It must appear first, exactly as written. Nothing before it.

p=none

This is the policy. It tells receiving mail servers what to do with messages that fail DMARC. With p=none, the answer is: nothing. Mail flows normally. You collect data. No email gets blocked or filtered because of this record.

That's exactly why it's the right starting point. You're turning on the monitoring without touching delivery.

rua=mailto:dmarc@yourdomain.com

This tells mailbox providers where to send your aggregate DMARC reports - daily XML summaries showing which systems are sending email using your domain and whether they're passing authentication. Replace the address with one you actually check.

Without rua=, you have no visibility. The record works, but you're flying blind.

DMARC Record Examples by Policy

Every DMARC record contains a policy tag (p=) that tells receiving servers what to do when an email fails authentication. There are three options. Here's what each one looks like, and when to use it. For a deeper dive into how SPF, DKIM, and DMARC work together, see our guide on how to implement SPF, DKIM, and DMARC.

p=none - Monitoring Mode

No action is taken on failing messages. Email continues to flow normally. You receive daily reports showing every system that sends email using your domain, whether they're passing authentication, and where failures are coming from.

Use p=none when:

• You're setting up DMARC for the first time
• You haven't yet identified every service sending email on your behalf
• You want visibility before you touch any mail flow

This is also the minimum required by Google and Yahoo for bulk senders (5,000+ emails/day), and by Microsoft since May 2025 for emails to Outlook, Hotmail, and Live addresses.

p=quarantine - Cautious Enforcement

Failing messages are treated as suspicious. Most receiving servers route them to the spam or junk folder instead of blocking them outright.

Use p=quarantine when:

• SPF and DKIM are correctly configured across your sending platforms
• DMARC reports show legitimate senders are passing authentication consistently
• You want spoofing protection without the risk of outright rejection

p=reject - Full Enforcement

Failing messages are rejected before they reach the recipient. This is the strongest spoofing protection available.

Use p=reject only when:

• You have monitored DMARC reports for weeks or months
• Every legitimate sending source is identified and authenticated
• SPF, DKIM, and DMARC alignment consistently pass across all your senders
• You have an ongoing process for monitoring new tools before they send

Why DMARC Fails Even When SPF and DKIM Both Pass

This is the most common DMARC problem we see, and it's the one competitors either bury in an appendix or skip entirely. So let's address it directly.

SPF passing and DKIM passing is not enough. For DMARC to pass, at least one of those results also has to align with the domain your recipients see in the From: address.

Here's what alignment means in practice:

• SPF alignment: the domain in the email's Return-Path (the envelope sender) must match the domain in the visible From: address
• DKIM alignment: the domain specified in the DKIM signature (d= tag) must match the domain in the visible From: address

The most common trigger: you connect a CRM, helpdesk, cold outreach tool, or marketing platform. That platform sends email using your domain in the From: address, but authenticates under its own domain behind the scenes. SPF and DKIM pass for the platform's domain. But they don't align with your From: domain. DMARC fails.

We see this constantly when teams add new tools without updating their DNS configuration. The fix is to configure each sending platform to authenticate under your domain specifically - not its own shared infrastructure.

One DKIM record per Email Service Provider (ESP), not per tool. If one ESP sends mail for multiple tools in your stack, you need one DKIM entry for that ESP, configured to sign with your domain.

How to diagnose an alignment failure:

• Open a received email and view the original message headers
• Look at the Authentication-Results header - it shows SPF, DKIM, and DMARC results and alignment status
• Check whether the authenticated domain matches your From: domain
• Review your DMARC aggregate reports for alignment failure patterns
• Run a real inbox placement test with MailReach's free Spam Test to see authentication results under actual receiving conditions

If you're seeing DMARC failures that don't make sense, our guide on fixing DMARC failures walks through the specific causes and fixes.

DMARC Record Examples for Special Cases

Most domains can start with the basic p=none example above. But a few situations need a different approach.

Parked Domains and Non-Sending Domains

If a domain never sends email - parked domains, defensive registrations, brand-protection domains - the right DMARC record is a hard reject with no reporting address needed:

This tells every mailbox provider to reject any email that claims to come from this domain. Since nothing legitimate ever should, there's no risk of disrupting real mail.

Secondary Outreach Domains for B2B Cold Email

This is the use case most DMARC guides skip entirely.

If you run B2B cold outreach, you should be using secondary domains, not subdomains of your primary domain. Subdomains share reputation with the parent domain. A deliverability problem on a subdomain affects your main domain too. Secondary domains (yourcompany.co, yourcompany.io) are completely separate and build their own reputation independently.

Stick to well-known extensions: .com, .co, .io. Avoid exotic TLDs. They trigger suspicion before your email even lands.

Each secondary domain needs its own complete authentication setup:

• A dedicated SPF record listing its authorized senders
• DKIM keys configured per ESP for that domain
• Its own DMARC record
• Its own warmup process to build sender reputation from scratch

For B2B cold outreach, DMARC is just the authentication layer. The reputation layer is what actually moves emails from spam to inbox. See how email warmup builds the sender reputation your secondary domains need.

Protecting Subdomains with the sp= Tag

By default, subdomains inherit the parent domain's DMARC policy. If you want explicit control, use the sp= tag:

p= applies to your organizational domain. sp= applies to all subdomains. If you have unused subdomains that should never send email, locking them down with sp=reject prevents them from being exploited for spoofing.

How to Move from p=none to Enforcement Without Breaking Your Mail

The DMARC record takes minutes to publish. The rollout takes weeks. The teams that run into trouble are almost always the ones that skip the monitoring phase and discover missing senders only after legitimate mail starts bouncing.

Here's the sequence that works:

Step 1: Publish p=none and start collecting reports

Leave this in place for at least two to four weeks. Confirm reports are arriving. Review them.

Step 2: Identify every system sending email as your domain

This is where most organizations are surprised. Beyond your main email provider, check:

• CRM platforms and sales engagement tools
• Marketing automation and newsletter platforms
• Helpdesk and ticketing systems
• Billing and invoicing software
• Internal applications and automated notifications
• Cold outreach tools

DMARC reports are often the first place teams discover sending systems they forgot existed.

Step 3: Fix authentication and alignment for every sender

For each sending platform you find:

• Confirm SPF is configured and the sending IP is authorized
• Publish DKIM records and enable signing for your domain specifically
• Verify the authenticated domain aligns with your From: address
• Confirm results in your DMARC reports before moving on

Step 4: Move to p=quarantine

Only move here after your reports show clean authentication across all your senders. Continue monitoring. Watch for any legitimate mail landing in junk.

Step 5: Move to p=reject (when the evidence supports it)

Move to p=reject only after months of clean reporting, with every sender verified, every alignment issue resolved, and a process in place for vetting new tools before they start sending.

A note on the pct= tag: you may see DMARC records that use pct=10 or pct=25 to apply enforcement to only a percentage of messages. Modern guidance discourages relying on it - mailbox providers don't implement it consistently. A phased rollout through p=none to p=quarantine to p=reject is more reliable.

DMARC Reporting Tags: What rua and ruf Actually Do

DMARC reports are how you see what's happening after your record is live. Without reporting enabled, you can enforce policies, but you won't know which systems are passing, failing, or attempting to send mail using your domain.

rua= (Aggregate Reports)

Aggregate reports are daily XML summaries sent by participating mailbox providers. They show you who is sending email using your domain, which IPs are involved, and whether they're passing or failing SPF, DKIM, and DMARC.

This is the one you need. For most organizations, rua= alone is sufficient.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Point it at a dedicated mailbox you'll actually monitor. Providers typically send reports once per day. Expect XML files that require either manual parsing or a reporting tool to read easily.

ruf= (Forensic / Failure Reports)

Forensic reports contain details about individual authentication failures. They're optional, not sent consistently by all providers, and raise privacy considerations in some regions. For most senders, rua= alone is the right setup.

External Reporting Addresses

If your rua= address uses a different domain than your sending domain, the receiving domain must publish a DNS record authorizing itself to receive reports on your behalf. Without it, reports may not be delivered - silently.

Always verify reports are arriving within a few days of publishing your DMARC record. If they're not, check this authorization requirement first.

Why DMARC Alone Won't Fix Your Inbox Placement

DMARC is necessary. It's not sufficient.

Google, Yahoo, and Microsoft use SPF, DKIM, and DMARC alignment to decide whether a message is authenticated properly. For high-volume senders, this authentication layer is now table stakes. Without it, your emails are much more likely to be junked, rejected, or treated as suspicious before content and reputation even get evaluated. But it doesn't earn the inbox. That decision comes down to three pillars:

• Sending setup (authentication): SPF, DKIM, and DMARC - DMARC lives here
• Sender reputation: built from real engagement signals over time, such as recipients opening your emails inside Gmail or Outlook, replies, positive mailbox interactions, low spam complaints, and consistent inbox placement
• Email content: structure, links, spam trigger words, and how your messages look to filters

Authentication is table stakes. It gets you into the game. Reputation is what moves your emails from spam to inbox.

For B2B cold outreach specifically, this matters a lot. You're sending to people who haven't heard of you. There's no prior relationship, no engagement history, no brand recognition with their inbox provider. A clean DMARC record tells providers your email is legitimately from you. It does nothing to tell them your email is worth reading.

That's why every secondary outreach domain needs warmup - not just authentication. MailReach warms up your sender reputation through meaningful positive interactions with a network of 30,000+ real Google Workspace and Microsoft 365 inboxes. It's the reputation layer that works alongside authentication to actually move your emails to the inbox. See how email warmup works and why network quality is what separates effective warmup from the rest.

FAQs

What is an example of a DMARC record?

The simplest example is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, published as a TXT record at _dmarc.yourdomain.com. v=DMARC1 sets the version, p=none tells receivers to monitor without acting, and rua= is where your aggregate reports go. This is the minimum required by Google, Yahoo, and Microsoft for bulk senders.

Is p=none good enough?

For getting started and satisfying inbox provider requirements, yes. p=none is also the correct starting point because it gives you visibility without disrupting mail. For complex sending environments with multiple platforms and vendors, a well-monitored p=quarantine is often the right long-term destination. Don't rush to p=reject before your reporting confirms every sender is clean.

Why does DMARC fail when SPF and DKIM both pass?

Alignment. SPF and DKIM passing is not enough - the authenticated domain also has to match the domain in your visible From: address. This breaks most often when a third-party tool (CRM, helpdesk, outreach platform) authenticates email under its own domain instead of yours. The fix is to configure each platform to sign and authenticate using your domain specifically.

Do I need a separate DMARC record for each subdomain?

Usually not. One record on your organizational domain governs subdomains by default. Use the sp= tag to set an explicit subdomain policy - for example, sp=reject to lock down subdomains you never send from. Secondary outreach domains, however, are completely separate and each need their own DMARC record.

Can I send DMARC reports to my own email address instead of a paid tool?

Yes. Point rua=mailto: at any inbox you control and you'll receive aggregate reports for free. The catch is they arrive as raw XML, which is workable for a small domain but becomes difficult to parse at scale. For a single sending domain with limited activity, your own mailbox is fine.

Will DMARC improve my cold email deliverability?

DMARC is necessary but not sufficient. Without it, Google, Yahoo, and Microsoft can reject or junk your email before it's even evaluated. But having it doesn't earn the inbox, that depends on sender reputation and content. DMARC fixes the authentication pillar. Inbox placement depends on all three. See our guide on improving email deliverability for the full picture.

Does Microsoft now require DMARC?

Yes. Since May 5, 2025, Microsoft requires SPF, DKIM, and a minimum DMARC policy of p=none for bulk senders (5,000+ emails/day) to Outlook.com, Hotmail.com, and Live.com addresses. Non-compliant messages are initially routed to junk, with rejection following. Google and Yahoo adopted similar requirements in February 2024. All three major inbox providers now require DMARC for bulk mail.

‍