RXed AI News

AI to the bone.
An afternoon ↓ architecture v1.0 · 2026-09-04

The spoofing report you are already entitled to: who sends mail as your business

One line of DNS turns on a free daily report from every mail provider; this reads it on your own box for EUR 0

Setup: An afternoon (~2-4 h) Running cost: $0-6/mo (software included) Time saved: none directly — it buys evidence and early warning, not hours: the FBI 2025 Internet Crime Report records USD 3,046,598,558 of business email compromise losses across 24,768 complaints, about USD 123,000 per reported case, and the commercial tools that read the same free reports publish USD 19.99-35.99/month at their entry tiers (dmarcian Basic, EasyDMARC Plus, both billed annually, checked 17/08/2026) with free tiers restricted to non-business or 1,000-email use After setup: Runs unattended — parses daily on its own; you only read a message when a new sender appears or a known one starts failing Data lives: Your server — The reports arrive in your own mailbox and are parsed on your own machine. Aggregate reports carry no message content - only sending IP addresses, counts and pass/fail. The optional plain-language step uses a local model, so the list of who mails your customers never leaves the building.
parsedmarccheckdmarcOllamaPython 3an IMAP mailboxGrafanaPostgreSQLEmailSecurityReporting
Built for small businesses in general — not a sector list.
Before you start
  • Access to your domain's DNS settings, or someone who will add one TXT record for you
  • A written list of every service that sends mail with your name on it - the accounting package, the booking tool, the webshop, the newsletter; the whole exercise is only as good as this list
  • A mailbox on your own domain for the reports, and an app password for it
  • Any always-on machine with Python; a mini-VPS at EUR 4-6/month if you have none
What breaks first FAILS SILENTLY
enforcement before the sender list is complete: you move to p=reject and a service you forgot about - the accountant's portal, an old webshop plugin - stops being delivered. The receiver rejects it; you see nothing. This is why the four-to-six weeks at p=none is not optional, and why the same monitoring must keep running after you tighten the policy.
Version history
v1.0 · 2026-09-04 — First release. parsedmarc reading a plain mailbox over IMAP, CSV output, a known-sender diff, and a deliberate four-to-six weeks at p=none before any enforcement.

Every mail provider on earth will send you a daily report naming every server that sent mail in your company's name. You have to ask for it, in one line of DNS, and then something has to read it. That something costs EUR 0 and runs on a box you already own.

The architecture

One line in your domain settingsA mailbox for the reportsevery mail provider sends a daily report, freeThe reader - unzips the reports and listsevery server sending as youwith counts, and whether each one passed the checkscompared against your list of known sendersA sender you do not recognise, usingyour nameYour own invoicing or booking toolquietly failing the checksA dated folder of reports for yourinsurer or your bankStay in listen-only mode for four to six weeks. Enforce before your senderlist is complete and the first thing you block is your own invoice.
the same flow as text
[ DNS: _dmarc.yourdomain ]  v=DMARC1; p=none; rua=mailto:dmarc@yourdomain
        │  you publish this once
        ▼
[ Google · Microsoft · Yahoo · every other receiver ]
        │  one gzipped XML per receiver per day, by email
        ▼
[ dmarc@yourdomain ]  a plain mailbox, nothing special
        ▼
[ parsedmarc ]  reads the mailbox over IMAP, unzips, parses
        ├─ output: aggregate CSV + JSON → reports/
        └─ archives the processed mail, never deletes your evidence
        ▼
[ 30-line diff script ]  sending IPs seen this week vs the known list
        ▼
[ local model (Ollama) ]  one sentence per new sender: who, how much, pass or fail
        ▼
[ Telegram or email ]  +  [ reports/ = your dated record ]

Nothing here listens on the public internet. The only inbound thing is a mailbox you already know how to make. The reports folder is the quiet half of the value: when your insurer, your bank or a customer's IT person asks what you did about domain spoofing, a folder of dated CSVs is an answer and a good intention is not.

The problem

