What Is DMARC, and Why It's Crucial for Email Delivery and Security

For years, getting email authentication wrong meant your messages landed in the spam folder. Annoying, recoverable, and easy to ignore.

That is no longer what happens. Since 2024, Gmail, Yahoo and Outlook have required authentication from anyone sending at volume, and they have moved from filtering non-compliant mail to rejecting it outright. Your invoice, password reset or order confirmation may not simply arrive late; it may not arrive at all.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the standard sitting at the centre of those requirements. It is also the single most effective control you can put in place to stop criminals sending email that appears to come from your business.

This guide covers what DMARC actually does, the one concept most people get wrong, how to publish a record safely, and how to reach enforcement without blocking your own mail along the way.

Why this is now urgent

Three of the largest mailbox providers in the world converged on the same rulebook within eighteen months of each other.

Google requires authentication from every sender, and from February 2024 it applied stricter rules to anyone sending around 5,000 or more messages a day to personal Gmail accounts: SPF and DKIM, a published DMARC policy, one-click unsubscribe on marketing mail, and spam complaint rates kept below 0.3%. From November 2025 Google began ramping up enforcement on non-compliant traffic, with temporary and permanent rejections rather than spam foldering.

Two details catch people out. The 5,000 threshold counts everything sent from the same primary domain, your marketing platform, your CRM, your invoicing tool and your helpdesk combined. And bulk sender status, once triggered, does not expire. Cross the line once and the requirements apply permanently.

Yahoo introduced matching requirements on the same February 2024 timetable, with one difference: it publishes no numeric threshold at all, defining a bulk sender by "significant volume" at its own discretion.

Microsoft followed on 5 May 2025 for domains sending over 5,000 messages a day to Outlook.com, Hotmail and Live.com. Non-compliant mail is routed to junk first and rejected if the problem persists, with the bounce code 550 5.7.515 Access denied, sending domain does not meet the required authentication level.

The practical takeaway is simple. DMARC stopped being a security nice-to-have and became a condition of delivery.

How DMARC works with SPF and DKIM

DMARC is not a standalone check. It sits on top of two older standards and adds the two things they lack: a policy, and a feedback loop.

Standard	Question it answers	What it cannot do
SPF	Is this server allowed to send for this domain?	Says nothing about the address recipients actually see
DKIM	Was this message signed by the domain, and unaltered in transit?	Same, the signing domain need not match the visible sender
DMARC	Does the visible From address match a passing check, and what should happen if not?	Nothing, unless SPF or DKIM is already working

SPF publishes a list of servers authorised to send on your behalf. The receiving server compares the sending server against that list.

DKIM attaches a cryptographic signature to every outgoing message. The recipient verifies it against a public key in your DNS, proving the message genuinely came from your domain and was not tampered with.

DMARC then does two things neither can. It tells receiving servers what to do with mail that fails, and it asks them to send you daily reports on every message claiming to be from your domain, including the ones you did not send.

Alignment: the part almost everyone gets wrong

This is the single most common reason a business with working SPF and DKIM still fails DMARC, and it is worth reading twice.

Every email carries more than one sender identity. There is the envelope sender (the Return-Path, used by SPF), the DKIM signing domain, and the From: header, the only one your recipient ever sees.

DMARC does not care that SPF passed alone. It cares that SPF passed for the same domain shown in the From: header. That match is called identifier alignment, and DMARC requires at least one of SPF or DKIM to both pass and align.

Here is the classic failure. You send your newsletter through a marketing platform. The platform's own domain is in the Return-Path, so SPF passes, for the platform, not for you. Your From: address says hello@yourbusiness.com. Nothing aligns, and DMARC fails despite every individual check looking green.

The fix is to authenticate each third-party sender as your domain: set up a custom return-path or sending subdomain, and publish that platform's DKIM keys in your own DNS. Every serious sending platform documents how. Do this for every tool that emails on your behalf before you tighten your policy.

The three DMARC policies

Policy	What receivers do with failing mail	When to use it
p=none	Nothing, deliver as normal, but send reports	Discovery. Always your starting point
p=quarantine	Deliver to spam or junk	Once your legitimate senders all pass
p=reject	Refuse the message at the server	Full protection. The goal

An important caveat: p=none gives you visibility, not protection. It satisfies the minimum bar set by Google, Yahoo and Microsoft, but it stops nothing. Plenty of businesses publish p=none, tick the compliance box and never progress, leaving their domain just as spoofable as it was before.

Only p=reject actually prevents criminals sending mail in your name.

What a DMARC record looks like

A DMARC record is a single DNS TXT record published at _dmarc.yourbusiness.com. Starting out, it looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourbusiness.com; fo=1

A mature record at enforcement looks more like this:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:reports@yourbusiness.com; pct=100

The tags worth knowing:

Tag	What it controls
v	Version. Always DMARC1, and always first
p	Policy for the main domain: none, quarantine or reject
sp	Policy for subdomains. Omit it and subdomains inherit p
rua	Where daily aggregate reports are sent. The tag that makes DMARC useful
ruf	Where forensic reports go. Many providers no longer send these on privacy grounds
pct	Percentage of failing mail the policy applies to. Useful for phasing in quarantine
adkim / aspf	Alignment mode: r relaxed (subdomains count) or s strict (exact match)
fo	When failure reports are generated. fo=1 covers any failing check

