Dashboard modules

Quick reference

If you only need a one-glance overview, here is the full list. Each module is detailed below.

Dashboard Free

The Dashboard module is the home screen for the selected domain. It answers one question in under five seconds: is anything broken right now? If you only have time to check one screen each morning, this is the one.

What you will see

• Four headline cards at the top: Total messages, Unique sources, DKIM pass rate, and SPF pass rate, all computed across the domain's retention window.
• A Daily statistics table with one row per day: total messages, DKIM pass percentage, SPF pass percentage, and unique sender count. This is the chart you scroll through when looking for a sudden drop or spike.
• A Notifications widget on the right that surfaces alerts the system has raised for this domain (DNS changes, authentication spikes, billing events).
• An Onboarding timeline that appears only before the first DMARC report arrives. It walks you step by step through publishing the right DNS records.

Open it when you start your day, after a DNS change, or whenever a customer reports they did not receive an email and you need a quick health check.

Insights FreePaid for Transport

Insights is where you investigate who is sending mail on your behalf and how their messages are doing. The Dashboard tells you if today is healthy. Insights tells you which sender is causing the trouble.

What you will see

• An Authentication tab with a scorecard showing SPF aligned percentage, DKIM aligned percentage, and inbox pass rate, followed by a daily table broken down by sending source. Each row links through to a per-source detail page.
• A Transport tab (paid plans only) for TLS-RPT data: a delivery scorecard, a per-domain matrix of TLS state, the top MX hosts by volume, and the most recent TLS-RPT reports.
• Per-source pages reachable from the table, where you can drill into a specific sender's IP, hostname, and detected provider.

Open it when the Dashboard shows a pass-rate dip and you need to know which sender to fix first, or when a deliverability issue at a specific provider needs evidence.

Reports Free

The Reports module is the raw inbox of every DMARC aggregate (RUA) report DMARCTrust has parsed for the domain. Each report is one XML file from a receiving mailbox provider, summarising one day of mail flow as that provider saw it.

What you will see

• Stats cards at the top: Total reports, Recent 7d, and Processed.
• A sortable, filterable table listing each report by date, sender organisation, domain, and number of record entries. You can filter by date range, source IP, sender organisation, or domain name.
• A detail view per report with the raw XML available for download, plus the list of message-cluster entries it contains.
• CSV export of the filtered list (paid plans). Useful for compliance archives or feeding a SIEM.

Open it when you want to verify that a specific receiver actually sent its daily report, when you need the raw XML for a support ticket, or when an auditor asks for evidence of what was authenticated on a given date.

Forensics Paid

Forensics shows DMARC failure (RUF) reports, which are message-level samples of mail that failed authentication. Where Reports gives you aggregate counts, Forensics gives you the individual incidents. Not every receiver sends RUF, so volumes vary.

What you will see

• Headline cards: Last 7 days, DMARC failures, and combined SPF/DKIM failures.
• A filter card with start date, end date, domain name, and a failure-type selector.
• A paginated table of forensic samples showing arrival date, failure type, source IP, domain, and sender header. Sortable by date, arrival, domain, or failure type.
• CSV export of the filtered set.

Open it when a phishing campaign is suspected, when you want a concrete example of a spoofing attempt to share with leadership, or when you are investigating a single source IP that the aggregate view flagged.

DNS history Paid

DNS history is your audit log of email authentication DNS records. DMARCTrust polls your DMARC, SPF, and BIMI records on a schedule, stores every version it observes, and confirms each change before logging it. The result is a timeline you can scroll back through.

What you will see

• A Current records section listing the live DMARC, SPF, and BIMI values, with the date each became active and a parsed breakdown (policy mode, alignment mode, include count, IP count, logo and VMC status).
• A Change events list showing the most recent fifty events, with a record-type filter (DMARC, SPF, or BIMI).
• Each event captures the previous value, the new value, and the time the change was confirmed.

Open it when a vendor or admin says they did not change anything but pass rates dropped, when you are preparing a postmortem, or when you need to know exactly when a record went into effect.

SPF Optimizer Pro

SPF records have a hard limit of ten DNS lookups per evaluation. Once you exceed it, every message returns permerror and SPF effectively turns off. The SPF Optimizer counts your current lookups, flattens selected include: mechanisms into raw IPs, and publishes the flattened record under a delegated subdomain that DMARCTrust keeps in sync as your providers' IPs change.

What you will see

• Warnings at the top, where they apply: a re-import notice if a previous DMARCTrust include is already there, a redirect= incompatibility warning, and a lookup-budget warning once the computed total reaches eight.
• A Current SPF record card with the syntax, parsed includes, mechanisms, and the trailing all qualifier.
• The optimiser itself: a list of available includes with each one's flattenability status, the mechanisms you have chosen to keep, a flattening preview, and toggles to enable, disable, or re-import.
• Starter plans see a read-only version of the page describing what the feature does. Pro plans get the full controls.

Open it when a deliverability tool warns that your SPF record returns permerror, when you onboard a new ESP that pushes you near the lookup limit, or when an upstream provider changes its SPF and you want to re-flatten with the new IPs.

Receiver Shield Pro

Receiver Shield is hosted MTA-STS. MTA-STS tells sending mail servers to enforce TLS and to refuse mail if your real MX records are tampered with. The hard part is publishing the policy at https://mta-sts.<your-domain> with a valid certificate, on a schedule. Receiver Shield does that for you behind a Cloudflare custom hostname.

What you will see

• A Status banner reflecting the current lifecycle state: provisioning, active, testing, billing grace, rollback serving, or deprovision pending.
• A Hosted MTA-STS card with the active policy mode (none, testing, or enforce), max age, policy ID, the MX hosts DMARCTrust detected, and the DNS records you need to add at your registrar.
• The TLS-RPT DNS record you should publish so receivers can report TLS failures back to you.
• A Policy history with the ten most recent Receiver Shield events.
• A Recent TLS reports list (up to thirty) and a TLS failure summary that breaks failures down by type and lists the top five MX hosts by failure count.

Caveats. Switching to enforce requires explicit confirmation. Provisioning runs a DNS preflight before talking to Cloudflare and will fail loudly if the required CNAMEs are missing.

Open it when you are rolling out MTA-STS for the first time, when a TLS-RPT report arrives showing failures from a specific receiver, or when you need to roll back from enforce to testing after an MX change.

BIMI FreePaid for VMC ordering

BIMI puts your brand logo next to authenticated messages in supported inboxes (Gmail, Apple Mail, Yahoo, and others). It only works once DMARC is at quarantine or reject, and most providers also require a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). The BIMI module shows where you stand and lets you start the certificate ordering process.

What you will see

• An info banner explaining what BIMI is, with a link to the deeper documentation.
• A Domains table listing each domain with status columns for BIMI, DMARC, and SPF. Each row shows whether a BIMI record was found, whether a referenced VMC is valid, and whether the prerequisite DMARC and SPF records pass.
• A per-domain Order Certificate modal that asks for the domain, certificate type, trademark registration details, evidence the logo has been in use for at least twelve months, and the SVG logo file. Submitting opens a support request to handle the certificate order.

Open it when you are ready to add a logo to authenticated mail, when you want to confirm an existing VMC is still valid, or when DMARC has reached enforcement and you want to take advantage of it visually.

Where to go next

Want to pull this same data into your own tools? See the API reference for endpoints covering domains, sources, statistics, and DNS state.

If a term in this page was unfamiliar, the Email security glossary defines DMARC, SPF, DKIM, MTA-STS, BIMI, alignment, and the rest of the vocabulary in plain language.