kMarc

The problem

If you run your own mail, DMARC aggregate reportssummaries of how receivers handled a domain's mail (summaries of how receivers handled a domain's mail) are how the rest of the internet tells you whether your SPFa DNS policy listing permitted sending hosts (a DNS policy listing permitted sending hosts) and DKIMa cryptographic signature attached to outgoing mail (a cryptographic signature attached to outgoing mail) actually hold up. They arrive as zipped XML attachments in a mailbox nobody readsexcept kMarc, now (except kMarc, now), which is a strange formatzip, inside xml, inside mail (zip, inside xml, inside mail) for information this important. kMarc collects them, keeps them, and turns them into answers.

Architecture

kMarc is a single-package Bun/TypeScript CLI with five commands: sync, watch, summary, report, and export. Each mail source is its own config file describing one mailbox; sync compares server UIDs against SQLite (keyed by source, mailbox, UIDVALIDITYan IMAP mailbox generation identifier (an IMAP mailbox generation identifier), and UID, so a rebuilt mailbox cannot cause false collisions) and fetches only what is new. Watch mode uses IMAP IDLEmail protocol that lets a client wait for new messages without polling (mail protocol that lets a client wait for new messages without polling) where the server offers it, raced against a polling interval so a silent server cannot stall it, with per-source exponential backoff on failure. One malformed "poison" message increments a counter instead of blocking the rest of the queue.

Everything is kept twice: raw RFC 822the standard format for a single email message (the standard format for a single email message) messages and extracted XML artifacts on disk (checksummed, deduplicated by SHA-256, directories created 0700), and a normalized SQLite database for querying. Aggregate retransmissions are deduplicated the way the RFC intends - by reporter organization plus report ID, not just byte identity. Parsing is defensive throughout: caps on mail size, attachment count, ZIP entries, decompressed size, and records per report, because a mailbox that accepts reports from the whole internet is an untrusted input.

kMarc does more than replay the XML. It looks up the live DMARC policy (walking exact domain, organizational domain, and RFC 9091 public suffixa suffix under which the public registers domains, like co.uk (a suffix under which the public registers domains, like co.uk) discovery) and the live SPF record, then classifies each source IP: authorized by which SPF mechanism, at what risk level, with which policy overrides. kMarc renders tables on wide terminals and stacked records under 80 columns, so security-relevant fields never get dropped. Output can be plain text, ANSI, or a standalone responsive HTML report. Exports produce JSON or CSV; builds compile to standalone binaries for Linux, Windows, and macOS.

Boundaries

kMarc reads reports about your mail; it does not touch your mail flow. Deleting processed messages from the remote mailbox is off by default, per-source, and only ever applies to messages that were successfully imported - unrecognized mail is never deleted. It is deliberately a local administrator tool, not a hosted service: credentials, raw reports, and source IPs stay in local files and SQLite, protected by file permissions rather than another login system. It shows you which senders fail alignmentmatching the visible From domain to SPF or DKIM results (matching the visible From domain to SPF or DKIM results) and where legitimate mail leaks past SPF; fixing the DNS records is still your job.