What is DMARC? A Complete Guide to Email Authentication

DMARC is the single most effective way to stop criminals from sending fake emails using your domain name. If you have ever wondered why phishing emails appear to come from legitimate organisations, the answer is almost always the same: the sender's domain has no DMARC policy in place.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email authentication protocol that tells receiving mail servers (such as Gmail, Outlook, or Yahoo) what to do when an incoming email fails SPF or DKIM checks.

Without DMARC, a receiving server that detects a failed authentication check has no clear instruction from the domain owner. It might deliver the message anyway, flag it as suspicious, or silently drop it. DMARC removes that ambiguity by publishing a policy in your DNS that says: "If an email claiming to be from my domain fails authentication, here is what you should do with it."

DMARC also introduces reporting. When you publish a DMARC record, receiving servers send you daily aggregate reports detailing every email they saw from your domain, whether it passed or failed, and which IP address sent it. This gives you visibility into who is sending email on your behalf (legitimate services like your CRM or newsletter platform) and who is spoofing your domain.

How DMARC works with SPF and DKIM

DMARC does not work alone. It sits on top of two existing email authentication standards, SPF and DKIM, and adds a critical piece called alignment. For a detailed comparison of all three protocols, see our guide on SPF vs DKIM vs DMARC.

SPF (Sender Policy Framework)validates the sending server's IP address. Your domain publishes a DNS record listing every IP address and service that is authorised to send email on your behalf. If a message arrives from an IP not on the list, SPF fails. If your SPF record is becoming complex, our SPF Flattener can help you simplify it.
DKIM (DomainKeys Identified Mail) validates the message signature. The sending server attaches a cryptographic signature to the email header. The receiving server retrieves the corresponding public key from DNS and verifies the signature. If the message was altered in transit, or the signature does not match, DKIM fails.
DMARC alignment is the layer that ties everything together. SPF and DKIM each authenticate a domain, but that domain might differ from the one shown in the "From" header (the address the recipient actually sees). DMARC requires that the domain authenticated by SPF or DKIM matches (aligns with) the domain in the From header.

Here is the flow for a typical inbound email:

1.The sending server delivers the message to the receiving server.

2.The receiving server checks SPF: is the sending IP authorised?

3.The receiving server checks DKIM: is the message signature valid?

4.The receiving server checks DMARC alignment: does the domain authenticated by SPF or DKIM match the From header?

5.If alignment passes, the email is delivered normally. If it fails, the receiving server applies the DMARC policy (none, quarantine, or reject).

