DMARC audit checklist: what to check and how

Q: What if the audit finds no DMARC record at all?

The fix is to publish a starting record at _dmarc. with p=none and a monitored rua= address, following NCSC's recommended first step: Parked or non-sending domains are the exception: they have no legitimate senders to find, so NCSC's parked domain guidance recommends p=reject for them straight away, and ShieldMarc's guide to DMARC for parked domains covers the NULL MX and SPF -all specifics. For domains that send mail, the next step is not to jump straight to reject: use the monitoring period to see legitimate senders first.

A DMARC audit checklist confirms that every domain publishes one valid DMARC record, that SPF or DKIM aligns with the From domain, that aggregate reports arrive, and that policy has moved past monitoring. This article sets out that checklist, then explains each item: which standard sets it, how to check it, and what a pass looks like. One gap worth watching: a record that validates but was never checked for alignment or a stuck p=none.

Key points

A DMARC record should exist at _dmarc on every domain an organisation owns, including parked ones, not only the domains that send mail; subdomains without their own record are covered by the organisational domain's record.
The record is in force when v=DMARC1 comes first and it carries a recognised p= value with no invalid sp= or np=, or a valid rua= that makes receivers read it as p=none; two records at one name are both discarded under RFC 9989.
RFC 9989 retired the pct tag, so any pct= left in a record should be removed rather than tuned.
DMARC only passes when SPF or DKIM aligns with the From domain, which aggregate reports show but a syntax checker alone cannot confirm.
A DMARC audit needs repeating on a schedule, since new or dropped sending services change what SPF and DKIM need to cover.

Contents

The DMARC audit checklist
Does every domain have a DMARC record, including parked ones?
Is the DMARC record itself valid?
Has the retired pct= tag been removed?
Is rua= set, with reports actually arriving?
Does SPF or DKIM alignment pass for every sender?
Has policy moved past none, with subdomains covered?
How to run this as a recurring review
Start today
Frequently asked questions

The DMARC audit checklist

A DMARC audit confirms 6 things, each covered in its own section below with the standard or guidance behind it.

A DMARC record exists at _dmarc on every domain, including parked ones, with subdomains covered by that record or their own (RFC 9989 s4.5; NCSC)
The record is valid: v=DMARC1 comes first, there is only one record, and p= and any sp= or np= each hold a recognised value (RFC 9989 s4.7, s4.8, s4.10)
The record carries no pct= tag, which RFC 9989 removed (RFC 9989 A.6, s9.3)
rua= points to a monitored mailbox and aggregate reports are actually arriving (RFC 9989 s4.6, s4.7)
SPF or DKIM aligns with the From domain for every legitimate sending source (RFC 9989 s3.2.10, s5.3.5)
Policy is at quarantine or reject, not stuck at none, with sp= and np= set deliberately for subdomains (RFC 9989 s4.7, s7.4)

DMARC audit checklist

DMARC record exists at _dmarc on every domain, including parked ones
Record is valid: v=DMARC1 first, one record only, valid p= tag
No leftover pct= tag (RFC 9989 retired it)
rua= is set and aggregate reports are actually arriving
SPF or DKIM aligns with the From domain for every sender
Policy at quarantine or reject, with sp= and np= set deliberately

Does every domain have a DMARC record, including parked ones?

Every domain an organisation owns should carry a DMARC record, including ones that never send mail. This is NCSC's guidance for all domains, not only ones with an active mailbox.

All of your domains, including parked domains, should have DMARC records in place, regardless of whether the domain is used for email or not. Source: NCSC

The record sits at _dmarc.<domain> as a TXT record, so example.com publishes at _dmarc.example.com (RFC 9989 s4.5).

To check this, list every domain the organisation has registered, including defensively registered names and marketing-only domains, then check the DMARC record on each. The free DNS Lookup tool shows a domain's DMARC record when given the bare domain, such as example.com, with no account needed; it does not accept names containing an underscore, such as _dmarc.example.com.

Parked domains are often the ones skipped, since nobody is watching them for mail problems. ShieldMarc's guide to DMARC for parked domains covers the NULL MX and SPF -all pairing that tells receivers the domain neither sends nor accepts mail.

Passing this item means a single TXT record comes back at the exact _dmarc host for every domain on the list, not only the ones currently sending mail.

Is the DMARC record itself valid?

A valid record starts with v=DMARC1, exact and case-sensitive, as the very first tag, or receivers must ignore the whole record (RFC 9989 s4.7).

