Google and Yahoo enforce DMARC for bulk senders
Verifox collects your DMARC aggregate reports, parses the raw XML into a source-by-source view, and tracks SPF and DKIM alignment for every service that sends as your domain. Watch the pass rate climb, then enforce with proof instead of hope.
yourdomain.com: 4 sending sources this week
1 unauthorized
Feb 2024
Google + Yahoo began enforcing DMARC
p=reject
The only policy that stops spoofing
5 weeks
Typical supervised path from p=none
1 domain
Monitored free, no card required
The keyword, answered
Every major mailbox provider that receives your email sends a daily accounting of it back to you. These DMARC aggregate reports (RUA reports) are gzipped XML files delivered to whatever address sits in the rua= tag of your DMARC record. Inside each one: every IP that sent mail claiming to be your domain, how many messages it sent, and whether each batch passed SPF and DKIM alignment. The data is gold and the format is hostile. A domain of modest size collects dozens of these files a day, and nobody reads raw XML at that rate. A DMARC monitor receives the reports for you, parses them, resolves IPs into named services, and turns a week of attachments into one table: who sends as you, how much, and what passes.
That table is the difference between guessing and enforcing. Publish p=reject blind and you will block real mail, because almost every company has senders it forgot: the billing system, the recruiting tool, the agency that still runs a campaign through Mailchimp. Monitoring surfaces all of them at p=none, where nothing is blocked, so you can fix alignment source by source. Start by running a free DMARC, DKIM, and SPF record check to see your current policy, then let the reports tell you when your alignment rate is high enough to tighten it.
Authentication is one leg of deliverability, not the whole animal. A perfectly aligned domain still suffers if its lists are full of dead addresses, so teams pair this monitor with email verification for hygiene, blacklist monitoring for reputation, and an inbox placement test to confirm where the mail actually lands.
The triple lock
SPF
Identifies the serverSender Policy Framework publishes the list of servers allowed to send for your domain. It breaks the moment a message is forwarded, which is why DMARC never relies on SPF alone and why alignment, not a bare pass, is what your reports actually measure.
DKIM
Signs the messageDomainKeys Identified Mail adds a cryptographic signature that survives forwarding. For DMARC purposes the d= domain in the signature must match your From domain. Third-party senders that sign with their own domain pass DKIM but still fail your DMARC.
DMARC
Sets the policyDomain-based Message Authentication ties SPF and DKIM to your visible From address and tells receivers what to do on failure: nothing (p=none), spam folder (p=quarantine), or refuse delivery (p=reject). It also requests the aggregate reports this monitor lives on.
A message passes DMARC when SPF or DKIM passes AND the passing domain aligns with your From address. Test your signature with the free DKIM tester if one source keeps failing.
The policy journey
Each step is gated on your real alignment data, so legitimate mail keeps flowing the whole way. If you are also bringing a new domain online, run email warmup in parallel; authentication and reputation mature together.
Observe at p=none
Weeks 1-2
Publish p=none with a rua= tag pointing at Verifox. Nothing is blocked yet. Within 48 hours the first aggregate reports arrive and the dashboard starts naming every service that sends as your domain, with SPF and DKIM alignment for each.
Tighten at p=quarantine
Weeks 3-4
Fix the legitimate sources that fail alignment: add the ESP's custom return path, sign with your own DKIM key, retire the forgotten tool. When your alignment rate holds steady, move to p=quarantine so unaligned mail lands in spam instead of the inbox.
Enforce at p=reject
Week 5+
With every real sender aligned, publish p=reject. Receivers now refuse spoofed mail outright instead of scoring it. Monitoring keeps running afterwards, because new tools get connected and a policy you stop watching is a policy that silently breaks.
Automatic RUA parsing · Per-source alignment · sp= subdomain coverage · Guided policy moves
What the dashboard shows
Aggregate report parsing
Point your rua= tag at us and every RUA report is collected, unzipped, parsed, and merged into one source-by-source view. You read names and pass rates, not gzipped XML attachments.
Alignment tracking
Per-source SPF and DKIM alignment rates, charted over time. The number that matters before enforcement is right on the dashboard: what percentage of your legitimate mail would survive p=reject today.
Policy advisor
The engine reads your live alignment data and tells you when each move is safe: stay at p=none, step to p=quarantine, or commit to p=reject. No guessing against raw report counts.
Subdomain and sp= coverage
Spoofers love forgotten subdomains (mail, marketing, billing) because most policies never mention them. We track every subdomain seen in your reports and flag the ones your sp= tag leaves exposed.
Spoofing alerts
A new source failing both SPF and DKIM is either a tool someone just connected or an impersonation attempt. Either way you get an alert when it appears in a report, not when a customer forwards you the phish.
Forwarding intelligence
Forwarded mail breaks SPF but keeps its DKIM signature. We separate that pattern from genuine spoofing, so mailing lists and auto-forwards never scare you out of moving to enforcement.
Everything on the dashboard is also queryable over REST: per-source alignment, report history, and policy state, documented in the API reference. Monitoring for your first domain is free; credit rates for verification and the rest of the platform are listed by region on the pricing page.
Common questions
The questions teams ask between publishing p=none and daring to type p=reject: report formats, alignment mechanics, subdomain traps, and what the Gmail and Yahoo rules actually demand.
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.
Add your domain, point the rua= tag at Verifox, and the first parsed reports land within 48 hours. From there the dashboard walks you from p=none to p=reject at the pace your own alignment data supports.
Free monitoring for 1 domain · No card required · 2,500 credits with a work email
