Docs
Upload or ingest DMARC aggregate reports, inspect SPF and DKIM alignment, label known senders, and find unknown sources before enforcement.
DMARC reports show which IPs are sending as your domain, whether SPF or DKIM aligned, and what receivers did with messages that failed policy.
The DMARC dashboard supports upload-based analysis and mailbox-based ingestion for teams that want recurring visibility. It separates aggregate RUA analytics, forensic RUF samples, and SMTP TLS-RPT transport reports so each report type is interpreted correctly.
Upload XML, gzip, zip, or EML aggregate reports to populate alignment rate, failures, volume, dispositions, report history, and sending sources.
Authentication-failure samples are routed separately so they do not distort aggregate volume or alignment charts.
SMTP TLS-RPT JSON reports show successful and failed transport-security sessions separately from DMARC policy results.
After reports are parsed, use labels, source ownership, rollout planner, and alerts to decide whether a source is legitimate, broken, or unknown.
Mark known providers, owners, service types, and notes so unknown-source noise drops over time.
Use aligned volume, failed volume, unknown sources, and disposition outcomes before moving from none to quarantine or reject.
Acknowledge or resolve DMARC alerts and route domain or DMARC findings to notification channels.
Authentication owner
A DMARC checker can confirm a record exists. Monitoring answers the operating question: which services are sending as the domain, whether SPF or DKIM aligns with the visible From domain, and whether enforcement would block legitimate mail.
Use RUA reports to see source IPs, header From domains, SPF/DKIM outcomes, alignment, counts, and receiver disposition.
Separate forgotten SaaS tools, ESP migrations, forwarders, and abuse before tightening policy.
Move from p=none to quarantine or reject only after legitimate senders are visible and aligned.
Alignment matrix
DMARC requires alignment with the visible From domain. WillItInbox should explain both raw authentication and aligned authentication so teams fix the right identity, not just any passing record.
| Signal | What passes | What DMARC needs | Common fix |
|---|---|---|---|
| SPF | Envelope sender / Return-Path is authorized. | Envelope domain aligns with visible From domain. | Configure a custom bounce domain or aligned return path. |
| DKIM | A signature verifies for the d= domain. | DKIM d= domain aligns with visible From domain. | Sign with the From domain or an aligned organizational domain. |
| DMARC | At least aligned SPF or aligned DKIM passes. | Policy and reporting are published for the From domain. | Fix sender configuration before increasing enforcement. |
Checker vs monitoring
The free tools are intentionally narrow. They are excellent for checking publication quickly, while the monitoring workflow records whether real senders align over time.
| Question | Best first page | Why |
|---|---|---|
| Is my DMARC record published? | /tools/dmarc-checker | It inspects policy, subdomain policy, percentage, and reporting tags. |
| Is my SPF record structurally risky? | /tools/spf-checker | It checks the visible SPF record and lookup-producing mechanisms. |
| Which services send as my domain? | /tools/dmarc-monitoring | Aggregate reports expose source IPs, alignment, volume, and dispositions. |
| Can I move to quarantine or reject? | /blog/dmarc-quarantine-vs-reject | Policy changes need sustained aligned legitimate volume and low unknown-source risk. |
Readiness checklist
DMARC failures can break invoices, password resets, product emails, marketing sends, and support workflows. The checklist should be boring on purpose.
Ongoing risk
DNS records drift, providers rotate infrastructure, new SaaS tools start sending mail, and old senders remain in SPF longer than anyone remembers. Monitoring turns those changes into visible events before they become support tickets or provider blocks.
Track SPF, DKIM, DMARC, MX, TLS, PTR, blocklist drift, ramp guidance, and provider reputation evidence in /domains.
Use /dmarc to label sources, find unknown senders, and move toward enforcement safely.
Use /placement for diagnostic seed testing when placement needs a sample beyond technical scoring.
Review rhythm
Review domain scans, DMARC source labels, failed alignment volume, unknown senders, blocklist signals, provider reputation snapshots, compliance status, and recent deliverability reports.
Plan model
WillItInbox plans are easiest to understand when the metered usage stays simple: deliverability tests, email validations, API calls, and bulk CSV rows. Monitoring, webhooks, workspaces, branded reports, placement diagnostics, and trust-layer APIs are shown as feature access until those surfaces need explicit capacity counters.
Newer surfaces
The pricing page should stay scannable. The docs and feature pages should explain what the newer surfaces do, what evidence they produce, and where they fit in a sender's workflow.
The DMARC docs explain DMARC aggregate/RUF/TLS-RPT separation, mailbox ingestion, source labels, forensic-report handling, and alerts.
Connect Google Postmaster for read-only domain evidence, compliance status, and latest Gmail-side reputation snapshots.
Diagnostic seed tests, schedules, user-authorized SMTP sends, and provider heatmaps are documented as evidence, not a placement guarantee.
DSN bounce ingestion, ARF complaint ingestion, and suppression-aware validation are API-backed workflows for operational hygiene.
Related
Inspect policy publication before reading aggregate reports.
Check sender authorization before diagnosing alignment.
See how SPF, DKIM, and DMARC evidence becomes a fix plan.
Compare monitoring, reports, validation, and workspace limits.
Open the public tool that helps diagnose one part of dmarc monitoring and sender authentication.
Read the supporting guide for practical context around dmarc monitoring and sender authentication.
Track DNS, TLS-RPT, provider reputation, and placement signals for the domains that carry production mail.
FAQ
No. DMARC monitoring identifies sender inventory, alignment, policy, and authentication risk. Inbox placement also depends on reputation, engagement, recipient history, content, and provider behavior.
Not for this batch. Use the authentication diagnosis example and DMARC monitoring pages until backend capability, search demand, and conversion value justify a dedicated DKIM checker.
Critical production domains should be checked at least weekly and after any ESP, DNS, or security change. High-volume senders often benefit from daily checks.
No. Google can return empty or unavailable domain stats until the verified domain has enough Gmail traffic. WillItInbox treats that as a no-data state rather than a deliverability guarantee or failure.
No. WillItInbox exposes four clear usage quotas today: tests, validations, API calls, and bulk rows. Other workflows are handled as feature access or beta access unless a concrete capacity limit is added later.
Placement tests provide diagnostic seed evidence, and trust-layer APIs provide operational ingestion and suppression evidence. Neither should be described as a guarantee of inbox placement or compliance certification.
