DMARC Policy Enforcement

DMARC tells receivers what to do with mail that claims to come from your domain but fails SPF and DKIM alignment. The policy level is the strength: p=none watches but does nothing, p=quarantine sends failing mail to spam, p=reject blocks it outright. RedScore passes only at quarantine or reject because those are the levels that stop spoofed mail from reaching inboxes.

This check only runs when your domain has a non-null MX. If you have only a null MX or no MX, it shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: a v=DMARC1 record exists at _dmarc.yourdomain.tld with p=reject or p=quarantine.
• Warn: a record exists but p=none. Receivers report on failures but take no action against the mail itself.
• Fail: no DMARC record found at _dmarc.yourdomain.tld.

Fail: no DMARC record. Publish one in monitoring mode

Do not jump straight to p=reject. Your first DMARC record should be in monitoring mode (p=none) with reporting enabled, so you can see who is sending mail "from" your domain and whether they pass alignment before you start blocking anything. Publish a TXT record at _dmarc:

_dmarc.yourdomain.tld.   IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld; sp=none"

rua= is the email address that receives aggregate XML reports from major receivers (Gmail, Microsoft, Yahoo, etc.). Ingest these yourself, or use a managed service (dmarcian, EasyDMARC, Postmark DMARC Digests, Valimail, Red Sift OnDMARC). Without rua=, you have no visibility at all.

Warn: p=none. Graduate to enforcement

p=none gives you reports but does not protect against spoofing. Receivers will still deliver mail that fails alignment. Move to p=quarantine, then to p=reject, in stages.

Phased rollout

• Two to four weeks at p=none: collect reports. Identify every IP and signing domain that sends mail "from" you. Confirm legitimate senders all pass SPF or DKIM alignment.
• Fix alignment failures: add missing senders to SPF, get them to sign with DKIM under your domain, or stop them sending from your domain.
• Move to p=quarantine; pct=10 (apply quarantine to 10% of failing mail). Watch reports for two weeks. Look for new failures or user complaints.
• Increase pct gradually: 25, 50, 100. Each step is two to four weeks of monitoring.
• Move to p=reject; pct=100. Full enforcement. Continue monitoring reports indefinitely.

_dmarc.yourdomain.tld.   IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.tld; sp=quarantine; adkim=s; aspf=s"

_dmarc.yourdomain.tld.   IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.tld; sp=reject; adkim=s; aspf=s"

What the tags mean

• p=: policy for the apex (none, quarantine, reject).
• sp=: policy for subdomains. Set this explicitly to match p=, otherwise subdomains inherit a weaker default depending on the receiver.
• rua=: aggregate reports. Always set this; it is your only visibility.
• ruf=: forensic (per-failure) reports. Most major receivers no longer send these for privacy reasons. Skip unless your reporting platform asks for it.
• pct=: percentage of failing mail to apply the policy to. Lets you ramp up cautiously. Defaults to 100 if unset.
• adkim=, aspf=: alignment strictness. s (strict) requires the From: header domain to match exactly; r (relaxed) allows organizational-domain matches. Strict is preferred when feasible.

Verify the fix

• Run dig +short TXT _dmarc.yourdomain.tld @1.1.1.1 and confirm exactly one v=DMARC1 record is returned.
• Send a test message from each legitimate sender to a Gmail address. "Show original" reveals dmarc=pass or dmarc=fail explicitly.
• Once aggregate reports start arriving (typically within 24-48 hours of publishing rua=), confirm every legitimate sender passes alignment.
• Re-run the RedScore lookup. The verdict moves to pass only at p=quarantine or p=reject.

Common pitfalls

• Jumping straight to p=reject. Legitimate mail bounces and the business breaks. Always go through p=none monitoring and a pct= ramp first.
• No rua=. You publish a policy with no visibility into what it is doing. Receivers cannot warn you about failures and you cannot diagnose problems.
• Missing sp=. Without an explicit sp= tag, subdomain policy depends on receiver implementation. Set sp= to match p= (or stricter) so subdomains are explicitly covered.
• Multiple DMARC records. Like SPF, DMARC allows exactly one record at _dmarc. Two or more makes the entire DMARC record permerror.
• Forwarders breaking alignment. Mailing lists and personal forwarders (Gmail "Forward All", iCloud aliases) rewrite mail in ways that break SPF and sometimes DKIM. ARC sealing helps; if you see significant fail traffic from forwarders, raise it with the operator.
• Reporting address on a non-DMARC-compliant domain. Some receivers refuse to send rua reports to addresses on domains that themselves fail DMARC. Use a domain that already passes DMARC for the reporting mailbox.