A record with no valid p=, or with an sp= or np= value that is not valid, is read as p=none when it has a valid rua= and gets no DMARC processing at all when it does not, so a mistyped sp= or np= value cancels even p=reject. Other syntax errors elsewhere in the record fall back to a default where one exists, or are otherwise ignored (RFC 9989 s4.8, s4.10.1).

Two DMARC records published at the same name are both discarded, as if neither existed there (RFC 9989 s4.10, s4.10.1).

Pro Tip: Query the TXT records at _dmarc.<domain> directly with dig TXT _dmarc.<domain> and count them, since a second DMARC record at the same name makes receivers discard both. Without TXT, dig asks for an A record and shows no DMARC record even when one exists.

To check validity, read the raw TXT record rather than a summarised checker view, and confirm exactly one record starting v=DMARC1;. ShieldMarc's free DMARC checker validates the record against RFC 9989.

Passing this item means one record, the correct tag order, and a recognised p= value of none, quarantine or reject, with any sp= or np= tag also holding one of those three values.

Has the retired pct= tag been removed?

RFC 9989 removed the pct tag entirely and lists it as historic, alongside rf and ri (RFC 9989 A.6, s9.3).

A pct value below 100 left in an old record is still honoured by receivers working to the old rules, so the policy only applies to that share of failing mail. Removing the tag applies the policy to all failing mail, under both the old rules and RFC 9989.

t=y now marks a policy as testing, dropping enforcement one level, and stands in for the retired pct=0 behaviour (RFC 9989 s4.7, A.6). Only receivers that implement RFC 9989 honour it: receivers still working to the old rules ignore t= as an unknown tag and apply the policy in full, so p=reject with t=y still means reject there (RFC 7489 s6.3).

To check, read the raw record text for any pct= tag. ShieldMarc's free DMARC generator has no pct field, so a record built with it never carries the retired tag.

Passing this item means no pct= tag anywhere in the record.

Is rua= set, with reports actually arriving?

Confirming this needs two things: a valid rua= address in the record, and evidence that aggregate reports are actually landing there. The tag is what makes reports arrive, not what makes the record valid; the one exception is a record with no valid p=, or with an invalid sp= or np=, which receivers read as p=none only when it has a valid rua=. Without a valid rua=, receivers that send reports must not send them at all (RFC 9989 s4.6, s4.7).

rua= holds one or more comma-separated mailto: addresses, so reports can go to more than one mailbox (RFC 9989 s4.6). A mailbox at another organisational domain, such as a provider's, an MSP's or another domain the organisation owns, only receives reports if that report domain publishes a TXT record v=DMARC1 at <policy-domain>._report._dmarc.<report-domain>, for example example.com._report._dmarc.reports.example.net, or a wildcard at *._report._dmarc.<report-domain>. Without that record, receivers must ignore the address (RFC 9990 s4).

Reports come only from receivers that choose to send them, only on the days they saw mail, and they name only the last server that handed the mail over. Silence proves nothing: it can mean no problem just as easily as a receiver that never reports at all.

To check, open a raw aggregate report in ShieldMarc's free DMARC report viewer and confirm it names the domain's known senders.

Passing this item means reports are landing at the rua= address regularly and cover the domain's known sending sources, with no large unexplained gap.

Does SPF or DKIM alignment pass for every sender?

DMARC passes only when SPF or DKIM aligns with the From domain: relaxed alignment, the default, needs only the same organisational domain, while strict alignment needs an identical one (RFC 9989 s3.2.10, s4.7, s5.3.5).

Domains publishing p=reject must not rely on SPF alone; they must also apply valid DKIM signatures (RFC 9989 s7.4, s8).

To check, read aggregate report rows for each sending source's SPF and DKIM result and identifier alignment, not just a pass or fail count. ShieldMarc's guide to understanding DMARC reports covers the fields involved; where alignment fails, the guide on why your DMARC is failing works through the causes.

For Microsoft 365 or Google Workspace senders, ShieldMarc's guides to DMARC for Office 365 and DMARC for Google Workspace cover switching on DKIM signing with the organisation's own domain, so that DKIM aligns with the From domain.

Passing this item means every legitimate sending source shows an aligned pass in reports, with no sending source the organisation cannot identify.

Has policy moved past none, with subdomains covered?

NCSC recommends starting at p=none as a monitoring phase, then iterating the policy once legitimate senders are identified.

RFC 9989 cautions that domains whose users might post to mailing lists should not publish p=reject, and that any such domain that still wants p=reject should first publish p=none for at least a month, then p=quarantine for an equally long period, comparing the results (RFC 9989 s7.4).

