How to Fix a Weak DMARC Policy

If a domain security scan has flagged your DMARC policy as too weak, your domain is not fully protected against email spoofing. This guide explains what the finding means, why it matters, and exactly how to fix it — without breaking your email delivery.

What this finding means

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers what to do when an email claiming to come from your domain fails authentication. There are three policy levels:

• p=noneMonitor only. Unauthenticated emails are delivered anyway. No protection.
• p=quarantineSuspicious emails go to spam. Partial protection.
• p=rejectUnauthenticated emails are blocked entirely. Full protection.

If your scan shows p=none or p=quarantine, your domain can still be spoofed. Attackers can send phishing emails that appear to come from your domain and many recipients will receive them.

Why it matters

Email spoofing is one of the most common vectors for business email compromise (BEC) fraud. If your DMARC policy is p=none, anyone can send email pretending to be you@yourdomain.com — and it will be delivered. Since 2024, Google and Yahoo also require p=quarantine or stricter for domains sending bulk email, making enforcement a deliverability issue as well as a security one.

Before you change anything

Moving to p=reject immediately can break legitimate email delivery if your SPF and DKIM records don't cover all your sending sources. Before tightening your policy:

1. Make sure your DMARC record includes a reporting address (rua=) so you receive aggregate reports
2. Check your DMARC reports for any legitimate sources that are failing authentication
3. Ensure SPF covers every service that sends email on your behalf (e.g. Microsoft 365, Google Workspace, Mailchimp, Salesforce)
4. Ensure DKIM is configured for your primary mail platform

If you're not confident all your sending sources are authenticated, start at p=quarantine; pct=10 and increase gradually.

How to fix it — step by step

Step 1: Find your current DMARC record

Your DMARC record is a DNS TXT record at _dmarc.yourdomain.com. It looks something like:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Step 2: Update the policy value

Change p=none or p=quarantine to p=reject. A complete recommended record:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1

• rua= — where aggregate reports are sent (daily XML summaries)
• ruf= — where forensic reports are sent (per-failure detail)
• fo=1 — generate a forensic report on any authentication failure

Step 3: Update the DNS TXT record

Log in to your DNS provider and update the TXT record at _dmarc.yourdomain.com with the new value above.

Step 4: Wait for propagation

DNS changes can take up to 48 hours to propagate globally, though most providers update within a few minutes to an hour.

Verify it worked

Run a new scan on your domain at mydomainrisk.com — the DMARC finding will show as resolved and your score will increase. You can also check using a DNS lookup:

nslookup -type=TXT _dmarc.yourdomain.com

Still seeing failures after tightening your policy?

If legitimate emails start bouncing after moving to p=reject, your DMARC aggregate reports will show which sources are failing. Common culprits are third-party services like CRM platforms, marketing tools, or helpdesks that send email on your behalf but aren't listed in your SPF record.