Two things are true about your business email and you have no way of seeing either. First: somebody is almost certainly sending mail that claims to come from your domain. The FBI's 2025 Internet Crime Report puts business email compromise at USD 3,046,598,558 across 24,768 complaints — about USD 123,000 per reported case, and the classic version of it is a supplier invoice that arrives from a name your customer trusts. Second: some of your own quotes and invoices are being rejected or filed as spam, and you find out weeks later when a customer says they never got it. Google and Yahoo have enforced authentication for high-volume senders since February 2024; Microsoft joined on 5 May 2025 with a hard 550 5.7.515 rejection. Those rules are aimed at senders above 5,000 messages a day, so as a small business you are not the target — but you are on the same filters, and the same three DNS records decide whether your mail is trusted. In May 2026 the standard itself grew up: the IETF published DMARCbis as RFC 9989, 9990 and 9991, replacing the 2015 document and moving DMARC onto the standards track. What none of that changes is the basic gap. The reports exist, they are free, they arrive daily, and almost nobody reads them because they are compressed XML.

Tool choices — and why

parsedmarc
(Apache-2.0, 1,291 stars, last commit 03/09/2026, version 11.0.1 released the same day) is the whole engine. It reads reports straight from a mailbox over IMAP, Microsoft Graph or the Gmail API, handles the gzip and zip wrappers the receivers use, and writes plain JSON and CSV. It already parses both the old RFC 7489 schema and the new RFC 9990 one, which matters in a year when receivers are switching. It can also push to Elasticsearch, OpenSearch, Splunk or PostgreSQL for the pretty dashboards — skip that on day one. A running Elasticsearch is more machine than most small businesses want to own, and a CSV per week answers the only two questions you actually have: who is sending as me, and what is failing. Honest caveat, stated by the project itself: it is maintained by one developer. It is Apache-2.0, so if that developer stops, the code is still yours.
checkdmarc
(Apache-2.0, 321 stars, last commit 31/08/2026, same author) is the before-and-after check. Run checkdmarc yourdomain.example and it validates your SPF, DKIM and DMARC records and tells you when the SPF record blows past the ten-DNS-lookup limit. Use it the day you publish the record and again every time you add a new service that sends mail for you.
Ollama
(MIT, 180k stars, active) is optional and does one narrow job: turn "203.0.113.7, 412 messages, SPF fail, DKIM pass" into "a new server in Frankfurt sent 412 messages as you this week and half of them failed one check". It never decides whether something is an attack. The rule engine decides; the model only writes the sentence. Keep it local — the input is a list of who mails your customers, which is not a thing to hand to a third party for the sake of nicer prose.
Grafana
(AGPL-3.0, 76,568 stars, active) with PostgreSQL is the optional trend view once you have a few months of data. Genuinely optional. A folder of dated CSVs and a diff already tell you whether the number of unknown senders is going up or down.
Monthly cost
Software: EUR 0. Hardware: EUR 0 on any always-on machine — the job runs for seconds a day. A mini-VPS is EUR 4-6/month if you have none. The mailbox is one you already pay for. For comparison, the published prices on the commercial side, checked 17/08/2026: dmarcian Basic is USD 19.99/month billed annually for 2 domains and 100,000 messages, Plus is USD 199/month, Enterprise USD 499/month; EasyDMARC Plus is USD 35.99/month billed annually at 100,000 emails and USD 111.99 at a million. Both have free tiers and both are gates rather than products — dmarcian's is non-business domains under 1,250 messages a month and it says it audits those accounts, and EasyDMARC's is 1,000 emails a month on one domain. Those are the vendors' own numbers. Roughly EUR 18-33 a month at the entry tier, for reading an XML file that is already being delivered to you for free.

