DMARC Check — Validate and Audit Your Policy

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is the umbrella over SPF and DKIM. The record at _dmarc.yourdomain.com answers two questions: what should happen to email that achieves neither SPF nor DKIM alignment, and where should reports about such messages be sent?

The key concept is alignment. DMARC does not merely require SPF or DKIM to pass; it requires the domain they validated to match the domain in the visible From header. That closes the gap SPF and DKIM leave open individually: an attacker can send from their own domain with valid SPF and still put your address in the From field — DMARC prevents exactly that.

What AnalyzeMy.Email checks

• Record validity: v=DMARC1 must be the first tag, p= must be present and valid, duplicate tags are detected
• Policy strength: p=none (monitoring only), p=quarantine or p=reject
• Subdomain policy: missing sp= or an sp= weaker than the main policy
• Enforcement: pct<100, pct=0 (effectively disabled) and invalid values
• Cross-check against authentication: an enforced policy with no SPF record and no usable DKIM signature is reported as a serious finding — you would be blocking your own mail
• Reporting: missing or invalid rua/ruf, correct mailto format, fo= and ri=, plus a warning when there are too many report destinations
• External report destinations (RFC 7489 §7.1): if rua points to a foreign domain, that domain must authorize acceptance via yourdomain.com._report._dmarc.targetdomain.com. This record is actually resolved — without it, compliant receivers simply send no reports
• Alignment modes: adkim and aspf set to relaxed or strict, invalid values
• Org domain fallback for subdomains

The path to p=reject

A DMARC policy is tightened in stages, otherwise you block legitimate senders:

• p=none — observe only and collect reports. Two to four weeks until you know every sending system.
• p=quarantine — unauthenticated mail goes to spam. Observe for another two to four weeks.
• p=reject — unauthenticated mail is rejected. This is the goal and the only state that offers real spoofing protection.

p=none without ever reading the reports is the most common permanent state — and it protects against nothing.

Common failure causes

• No sp=: subdomains do inherit the main policy, but setting sp=none opens every subdomain to attackers.
• pct=0: looks like reject but applies to zero percent of messages.
• rua going nowhere: an external report address without an authorization record means you never receive data.
• Strict alignment too early: aspf=s breaks as soon as a subdomain is used as the envelope from.