Free DMARC Monitoring Tool

Why monitor DMARC reports?

DMARC monitoring tells you who sends mail in your name and which of those messages pass authentication. It is the only way to find out.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) unifies SPF and DKIM to close your domain to phishing and email spoofing. Publishing the record is step one. Without reports, the rest is blind. You have no idea which sources send under your name, whether your legitimate flows really align on SPF and DKIM, or whether a third party is riding your domain to push spam.

Four problems surface in almost every DMARC report audit.

A CRM, a newsletter platform, or a billing tool sends for your domain with no proper SPF or DKIM alignment. The result: spam folder or outright rejection. This is the most common case by far.

Spoofing comes next. Attackers forge your From address for phishing. Without aggregate reports, those campaigns stay invisible until a customer complains.

A botched email migration leaves the old provider sending unaligned mail for weeks. Your compliance rate drops, and nobody understands why.

Then there is shadow IT: an internal team sends without authorization. DMARC reports pull these unknown senders out of the dark.

How DMARC authentication works

DMARC validates that at least SPF or DKIM passes and aligns with the domain in the From header. Two protocols underneath, a single decision on top.

SPF (RFC 7208) and DKIM (RFC 6376) each authenticate a different aspect of the message. SPF checks the sending server. DKIM checks a signature. DMARC makes the call.

It all hinges on alignment. SPF and DKIM both pass, and DMARC still fails when neither aligns with the From domain. Strange? Not really: this is exactly the gap spoofers exploit, and the first failure reports expose.

DMARC also dictates the fate of unauthenticated mail: let it through (p=none), send it to quarantine (p=quarantine), or reject it (p=reject).

How to set up DMARC monitoring in 3 steps

Step 1: Add your domain and verify ownership

Sign in and register the domain you want to monitor. Add the CaptainDNS verification TXT record to your DNS. This verification system is shared across all CaptainDNS services (MTA-STS hosting, TLS-RPT monitoring, BIMI hosting).

Step 2: Configure your DMARC DNS record

The setup wizard analyzes your current DNS state and proposes the exact record to publish:

• No existing DMARC record: a complete record is generated with p=none and our rua= address
• Existing DMARC record: your policy, alignment settings, and existing rua= addresses are preserved; our address is added automatically
• Invalid existing record: the issue is flagged and a clean replacement is proposed

Just copy the host (_dmarc.yourdomain.com) and value, then paste them into your DNS provider.

Step 3: Reports are received and analyzed automatically

Email providers start sending aggregate reports within 24 to 48 hours. CaptainDNS ingests them, decompresses the XML, analyzes authentication results, and displays the findings in your dashboard: compliance scores, source IPs, pass/fail rates, and applied dispositions.

Understanding DMARC aggregate reports

A DMARC aggregate report is an XML file that summarizes, per source IP, every authentication result on your domain over a given window.

Google, Microsoft, Yahoo, and Apple ship them to the address in your rua= tag, usually every 24 hours. Each report covers a period, and each row describes one source that sent using your domain.

RUA vs RUF: aggregate reports vs failure reports

DMARC defines two types of reports:

CaptainDNS focuses on aggregate reports (RUA), which provide the data needed for compliance tracking and source identification. Forensic reports are rarely available in practice.

What does a DMARC aggregate report contain?

Example of a DMARC aggregate report

Here is a simplified extract from a DMARC aggregate report in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1710201600</begin>
      <end>1710288000</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>captaindns.com</domain>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.1</source_ip>
      <count>1547</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <row>
      <source_ip>198.51.100.42</source_ip>
      <count>23</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

The first row shows 1,547 messages from a legitimate source passing both checks. The second row reveals 23 messages from an unknown IP failing both SPF and DKIM, a potential spoofing attempt. CaptainDNS parses these reports automatically and presents the data in your dashboard. To decode a single XML report you received, our DMARC report reader renders its contents in plain view.

DMARC record tag reference

A DMARC TXT record is published at _dmarc.yourdomain.com. Here are the available tags:

Use our DMARC Generator to build a valid record, or the DMARC Syntax Checker to validate an existing one.

From monitoring to enforcement: the path to p=reject

Only p=reject actually blocks spoofing for good. Every forged message gets discarded at the door. Jumping straight to reject without reports is roulette: your misaligned legitimate senders fall too, and their mail vanishes.

Recommended progression:

1. p=none (monitoring only): collect reports for 2 to 4 weeks. Identify all legitimate sources and fix any SPF/DKIM alignment issues. Target: 95%+ compliance rate.

2. p=quarantine (partial enforcement): failed messages are sent to spam instead of the inbox. Use pct=25 initially, then increase to 50% and 100% over 2 to 4 weeks. Monitor for legitimate mail being quarantined.

3. p=reject (full enforcement): failed messages are discarded. Domain spoofing is fully blocked. Start with pct=25, then ramp to 100%.

Timeline: Most organizations complete this journey in 4 to 8 weeks. Do not rush. Each stage should confirm that no legitimate email flow is impacted.

Reaching p=reject also unlocks BIMI (Brand Indicators for Message Identification), which displays your brand logo next to your emails in supporting inboxes.