sp= covers existing subdomains and np= covers non-existent ones. Check that both are set deliberately rather than left to inherit by default, since a missing np= takes the sp= value and a missing sp= takes p= (RFC 9989 s4.7).

Receivers must not reject mail solely because a policy says p=reject, and without other analysis must still treat it as quarantine. Reject is a strong signal, not an absolute guarantee (RFC 9989 s5.4, s7.4).

Passing this item means policy sits at quarantine or reject, with clean reports behind that move and sp=/np= matching intent rather than left to chance. ShieldMarc's guides cover moving from none to reject and choosing between quarantine and reject.

How to run this as a recurring review

Organisations regularly add and remove email sending services as they adopt new tools and retire old ones, so SPF and DKIM configuration drifts unless someone owns keeping it current, as NCSC's continuous improvement guidance notes.

A fixed schedule works well: run the full checklist quarterly, for example, and review aggregate reports continuously in between, so a new or unauthorised sender is caught sooner than the next full pass would find it.

MSPs auditing many client domains need a per-client, systematic pass rather than an ad hoc one. ShieldMarc's guide to DMARC for MSPs covers running that at scale.

ShieldMarc's DMARC health monitor re-reads the record every five minutes and emails only when the effective p= policy changes, which catches regressions between scheduled audits. ShieldMarc has no PSA integration, so MSPs still need to log the review itself in their own ticketing system.

For context, ShieldMarc's UK MSP DMARC Audit Q2 2026 reports that the average UK MSP domain scores a C on the Security Grade.

Start today

Run the free checks first: the DMARC checker and DNS Lookup tool cover checklist items 1 to 3, and neither needs an account. The free Domain Trust Check shows where DMARC sits alongside SPF, certificates and the rest of the domain's Security Grade.

Open a real aggregate report in the free DMARC report viewer to work through items 4 and 5, rua= delivery and alignment.

Where the record is missing or invalid, rebuild it with the free DMARC generator.

Once the checklist passes, the next step is moving from a one-off check to ongoing monitoring and alerts. ShieldMarc's 30-day trial needs no card.

This checklist does not cover everything an audit might need: ShieldMarc has no live SMTP STARTTLS test and no SOC 2 report today, so an audit that also needs either of those should look elsewhere for that piece.

Frequently asked questions

What is a DMARC audit?

A DMARC audit checks whether a domain's DMARC record is valid under RFC 9989, whether SPF or DKIM aligns with the From domain, and whether the policy sits at none, quarantine or reject. It is a point-in-time check against a checklist like this one, not the same as ongoing monitoring, which needs continuous report review to catch new or unauthorised senders. A proper audit covers every domain and subdomain the organisation holds, not only the ones sending mail today.

Does Cyber Essentials require a DMARC audit checklist?

Cyber Essentials does not require DMARC, SPF or DKIM. Anti-spoofing controls sit in separate NCSC guidance, so passing Cyber Essentials is not evidence that a domain is protected against spoofing. ShieldMarc's guide to Cyber Essentials and email security for suppliers sets out which NCSC guidance actually applies to UK public sector suppliers.

What tools do I need to audit DMARC?

A DNS lookup and a DMARC record checker cover the syntax items on this checklist, while a report viewer is needed for the alignment and reporting items. ShieldMarc's free DMARC checker, DNS Lookup and DMARC report viewer need no account. Syntax tools alone cannot confirm alignment passes in practice, since that needs aggregate reports collected over time, and reports only cover the days a receiver actually saw mail.

What if the audit finds no DMARC record at all?

The fix is to publish a starting record at _dmarc.<domain> with p=none and a monitored rua= address, following NCSC's recommended first step:

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

Parked or non-sending domains are the exception: they have no legitimate senders to find, so NCSC's parked domain guidance recommends p=reject for them straight away, and ShieldMarc's guide to DMARC for parked domains covers the NULL MX and SPF -all specifics. For domains that send mail, the next step is not to jump straight to reject: use the monitoring period to see legitimate senders first.

How often should a DMARC audit be repeated?

NCSC's continuous improvement guidance sets no fixed interval; it says to review SPF and DKIM configurations regularly, as organisations add and remove email sending services. Pairing a scheduled full pass, quarterly for example, with continuous report review in between catches most changes as they happen. ShieldMarc's DMARC health monitor re-checks the record every five minutes and emails only when the effective policy changes, catching regressions between scheduled audits.