DMARC Engine

Look up the DMARC record of almost any company and you will find p=none, published two or three years ago by somebody who had just read an article about it. That record asks receiving mail servers to send reports. It does not stop anyone sending mail as you, and a great many people believe it does. The gap between publishing a DMARC record and being protected by one is where most domains have been sitting for years.

Why it exists

Nobody leaves a domain at p=none out of laziness. They leave it there because the failure mode of tightening too early is that your own invoices, your own password resets and your own recruitment emails stop arriving, silently, and you find out from a customer three days later. Faced with a change that can break the business quietly, most people sensibly do nothing.

That was tolerable until it was not. Google, Yahoo and Microsoft now impose authentication requirements on bulk senders, and PCI DSS 4.0 puts anti-phishing controls in scope for anyone handling card data. So the same organisations that had been deferring the work started needing it on a deadline, usually without anyone in the building who had done it before. The two verticals the product calls out by name are accountants and law firms, both of which send documents people act on financially, and both of which are impersonated for exactly that reason. Alongside them are the managed service providers and IT shops who do this for clients and want partner pricing rather than a seat.

The route from monitoring to enforcement is not clever, it is patient: collect reports for a month, work out which senders fail and why, fix the ones that matter, then tighten in steps you can reverse in five minutes. We wrote that sequence out in full, including the check that has to pass before each step. This product is that sequence with the tedious parts automated and the risky parts made visible.

How it works

There are two surfaces. The public site runs a domain scan and 42 browser tools with no account at all, covering DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, general DNS and phishing checks, resolving records over DNS-over-HTTPS against two independent resolvers so a single resolver's cache cannot produce a confident wrong answer. Nothing is stored, and nothing is asked for.

The signed-in application is where a domain gets managed. The customer adds a domain and points one CNAME at our zone. After that, the DMARC record can be tightened, the SPF include list corrected, the MTA-STS policy published and a BIMI record added without anybody going back to the registrar.

Reports come back in by email and land in an ingest worker.

What arrives	What happens to it	Where it ends up
Aggregate DMARC report, zipped or gzipped XML	MIME parsed, decompressed, sender checked against the allowlist, rows extracted	Raw file in object storage, parsed rows in the database
Forensic RUF report	Same worker, same sender check	Stored against the domain, surfaced in investigations
TLS-RPT report	Same worker	Delivery and TLS failure reporting
Public scan from the marketing site	Two DNS-over-HTTPS resolvers, compared	Nothing retained

From there, alert rules are evaluated on a queue and notifications dispatched by email, Slack or Microsoft Teams, each channel with its own minimum severity, with snoozing and deduplication so an ongoing problem does not become a wall of identical messages. A scheduled worker flattens SPF and republishes it. The dashboard carries the enforcement plan and recommendations, DMARC and SPF drift detection, lookalike domain findings, threat investigations, multi-domain analytics with PDF and CSV export, and scheduled reports.

The decision that shaped it

Hosting the records ourselves is the decision everything else follows from. DNS is where these projects die: every change is a ticket to whoever holds the zone, and the fifth change is the one nobody gets round to. Delegating by CNAME removes four of those five tickets.

It also makes us part of the customer's mail authentication path, which is not a small thing to be. If our zone is wrong, their mail is wrong. It obliges us to keep a scheduled flattener running forever, because SPF allows ten DNS lookups at evaluation time and a company with a CRM, a helpdesk, a marketing tool and two mail providers is already near the limit, sometimes over it without knowing. Flattening resolves the includes down to IP ranges, which fixes the count and creates a record that goes stale unless something keeps republishing it. That is a permanent operational commitment traded for a one-off customer action, and it only works if the automation is treated as load-bearing rather than as a convenience.

The second decision is narrower and more contentious. Reports arrive by email, and anyone can send an email. A forged aggregate report can make a dashboard say a domain's mail is healthy when it is not, which is worse than no dashboard. So ingest accepts reports only from an operator-reviewed list of exact sender addresses and DKIM signing identities. The cost is real: a reporting provider that is not on the list is dropped, and adding one is manual work by a person. We chose incomplete numbers that can be acted on over complete numbers that cannot be trusted.

The free tools are a third choice of the same kind. A scan with no sign-up, no email capture and no form is a deliberate refusal of the usual arrangement, for the same reason we argue that a chat link beats a contact form: a buyer checking a domain at eleven at night wants an answer, not a queue they never agreed to join.

Where it stands today

Live and self-serve, with a 14-day trial at Monitor level and no card required. The plan ladder runs from Free at £0 for a single domain, through Starter at £12 a year and Watch at £5 a month, to Monitor at £19 a month shown against a £39 anchor, Growth at £49 a month for up to five domains and ten seats, and Agency from £9 per domain a month with unlimited domains and reseller pricing. The done-for-you enforcement service, where the move to p=reject is carried out for the customer rather than by them, is a one-time £200 against a £500 anchor. Billing runs through Stripe, and AppSumo lifetime codes are supported as a separate entitlement across three tiers.

What we cannot claim, in order of how much it matters. There is no published customer count, domain count or case study, so anyone judging traction has nothing to judge it on. Whether the done-for-you service has been delivered to real clients, as opposed to being purchasable, is not something we are in a position to evidence here. The anchor prices next to the discounted ones are administrator-configurable display fields, which means the discount is a decision rather than a promotion with an end date, and it could change. Whether the AppSumo listing is live and selling, or whether only the redemption path is built, is likewise unsettled. The 42 tools were inventoried rather than each executed one by one. And the repository README still says the application has 29 endpoints when the current tree has 156 route handlers and 66 pages, which tells you where documentation sits in the priority order.

What this says about how we work

Taking on a customer's DNS is the most consequential thing a small supplier can offer to do, and it is the sort of offer that should be made with the reversal path described first. Every change the platform makes to a hosted record is one a customer can undo by pointing the CNAME somewhere else and publishing their own; that is a deliberate property, not an oversight, and it is the same property we look for when we take responsibility for a client's infrastructure.

The habit underneath both is refusing to build a dashboard that can be lied to. It is easy to accept every report and show a rising green line. Deciding instead that the number has to be defensible, and paying for that decision in manual allowlist work every time a new reporting provider appears, is a small example of the trade we make in most projects. Two of the sites in this portfolio belong to firms in exactly the position described at the top of this page, an accountancy practice and an import and export company, where a forged invoice from a lookalike domain is a plausible bad week rather than a theoretical risk. If you are somewhere similar and want the domain looked at before deciding anything, say so and we will run it and tell you what we find.