DMARC Monitoring That Makes p=reject Safe.

A DMARC aggregate report is a daily XML file that mailbox providers like Gmail and Yahoo send to the rua= address published in your DMARC record. It lists every IP that sent mail claiming your domain, the message counts, and the SPF and DKIM alignment result for each batch. Verifox receives these reports, parses the XML, and resolves the IPs into named services, so you read a dashboard instead of gzipped attachments.

RUA reports are aggregate: daily per-source counts of messages with pass and fail totals, no message content. RUF reports are forensic: redacted copies of individual failing messages. In practice RUA carries nearly all the value, because most large providers, Gmail included, decline to send RUF for privacy reasons. Verifox accepts both, but every policy recommendation we make is built from your aggregate data, which arrives reliably from every major receiver.

Two weeks is the practical minimum; domains with many sending services need longer. p=none blocks nothing, and its whole job is to collect aggregate reports until every legitimate source is identified and aligned. Move when your alignment rate is stable and high, not on a calendar date; the monitor flags the moment that holds. Start with a free DMARC, DKIM, and SPF check to see which policy your domain publishes today.

Not if they are aligned first. Tools like Mailchimp, HubSpot, and SendGrid send from their own servers, so out of the box they fail SPF alignment. Each one offers the fix: a custom return path for SPF and a DKIM key that signs with your domain. The monitor lists exactly which of your senders would fail under p=reject, so you repair them during the p=none phase while nothing is being blocked.

Since February 2024, anyone sending 5,000 or more daily messages to Gmail or Yahoo must publish a DMARC policy of at least p=none, authenticate with both SPF and DKIM, align the visible From domain, offer one-click unsubscribe, and keep spam complaints under 0.3%. Smaller senders still need SPF or DKIM. Mail that misses the bar gets throttled or rejected, which is why DMARC monitoring stopped being optional for bulk senders.

The sp= tag sets a separate DMARC policy for subdomains; without it, subdomains inherit your p= value. It matters because attackers deliberately spoof forgotten subdomains like mail.yourdomain.com or billing.yourdomain.com, where nobody is watching. Verifox tracks every subdomain that appears in your aggregate reports and warns you when sp=, or a missing record on a delegated subdomain, leaves one of them weaker than your organizational policy.

SPF alignment compares the Return-Path domain with your visible From domain; DKIM alignment compares the d= domain in the signature. A message passes DMARC when either one passes and aligns. The practical difference is forwarding: it rewrites the Return-Path and breaks SPF, while a DKIM signature survives intact. That makes aligned DKIM the backbone of a safe p=reject. If one source keeps failing, the free DKIM tester shows whether its signature validates at all.

pct= applies your policy to only a percentage of failing mail. At p=quarantine with pct=25, a quarter of failing messages go to spam and the rest are treated as p=none. It is a throttle for nervous rollouts. Treat it as a short ramp, not a destination: a long-lived pct below 100 leaves a permanent gap spoofed mail can ride through, and some receivers do not honor the tag at all.

Yes. Monitoring is free for one domain, with unlimited aggregate reports and no card required. Signing up also grants 1,000 free credits, or 2,500 with a work email, usable across the whole platform. Additional domains run on the same pay-as-you-go credits, which never expire, and the pricing page shows rates localized for your region.

Yes. Per-source alignment rates, parsed report history, policy state, and spoofing alerts are all exposed over REST and documented in the API reference. Webhooks push new-source and failure-spike events into Slack or your own tooling, and AI agents can read the same data through the native MCP server. Most teams wire it next to email verification so hygiene and authentication share one pipeline.