Google and Yahoo DMARC requirements

Since February 2024, Google and Yahoo refuse mail from bulk senders that have no DMARC published. The threshold: 5,000 messages per day to Gmail or Yahoo.

Four obligations apply at those volumes. You need a DMARC record with at least p=none. SPF and DKIM both have to be configured, not one or the other. The From domain must align with one of the two. And marketing emails have to carry the RFC 8058 one-click unsubscribe.

Without report monitoring, you cannot prove your sources pass these checks or hold the compliance rate over time. Non-compliant senders see their mail deferred with 4xx errors, then rejected. It already happened at scale in spring 2024.

Common DMARC failures and how to fix them

Most DMARC failures come down to six causes: broken SPF alignment, broken DKIM alignment, SPF past 10 DNS lookups, a third party with no authentication at all, an uncovered subdomain, and forwarding that breaks SPF. Each one has a precise fix.

Real-world use cases

Case 1: Identifying a misconfigured third-party service

Symptom: DMARC compliance rate drops from 98% to 72% over one week.

Diagnosis: The dashboard shows a new source IP sending significant volume without DKIM alignment. It turns out to be the new marketing CRM, configured without a DKIM signature for your domain.

Action: Configure DKIM signing in the CRM. Compliance rate recovers in subsequent reports.

Case 2: Detecting domain spoofing

Symptom: Unknown source IPs appear in the reports, sending mail on behalf of your domain with complete SPF and DKIM failure.

Diagnosis: DMARC reports reveal phishing attempts from servers in suspicious jurisdictions. Your p=none policy lets these messages through.

Action: Progressively move your policy from p=none to p=quarantine then p=reject. Subsequent reports confirm fraudulent messages are being rejected.

Case 3: Meeting Google bulk sender requirements

Symptom: Gmail starts deferring your marketing emails with temporary 4xx errors. Delivery rates drop.

Diagnosis: DMARC monitoring shows that your newsletter platform sends mail without DKIM alignment to the From header domain. Google's bulk sender policy requires authentication compliance.

Action: Configure DKIM signing for your domain in the newsletter platform and verify alignment through DMARC reports. Delivery rates return to normal within days.

FAQ - Frequently asked questions

Q: What is DMARC monitoring?

A: DMARC monitoring means receiving and analyzing the aggregate reports (rua) sent by email providers. These reports show which sources send mail on behalf of your domain and whether they pass SPF and DKIM checks with correct alignment.

Q: What is the difference between DMARC aggregate reports (RUA) and failure reports (RUF)?

A: Aggregate reports (rua) are sent daily and contain summarized authentication data per source IP. Failure reports (ruf) are sent for individual message failures and contain more detail including message headers. Most providers only send aggregate reports. CaptainDNS focuses on aggregate report analysis.

Q: How does DMARC work with SPF and DKIM?

A: DMARC builds on SPF and DKIM by adding identifier alignment. SPF validates the envelope sender IP, DKIM validates a cryptographic signature, and DMARC checks that at least one passes with alignment to the From header domain. Monitoring reveals when alignment fails.

Q: What DMARC policy should I start with?

A: Start with p=none to monitor without affecting mail delivery. Once your DMARC compliance rate is consistently above 95%, move to p=quarantine. After confirming no legitimate mail is impacted, set p=reject for full spoofing protection.

Q: How do I set up DMARC monitoring?

A: Add your domain in CaptainDNS, verify ownership via the TXT record, then follow the setup wizard that detects your current DMARC record and proposes the exact update needed. Reports start arriving within 24 to 48 hours.

Q: Is DMARC monitoring free with CaptainDNS?

A: Yes, completely free for 1 domain (upgrade to Starter for 25). No hidden fees, no trial period. Every domain should be able to monitor its DMARC aggregate reports regardless of budget.

Q: Do Google and Yahoo require DMARC?

A: Yes. Since February 2024, Google and Yahoo require bulk senders (5,000+ messages per day) to publish a DMARC record. Monitoring helps you meet and maintain these requirements by tracking authentication compliance.

Q: What happens if I set my DMARC policy to reject?

A: With p=reject, receiving servers discard messages that fail both SPF and DKIM alignment. This fully prevents domain spoofing but can block legitimate mail if third-party senders are not properly configured. Always monitor first with p=none.

Q: How long does it take to receive DMARC reports?

A: Most email providers send aggregate reports every 24 hours. After publishing your rua= address, expect the first reports within 24 to 48 hours depending on your email volume.

Q: What is the relationship between DMARC monitoring and a DMARC record?

A: The DMARC record defines your authentication policy (none, quarantine, reject) and the rua= tag specifies where to send reports. DMARC monitoring analyzes those reports to show you who is using your domain and whether authentication is working correctly.

Complementary tools

Useful resources

• RFC 7489: DMARC, official DMARC specification
• RFC 7208: SPF, Sender Policy Framework
• RFC 6376: DKIM, DomainKeys Identified Mail
• Google: Email sender guidelines, requirements for bulk senders
• Yahoo: Sender best practices, Yahoo authentication requirements
• M3AAWG Best Practices, Messaging Anti-Abuse Working Group recommendations