How to: Resolve DMARC policy issues

When to use this guide

Use this guide when the EasyDMARC Domain Scanner (listed in the Domain & server security checklist⁠ ) shows:

DMARC policy is set to p=none , and/or
Risk level is flagged as Medium due to DMARC not enforcing
The DMARC record is missing a rua= reporting address

SPF and DKIM may already be valid. The problem is that DMARC only watches and doesn't yet tell receivers to act on mail that fails them.

How urgent is this? DMARC on p=none is high priority. It means anyone can send emails that appear to come from your domain right now, and recipients will receive them without any warning. For organisations that handle donations or financial transactions, this is a real and active phishing risk.

Who does this?

The person holding the Domains & DNS role in your organisation (via your domain registrar or hosting provider).

For what SPF, DKIM and DMARC each do, see Email authentication⁠ . A DMARC record on p=none only monitors: it doesn't block or quarantine anything. Switching to p=quarantine or p=reject turns on enforcement.

Step 1: Update the DMARC record

In the DNS settings for the domain, find the TXT record named _dmarc.[clientdomain].

Current value (typical):

v=DMARC1; p=none; aspf=r; adkim=r;

Change it to:

v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:THEIR-EMAIL@clientdomain.com

Replace THEIR-EMAIL@clientdomain.com with an address the client monitors regularly (e.g. it@ or beheer@). This rua tag enables aggregate reports showing who is sending email from their domain.

Do not jump straight to p=reject unless you are confident all legitimate mail flows are covered by SPF and DKIM. Start with p=quarantine as a safe intermediate step.

Step 2: Wait and monitor (2–4 weeks)

After the change, check with the client whether any legitimate emails are landing in spam. Ask them to check:

Their own outbound mail (newsletters, notifications, transactional email)
Any third-party tools that send on behalf of the domain (e.g. Mailchimp, Brevo, Salesforce)

Read the aggregate reports

The rua= address from Step 1 starts filling up within a day or two. The reports are XML, one per receiving provider per day, and nobody reads those by hand. Point the client at a tool instead. Any of these does the job:

Tool	Best for	Cost
Cloudflare DMARC Management	Domains whose DNS already sits at Cloudflare. It adds the rua address for you and shows the results in the dashboard.	Free
Postmark DMARC Digests	Anyone. Sends a weekly digest in plain language, so there is no dashboard to remember.	Free
EasyDMARC	Teams who also use the domain scanner from Step 5 and want alerting in one place.	Free tier, paid above it
Palisade DMARC report analyzer	Reading a single report that already landed in an inbox. Parses in the browser, so nothing is uploaded.	Free, no sign-up

Aggregate reports list other organisations' sending IP addresses, so prefer a tool that either receives the reports directly or parses them on your own machine.

What you are looking for in the reports:

Every sender you recognise should pass SPF or DKIM. One of the two is enough.
A sender you recognise that fails both needs fixing before Step 3: add it to SPF, or have it sign with DKIM.
A sender you do not recognise that fails is exactly what p=reject is meant to stop. Leave it.

If no issues arise, proceed to Step 3.

Step 3: Upgrade to p=reject

Once confident, update the DMARC record again:

v=DMARC1; p=reject; aspf=r; adkim=r; rua=mailto:THEIR-EMAIL@clientdomain.com

With p=reject, spoofed emails are fully blocked by receiving mail servers. This is the recommended end state.

Step 4 (optional): Tighten SPF

If the SPF record ends in ~all (soft fail), consider changing it to -all (hard fail) for stricter enforcement:

Before: v=spf1 ... ~all

After: v=spf1 ... -all

Only do this if you are certain all sending sources (Google Workspace, newsletters, CRM, etc.) are already listed in the SPF record. When in doubt, leave ~all in place.

Step 5: Verification

After each DNS change, check the result with the EasyDMARC Domain Scanner .

DNS changes can take up to 48 hours to propagate, though they typically update within an hour.