What is DMARC? A Complete Guide to Email Authentication

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol you publish as a DNS TXT record at _dmarc.example.com. It tells receiving mail servers (such as Gmail, Outlook or Yahoo) what to do with mail that uses your domain in the From address when neither SPF nor DKIM passes for that domain: monitor only (p=none), send it to spam (p=quarantine) or refuse it (p=reject). With an rua= address, receivers that report send you a summary, usually daily.

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 your DMARC record has an rua= address, receivers that support reporting, including the largest mailbox providers, send a daily summary of the mail they saw using your domain: whether it passed or failed, and which IP address sent it. Smaller receivers may send nothing, so a quiet day is not proof that no mail was sent. 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 side-by-side comparison of all three protocols, see SPF vs DKIM vs DMARC below.

• 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:

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.

SPF vs DKIM vs DMARC: what is the difference?

SPF says which servers may send mail for a domain. DKIM signs each message, so a receiver can check which domain signed it and that it was not changed after signing. DMARC checks that at least one of the two passed for the domain in the visible From address, tells receivers what to do when neither did, and asks them to send you reports. In short, SPF and DKIM authenticate; DMARC enforces and reports. A domain that sends email needs all three.

What each one cannot do on its own

• SPF checks the envelope sender, not the From address people see. An attacker can pass SPF with their own domain in the envelope while showing yours in the From header. SPF also breaks when mail is forwarded, because the forwarding server's IP is not in your record, and a record that needs more than 10 DNS lookups returns a permanent error (PermError) instead of a pass. The SPF Flattener page covers the limit and how to get back under it.
• DKIM proves who signed, not who the From address claims to be. Anyone can sign mail with a domain they control, so a message signed by an attacker's own domain can still show yours in the From header. DKIM also says nothing about what a receiver should do when a signature fails, and it breaks when a mailing list rewrites the subject line or adds a footer.
• DMARC has no check of its own. It only reads whether SPF or DKIM passed and aligned with the From domain, so a domain with neither in place fails DMARC on its own legitimate mail. At enforcement, DMARC lets receivers block mail that uses your domain in the From address and fails authentication. It does nothing about lookalike domains or display-name tricks.

SPF and DKIM break in different places: SPF on forwarding, DKIM when a mailing list changes the message. Publish both, and DMARC has two chances to find an aligned pass, so when one breaks the other can still carry legitimate mail through.

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:

Most organisations should start with p=none and advance to p=reject only once aggregate reports show every authorised sender aligning. The gate is report cleanliness, not the calendar. 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 Q3 2026 audit of 192 UK MSPs, scanned on 16 October 2026, found only 39% of their main domains at p=reject: even the companies that run email for others still have work to do.

What does a DMARC record look like?

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

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r;

Here is what each tag means:

Some older guides add a pct= tag to apply the policy to only some of the mail that fails. Leave it out. The current standard removed the tag in May 2026 (RFC 9989, Appendix A.6). Receivers that still follow the older RFC 7489 honour a value below 100, so the rest of your failing mail gets the next weaker policy. If your record still has pct= below 100, remove it and set p= to the policy your reports support.

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:

1. 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). If you are on Microsoft, our DMARC for Office 365 and Microsoft 365 guide gives the exact records to publish and where to find them.
2. Start with a monitoring-only policy. Create a TXT record at _dmarc.example.com with the following value:

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

   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.

3. Wait for reports. Within 24 to 48 hours, you should start receiving aggregate reports from major mail providers. They show the IP addresses that sent mail using your domain and whether that mail passed or failed SPF, DKIM and DMARC. Reports come from receivers that send them, on days they see your mail. A quiet day is not proof that nothing was sent.
4. 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.
5. 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.

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 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 and alignment trends over time. For each sender it shows SPF and DKIM alignment, why a failing sender fails, the fix steps for its provider and a risk rating.

The free Starter tier covers one domain and up to 10,000 DMARC messages a month. That domain's aggregate reports are parsed onto the Email reports page and kept for 365 days, with one SSL certificate monitor. DNS, DKIM and the other monitors, scheduled reports and Ask AI come with the paid plans and the 30-day trial.

How many organisations actually publish DMARC?

As of 24 October 2026, ShieldMarc’s UK public sector DMARC tracker found that 79.2% of the 7,908 .gov.uk domains it measured publish a DMARC record, and 53.2% are at enforcement (p=quarantine or p=reject): 49.1% of parish and town councils and 67.1% of all other bodies.

We measure every domain in the UK government’s official .gov.uk register every hour. Since the first full scan on 27 July 2026, the share with no DMARC record at all has fallen 2.0 points to 20.8%, and the enforcing share has risen 1.4 points. The 53.2% at enforcement is 67.1% of the domains that publish DMARC.

The more revealing figure is reporting. As of 24 October 2026, ShieldMarc’s tracker found that 41.6% of the domains that publish a DMARC policy send their aggregate reports nowhere at all: 50.1% of parish and town councils and 12.9% of other bodies. They have the record but no rua address, so nobody in those organisations can see who is sending mail as their domain, whether spoofing is happening, or whether their own legitimate mail is failing authentication. An enforcing policy with no reporting still asks receivers to act, but nobody sees what it catches or breaks.

That is why the order matters: publish p=none with a reporting address first, read what comes back, and only then move to quarantine and reject.

Current figures, the per-body-type breakdown, and any individual domain are on our UK public sector DMARC tracker, which re-measures every domain every hour and is free to cite. About three in four entries in the register (6,107 of 7,912 in October 2026) are parish, town and community councils or parish meetings, so an estate-wide figure is mostly a statement about small local bodies. That is why the figures above are split.

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 can 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 cannot see who is sending as you.
• Forgetting subdomains. Subdomains inherit the parent domain's DMARC policy unless they publish a DMARC record of their own, so a protected root also covers billing.example.com. Use the sp= tag when subdomains need a different policy, for example sp=reject when none of your subdomains send mail. Check that no subdomain publishes a weaker record of its own, because that record overrides the parent.
• 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, DMARC, and more in a single scan.
• Build your records with our free DMARC Generator, SPF Generator, and DKIM Generator.
• Read our Q3 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.