Setup outline

  1. Write down every service that sends mail with your name on it. Your mail provider, your accounting package, your booking tool, your webshop, your newsletter, the contact form on your site, the garage software, whatever your accountant uses to send you documents. This list is the whole job — steps 2 to 9 only tell you whether the list was complete.
  2. Create a mailbox: dmarc@yourdomain.example. Nothing clever. It will get a handful of messages a day.
  3. Publish one DNS TXT record at _dmarc.yourdomain.example with the value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.example. p=none means "change nothing, just tell me" — it cannot break your mail. That is deliberate and you will stay there for weeks.
  4. Run checkdmarc yourdomain.example and fix whatever it flags in your SPF record before going further.
  5. Wait. The first reports arrive within a day or two, from Google, Microsoft, Yahoo and a long tail of smaller receivers.
  6. On any always-on box: pip install parsedmarc, then a small parsedmarc.ini with a [mailbox] section pointing at the mailbox (host, user, password, archive_folder) and an [general] section with aggregate_csv_filename and aggregate_json_filename. Use an app password, not your real one.
  7. Run it by hand once. Open the CSV. You are looking at one row per sending IP per day with counts and pass/fail for SPF and DKIM. Match every IP against your step-1 list.
  8. Add the cron line — daily is plenty — and keep every output file in a reports/ folder named by date. Never delete them.
  9. Add the diff: a short script holding a text file of known-good sending IPs, comparing this run against it, and messaging you only when something new appears or when a known sender starts failing. Silence is the normal state.
  10. After four to six weeks of a clean report, tighten to p=quarantine, then months later to p=reject if your mail flow is simple. Both are real changes to how your mail is treated. Do them on a Tuesday morning, not a Friday evening.

Pitfalls — what goes wrong when you build this

Jumping to p=reject is how you stop your own invoices
This is the expensive mistake in this field, and it is always the same shape: a service you forgot about — the accountant's portal, the old webshop plugin, the booking tool that mails confirmations "from" you — is not in your SPF record, and the day you enforce, its mail dies silently at the receiver. The four-to-six weeks at p=none is not caution theatre. It is the only way to find the sender you forgot.
Failures in the report are not all attacks
Forwarding breaks SPF by design, and mailing lists break DKIM by design. A customer who auto-forwards your quote to their accountant will show up as a failure. Read the volume and the pattern, not the individual line.
The ten-lookup SPF limit
SPF allows ten DNS lookups; each include: for a service can eat several. Add one service too many and the whole record turns into a permanent error, which fails everything — including mail you sent yourself. This is why step 4 exists, and why you re-run it every time you add a tool.
Sending reports to a different domain needs permission
If your rua= address is on another domain — your IT person's, say — that domain must publish an authorisation record of the form yourdomain.example._report._dmarc.theirdomain.example with the value v=DMARC1;. Without it, conforming receivers simply do not send the reports, and you sit there for a week thinking nothing arrived.
Aggregate reports contain no message content
— only sending IP, counts and pass/fail per day. That is a feature. The separate failure reports can contain message details and most large receivers do not send them at all; do not go hunting for them, and if you do enable them, understand you are asking for other people's mail headers to land in your mailbox.
The standard changed in May 2026, your record did not have to
DMARCbis (RFC 9989, 9990, 9991, published 19/05/2026) keeps v=DMARC1 valid. It drops the old pct= tag in favour of a plain t=y testing mode, adds np= for subdomains that do not exist, and replaces the Public Suffix List with a DNS tree walk. Nothing to do today. Do not let a vendor tell you your record is "out of date" and sell you a migration.
A quiet report is not proof nobody is spoofing you
You only see what receivers who send reports tell you, and the big four cover most but not all of it. It is a very good signal. It is not a camera on the whole internet.

Verified repos

parsedmarc — Apache-2.0, 1,291 stars, last commit 03/09/2026, v11.0.1
checkdmarc — Apache-2.0, 321 stars, last commit 31/08/2026
Ollama — MIT, 180k stars, active (optional, for the plain-language line)
Grafana — AGPL-3.0, 76,568 stars, active (optional trend view, needs a database)
parsedmarc documentation — configuration reference for the mailbox and output sections

Get the next blueprint as it publishes — free, practical, verified tooling only.

Subscribe · Want this audited or extended for your business? DM @RXed_EU