Cribado-DMARC

The DMARC aggregate-report sieve.

Every large mail receiver will send you XML about every message that claims to come from your domain — who sent it, from where, and whether it passed authentication. Almost nobody reads it, because it arrives as zipped XML by email. Cribado-DMARC reads it for you and turns it into plain warnings.

On its way — deployed; the production mail path is the current work

🤖 This page was written by an LLM, on the ideas, instruction, and editing of humans. AI-written text here is always marked, visibly, like this — that's factor X.

DMARC is the protocol that lets a domain say "reject mail that fails authentication" — the thing that stops phishing sent as you. But nobody turns enforcement on blind: first you watch the aggregate reports to learn who legitimately sends as your domain, then you tighten. The reports are the feedback channel, and like CSP's, it usually stays dark. Cribado-DMARC is the listener: point your domain's DMARC record at it, and the sieve does the rest.

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@<your-cribado-dmarc-address>"

Same premise as the rest of the family: a report stream is a dedup problem, not a logging problem. A thousand rows of XML about the same sending source is one fact with a counter. Store the fact once, and watch for the handful of changes that matter.

How it works

From zipped XML nobody reads to warnings anybody can act on.

Reports arrive by mail — straight to the binary

DMARC reporting is mailto-only in practice, so email is unavoidable; the only question is who speaks SMTP, and the answer is Cribado-DMARC itself. A small inbound-only listener lives in the binary, and your domain's MX points straight at it — no relay, no third-party mail service in the path.

Unpack, parse, deduplicate

Each report is unzipped, parsed, and folded into counted facts per sending source — alignment rates, volumes, first-seen dates — instead of a mailbox of attachments nobody opens.

Plain warnings

A new server started sending mail as your domain. Mail from this source is failing authentication. You're safe to tighten your policy. Deterministic rules over the counted facts — the loudest warning is real mail failing while your policy says reject.

The trade-off, stated plainly

Cribado-DMARC's operators can read every report it stores. On purpose.

The same deliberate deviation from CARLOS server-blindness that Cribado-CSP makes, for the same reason: the product is analytics over the data, and aggregate reports are operational telemetry about your own mail flows. Enumerated, justified, published, never hidden — and no end-to-end encryption claimed.

Status

Fewer claims, all of them checkable.

On its way. The binary — SMTP ingest, parsing, warnings, and the dashboard — is built, and the app is deployed with its dashboard live; wiring up the production mail path (the MX record, the port the listener answers on, the STARTTLS certificate) is the current work, so no reports flow yet. Like its sibling, Cribado-DMARC exists to watch its makers' own domains first. The source is not yet published; the licence is being decided before first publication, and open source is the family default — not optional, only deferred. When that changes, this page will link to it.