Look up any domain's DMARC record and read it back in plain English: the policy, whether it is actually enforcing, how alignment is set, and where your reports are going.
A DMARC record tells receivers what to do. It does not tell you who is sending as you, which of them pass, or when something new appears. That arrives in the aggregate reports, as compressed XML, every day, from every receiver.
A DNS TXT record that sets a policy for mail failing SPF and DKIM, and requests reports so you can see who sends as your domain.
Monitoring only. It takes no action on failing mail, and is the safe first step while you gather reports.
For DMARC to pass, the domain in the From header must line up with the domain validated by SPF or DKIM. Alignment is what stops spoofing.
Enter your domain in the box at the top of this page. We read the TXT record at _dmarc.yourdomain from public DNS and decode every tag, so you get the policy, the alignment settings and the reporting addresses without parsing the string yourself.
As a TXT record on the _dmarc subdomain, so the full name is _dmarc.yourdomain.com. That is why looking up the root domain does not show it.
Only as a starting point. It publishes a valid record and gets you reports, but it instructs receivers to do nothing about mail that fails, so a domain sitting at p=none is still spoofable by anyone.
Long enough for the reports to show every legitimate sender passing, which is usually a few weeks for a small business and longer if several departments send mail. Move when the data says so, not on a schedule.
Yes. SPF and DKIM each prove something about a message, but neither tells a receiver what to do when the check fails, and neither requires the From address a human reads to match the domain that passed. DMARC does both, which is the part that actually stops spoofing.
Aggregate reports arrive as gzipped XML, one per receiver per day, and they are meant for software rather than people. Monitoring turns them into a list of who is sending as you and whether it passed.