Start with relaxed alignment. Strict alignment breaks legitimate mail sent from subdomains, and there is rarely a reason to impose it early.

The reporting problem, and how to solve it

The rua tag is where DMARC earns its keep, and where most implementations quietly collapse.

Point it at a normal mailbox and, within days, you will be receiving gzipped XML attachments from Google, Microsoft, Yahoo, Comcast and dozens of others you have never heard of. Each contains raw authentication results for every IP address that sent mail claiming to be you. They are machine-readable and, in practice, humanly unreadable.

This is the exact point at which most DMARC projects stall. The record is published, the reports pile up unread in a folder, the policy stays at p=none forever, and the domain remains spoofable.

EasyDMARC is the platform we recommend for solving this. You point your rua tag at their address and the raw XML becomes a readable dashboard: every sending source identified by name rather than IP, grouped into compliant, non-compliant, forwarded and threat, so you can see at a glance which of your own tools are broken and which senders are impersonating you.

Beyond report parsing, the features that matter for getting to enforcement are:

• Source identification. Sending tools are named, your CRM, your invoicing platform, your helpdesk, rather than left as bare IP addresses you have to research.
• EasySPF and managed records. CNAME-based managed DMARC, SPF, DKIM and BIMI records, so policy changes happen in the platform rather than through a DNS ticket each time.
• The 10-lookup problem. SPF permits only ten DNS lookups; add enough platforms and the record silently breaks. SPF flattening and auto-detection of sources solve it.
• Policy progression with impact preview. You can see what moving to quarantine or reject would actually do to your mail before you do it.
• Alerting. Notifications for unauthorised senders, compliance drops and policy changes, via email, Slack or Teams.

There is a free XML report analyser if you simply want to see what one of your reports contains, and a 14-day trial of the full platform, try EasyDMARC here. Read our full EasyDMARC review for the detail. For most businesses, the value is not the parsing, it is that the platform tells you exactly which sender to fix next, which is what turns p=none into p=reject.

Alternatives worth knowing include Dmarcian, Valimail, Postmark's free DMARC digest service and the open-source OpenDMARC for teams who want to self-host. The important thing is that you use something.

A safe four-stage rollout

Rushing to p=reject is how businesses block their own invoices. Work through these stages instead, and do not advance until the current one is clean.

Stage 1: Monitor and inventory (2 to 4 weeks)

Publish p=none with a working rua address pointed at your reporting platform. Change nothing else.

Your goal is a complete list of everything that sends email as your domain. Expect surprises. Almost every business discovers a forgotten tool: an old marketing account, a website contact form, a booking system, a finance platform, something a department signed up for two years ago.

Stage 2: Fix alignment, sender by sender

Work down the non-compliant list. For each legitimate sender, configure a custom return-path or sending subdomain and publish its DKIM keys in your DNS.

Keep an eye on your SPF record while you do it. Ten DNS lookups is the hard limit, and exceeding it invalidates the whole record.

Stage 3: Quarantine, gradually

When your reports show legitimate mail passing consistently, move to quarantine on a fraction of traffic:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourbusiness.com

Watch for a week, then step to 50, then 100. Any surprise lands in spam rather than disappearing, which gives you room to correct it.

Stage 4: Enforce

Move to p=reject. Set sp=reject as well, and publish a reject policy on parked domains you never send from ; those are precisely the ones attackers look for.

Keep reading the reports. Enforcement is a state to maintain, not a project to finish: every new tool your business adopts is a new sender that has to be authenticated.

Common mistakes that break delivery

• Two SPF records. Only one is permitted per domain. Additional senders go inside the existing record, never alongside it. Two records is an automatic fail.
• Exceeding ten SPF lookups. Each include: costs a lookup and can trigger more. Past ten, the record fails entirely.
• Forgetting subdomains. Without sp, subdomains inherit your policy, but parked and unused domains need their own reject records.
• Jumping straight to reject. Skipping monitoring is the fastest way to block your own transactional mail.
• Publishing p=none and stopping. Compliant on paper, unprotected in practice.
• Ignoring forwarding. Forwarded mail frequently breaks SPF. DKIM usually survives, which is why having both matters.
• Using a real mailbox for rua. Unless you enjoy XML.

What you get beyond deliverability

The delivery argument is the one that forces the work, but enforcement pays off in three other ways.

It stops domain impersonation. Invoice fraud and supplier payment redirection overwhelmingly rely on email that appears to come from a trusted domain. A reject policy makes exact-domain spoofing of your business fail at the recipient's server.

It gives you visibility you did not have. Most businesses cannot list everything that sends email in their name. DMARC reporting produces that inventory as a side effect.

It unlocks BIMI. Brand Indicators for Message Identification puts your verified logo beside your messages in supporting inboxes. It requires p=quarantine or p=reject, so enforcement is the entry ticket.

Where to start this week

Check what you already have. Look up the TXT record at _dmarc.yourbusiness.com; many businesses find an old p=none record published by an agency years ago, with reports going to a mailbox nobody reads.

Then publish a monitoring record pointed at a reporting platform, give it a month, and work through what it shows you. EasyDMARC is where we would send most businesses to do that, because the platform does the part that otherwise stalls the project.

The deadline has effectively passed. Google, Yahoo and Microsoft are enforcing now, and the cost of not acting is no longer a spam folder, it is mail that never arrives.

If you are choosing where your business email should live in the first place, our guide to the best email hosting providers covers the providers worth shortlisting and how each handles authentication.