How it works
The DMARC record is a TXT record under _dmarc in front of the domain, for example _dmarc.example.com with v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. The protocol is specified in RFC 7489.
A message passes DMARC when SPF or DKIM passes and the domain that was checked matches the visible From address (alignment). In the default relaxed mode the same organizational domain is enough; with adkim=s or aspf=s the domains must match exactly.
The p= policy decides what happens to mail that fails: none only monitors, quarantine sends it to spam, reject refuses it. sp= sets a separate policy for subdomains and pct= applies the policy to a share of messages only; a subdomain without its own record falls under the parent domain’s record.
With rua, receivers such as Google and Microsoft send you daily aggregate reports in XML: which IP addresses sent mail in your name, how many messages, and with what SPF and DKIM results. That data is what lets you tighten the policy without breaking legitimate mail.
Why it matters
Without DMARC, or with p=none, every receiver decides on its own what to do with forged mail in your domain’s name, and quite often it reaches the inbox. Phishing with a client’s real sender address then takes no technical effort at all. Gmail and Yahoo require a DMARC record from senders of more than 5,000 messages a day.
On the flip side, a policy tightened too early hits real mail: if p=reject goes live before the newsletter tool, CRM and shop sign with your own domain, receivers reject exactly those messages. Publishing more than one DMARC record makes receivers ignore all of them.
How to prevent it
- Start with v=DMARC1; p=none and a rua address, and review the reports for a few weeks.
- Give every legitimate sender found in the reports DKIM on your own domain or a matching return path.
- Raise the policy step by step to p=quarantine and then p=reject, using pct stages if needed.
- Do not set sp weaker than p, so subdomains do not become a loophole.
- Lock down domains that never send mail right away with p=reject and v=spf1 -all.
- Keep a single DMARC record per domain.
How DomainWarn detects it
The DMARC check queries the domain’s _dmarc record and checks syntax, policy, pct, reporting address and subdomain policy. A missing record opens a “DMARC missing” incident after a single run, and multiple records are critical. p=none, p=quarantine, pct below 100, a missing rua address and a weaker subdomain policy are hints; syntax errors such as a missing or invalid policy are warnings. Change detection reports a weakened policy as a critical change.
For subdomains without their own record, DomainWarn shows the policy inherited from the parent domain. With DomainWarn’s report address in rua, aggregate reports land straight in the dashboard; the DMARC assistant uses them to tell you when the next step toward p=reject is safe and, with a connected DNS provider, applies it after you confirm.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.