An email only needs to pass either SPF or DKIM with alignment for DMARC to pass. This is important because some legitimate forwarding scenarios break SPF (the forwarding server's IP is not in the original SPF record), but DKIM survives because the signature travels with the message.

DMARC policies: none, quarantine, reject

The p= tag in your DMARC record tells receiving servers how strictly to handle authentication failures. There are three levels:

Policy	What happens to failures	When to use it
p=none	Nothing. The email is delivered as normal, but reports are still sent to your rua address.	Starting out. You want to monitor who is sending email as your domain before enforcing anything.
p=quarantine	Failures are sent to the recipient's spam or junk folder.	Intermediate step. You have reviewed your reports and are confident that legitimate senders are passing.
p=reject	Failures are blocked entirely. The receiving server refuses the message.	Full enforcement. This is the goal, and the only policy that fully prevents spoofing.

Most organisations should start with p=none and work their way up to p=reject over a period of weeks or months. Jumping straight to reject without monitoring first risks blocking legitimate email from third-party services you may have forgotten about (marketing platforms, ticketing systems, invoicing tools).

Our 2026 audit of 192 UK MSPs found that only 36% have reached full DMARC enforcement, which illustrates how many organisations still have work to do.

What does a DMARC record look like?

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here is an example:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r;

Here is what each tag means:

Tag	Value	Meaning
v	DMARC1	Protocol version. Always DMARC1.
p	quarantine	Policy for the domain (none, quarantine, or reject).
rua	mailto:[email protected]	Address to receive aggregate (summary) reports.
ruf	mailto:[email protected]	Address to receive forensic (failure) reports. Not recommended: forensic reports can expose full message headers and content (GDPR risk), and most receivers ignore the request. Omit this tag unless a specific compliance requirement exists.
pct	100	Percentage of messages the policy applies to. Leave at 100 (the default). We do not recommend ramping pct as a rollout strategy because it hides real sender problems behind a probability.
adkim	r	DKIM alignment mode. "r" is relaxed (subdomains allowed), "s" is strict (exact match only).
aspf	r	SPF alignment mode. Same as adkim: "r" for relaxed, "s" for strict.

You can check any domain's existing DMARC record using our free DMARC Checker.

Setting up your first DMARC record

If your domain does not have a DMARC record yet, here is how to get started:

Verify SPF and DKIM first. Before DMARC can do anything useful, your domain needs a valid SPF record and DKIM signing configured on your mail server or email provider. Use our free SPF Generator and DKIM Generator to build valid records, or follow the instructions from your email provider (Google Workspace, Microsoft 365, Zoho).
Start with a monitoring-only policy. Create a TXT record at _dmarc.yourdomain.com with the following value:
```
v=DMARC1; p=none; rua=mailto:[email protected];
```
Replace the rua address with a mailbox you control, or use a DMARC monitoring service like ShieldMarc that provides a dedicated rua address and processes reports automatically.
Wait for reports. Within 24 to 48 hours, you should start receiving aggregate reports from major mail providers. These reports will show you every IP address that sent email using your domain and whether each message passed or failed SPF, DKIM, and DMARC.
Review and fix legitimate senders. Go through the reports and identify any legitimate services that are failing authentication. Update your SPF record to include their sending IPs and ensure DKIM is configured for each service.
Advance enforcement when the reports are clean. Once every legitimate sender is aligning in your parsed reports and no unresolved unauthorised sources remain, move to p=quarantine. Keep reading reports at quarantine, then move to p=reject on the same gate. Leave pct= at 100 throughout.

Reading DMARC reports

Aggregate DMARC reports arrive as XML files (usually compressed as .zip or .gz attachments). They contain detailed rows for each sending IP, the number of messages sent, and the SPF/DKIM/DMARC results for each. Here is a simplified snippet of what the raw XML looks like:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>127</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

If you need to read a single report right now, our free DMARC Report Viewer lets you drag and drop an XML, gzip, or ZIP file and instantly see it in a human-readable table, entirely in your browser with no data uploaded.

Reading individual reports works for a one-off check, but it quickly becomes unmanageable once you have multiple domains and dozens of sending services. ShieldMarc automates the entire process: it ingests your aggregate reports, parses every XML file, and presents the data as clear dashboards showing pass/fail rates, sender breakdowns, alignment trends over time, and alerts when new failures appear.

The free tier includes continuous monitoring for one domain with DMARC report parsing, SPF and DKIM validation, and SSL certificate tracking. It is enough to see the full value of automated report analysis before scaling to additional domains.

Common mistakes

These are the pitfalls we see most often when organisations deploy DMARC:

Not setting up SPF and DKIM first. DMARC depends on SPF and DKIM. Publishing a DMARC record without these in place means every email will fail alignment checks. Always confirm both are working before adding DMARC.
Jumping straight to p=reject. Moving to full enforcement without a monitoring period will block legitimate email from services you forgot to authorise. Start with p=none, review reports, then progress.
Not monitoring the rua reports. Publishing a DMARC record with a rua address and then never reading the reports defeats the purpose. The reports tell you what is happening. Without them, you are flying blind.
Forgetting subdomains.By default, subdomains inherit the parent domain's DMARC policy, but you can (and should) set an explicit subdomain policy using the sp= tag. Without it, attackers may spoof subdomains like billing.yourdomain.com even if the root domain is protected.
Not protecting parked and alias domains. Every domain you own can be spoofed, even domains that never send email. Parked and alias domains should have v=spf1 -all and p=reject from day one. See our guide on how to redirect parked domains for the full setup, including web redirects and email security.

Next steps

Now that you understand how DMARC works, here is where to go next:

Check your domain's DMARC record now with our free DMARC Checker to see where you stand today.
Check your Security Grade to assess SPF, DKIM, DMARC, and more in a single scan.
Build your records with our free DMARC Generator, SPF Generator, and DKIM Generator.
Read our 2026 UK MSP DMARC audit to see how the industry is progressing towards enforcement.
Learn how to secure parked and alias domains with redirects, SPF, and DMARC reject policies.

Ready to protect your domain?

Start by checking your current DMARC setup with our free DMARC Checker. If you want ongoing monitoring, aggregate report analysis, and a guided path from p=none to p=reject, create a free ShieldMarc account and start monitoring your first domain in under two minutes.