START HERE. Returns all DMARC monitoring projects for the account with aggregated statistics.

Per project: • Project info — name, projectId, active, contact person, access level (own/shared) • Domain counts — total, paid, parked, excluded, not monitored • Email volume — total messages and three compliance rates for the period: compliancePct — compliant / messages, forwarded mail counts in the denominator only (the conservative floor the web app shows; same definition as in get_domain_full_data); compliancePctNoForwards — compliant / (messages − forwarded): the rate over mail a DMARC policy can actually act on; complianceKnownPct — the same over known sources only (get_domain_full_data's pctFromKnownSources, per domain). The classifier types mail known only when it passes DMARC (on reports parsed since December 2025), so with known mail in the period it reads 100; a period reaching back before December 2025 can read lower. The project's own mail that fails DMARC is classified unknown (forward when it reads as forwarded) and is in neither part, so 100 does not mean its own senders all pass: do not quote it for "is our mail set up correctly". Quote compliancePctNoForwards there, the rate a policy acts on (unknown mail, spoofing among it, included), and read the domains' unknown sources: the sourceReason of the unknown rows in get_domain_source_details (source_type=unknown) says whether to identify the sender, fix the domain's own setup or leave a relay's damage alone. Quote compliancePct when the question is "how much of the mail seen for these domains passes". • Max severity — worst severity across all domains (Unknown/Healthy/Info/Warning/Critical) • Severity breakdown by category (dmarcRecord, spfRecord, dkimRecord, spfAlignment, dkimAlignment, dmarcCompliance, messageVolume) • Policy distribution — domain counts per DMARC policy (none/quarantine/reject/unknown) • dmarcAREmail — DMARKOFF's reporting address of the project. monitoringEmail, when set, is the address published in rua instead: an MSP's own mailbox that forwards the reports to dmarcAREmail. dmarcStatus of the project's domains is checked against monitoringEmail then, and add_domain and generate_dmarc_record put it in the record. • noReports — no report in the period: messages is 0 and the compliance percentages are 0 by convention, not a measured 0% (the web app shows the same zeros). A project whose domains were added recently has no reports for 24–48 h after the DMARC records go live. • noEligibleMail — the period has reports, but all of its mail was forwarded: compliancePctNoForwards has nothing to divide by and is 0 by convention, not a measured 0%. • noKnownMail — the period has reports, but none of its mail (forwarded mail aside) came from the project's known sources: complianceKnownPct is 0 by convention, not a measured 0%. Say that no mail of the period was classified known, not that the project's own senders sent none: their mail that fails DMARC is classified unknown (forward when it reads as forwarded). • missedReports — aggregate reports DMARKOFF received for the project and dropped on arrival, counted per reason: unpaid_domain (the domain was not paid: DMARKOFF keeps at most one report a day of an unpaid domain for 3 days after it was added or became unpaid, then none), excluded (the domain was excluded), parked (the domain was parked: DMARKOFF keeps at most one report a day of a parked domain, one that shows mail), auto_add_disabled (the report named a domain the project did not hold, while adding domains from reports was off). A report is counted on the UTC day it arrived, not the day its mail was sent; the period ends yesterday unless stats_period_end is given. The reason is the domain's state when the report arrived: a domain paid, included, unparked or deleted since still shows up, so a count does not mean any domain is unpaid, excluded or parked now — list_domains has their current state. Absent when no report was dropped or the count could not be read. • period, missedReportsPeriod — the days read for messages and compliance and for missedReports (start, end, days, endClamped: the end asked for was after today); the header line names them too. Both are the same period when stats_period_end is given. • nextStep — set on a project without domains.

Use this first to discover project IDs and identify projects that need attention. Then call list_domains with the project_id to see which domains have problems; for a project without domains go to adding them (add_domain).