The DMARC signal nobody watches

There is a category of problem that hosting providers deal with reactively because the tools to deal with it any other way are either expensive, poorly fitted to hosting-provider use, or both. Email deliverability on shared infrastructure is the most visible example. This note is about why we decided to stop dealing with it reactively and build our own observability layer for it instead. We call the tool Provenly, and a working prototype is running now.

The invisible problem

When email deliverability goes wrong on shared hosting, the usual sequence is this. A customer’s account gets compromised or misconfigured or starts sending in a pattern that looks like abuse. The mail flows out of our servers looking wrong. Recipient mail servers start marking the IP with a bad reputation score. Other customers on the same IP start experiencing bounces or spam-folder delivery for their perfectly legitimate email. Someone eventually notices, either because a customer complains loudly enough or because an automated monitor catches the IP appearing on a public blocklist. We investigate, find the source, suspend or fix the offending account, document the remediation, and file delisting requests with the affected reputation services. Recovery takes days to weeks depending on which services were involved.

This is standard operational practice in the hosting industry. It is also profoundly reactive. By the time the reputation damage is visible, it has already happened. The customers who paid the price are the innocent ones sharing infrastructure with the compromised account. The remediation is downstream of the cause by hours or days.

The frustrating part is that most of the causes are visible before the damage occurs, in a place almost nobody looks.

DMARC aggregate reports contain the raw signal. Every mailbox provider that receives email from your domain sends you a daily XML report describing what they saw, what authenticated, what did not, and what they did with it. If you ingest and analyse those reports, you can see:

• A customer’s account starting to send from an unexpected IP, which is often the first signal of a compromised mailbox being used by an attacker
• SPF alignment failures on outbound mail, which indicate misconfigured customer setups or third-party services sending in the customer’s name without proper authorisation
• Sudden volume spikes from specific customer domains, which are usually either legitimate bulk sends done through the wrong channel or the early stage of an abuse campaign
• Forwarders leaking spam through our IPs, showing up as authentication failures at Gmail with our IP in the source position
• Individual customer domains developing reputation problems that will eventually affect the shared IP if not addressed at the source

Why the commercial tools do not fit

The DMARC platform market is dominated by services aimed at large enterprises monitoring a small number of high-value domains: their own corporate email, their marketing subdomain, their transactional email service. Pricing scales by domain, typically ten to fifty dollars per domain per month at the middle of the market, more at the top. For a corporate customer with three domains, this is fine. For a hosting provider with a couple of hundred customer domains, the maths becomes structural.

The tools also assume a different operational shape than a hosting provider has. They are built to help a marketing team optimise their email sending against a small set of tuning parameters. What we need is different: fleet-wide visibility into hundreds of small domains, most of which are not doing anything sophisticated, with alerting on the specific patterns that indicate a compromise or a misconfiguration rather than on the patterns that indicate a marketing team should adjust their sending cadence.

We could adapt a commercial tool to our use case. The cost would be significant, we would be paying for features we do not use, and the tool would still be shaped around its original audience in ways that make our operational workflow harder rather than easier. Or we could build the specific tool we need, in the specific shape our operation needs, at the specific cost of the engineering time to build it.

The engineering time was the real question. DMARC report ingestion is not a research problem. The XML format is documented. The parsing is straightforward. The database schema follows the report structure. The rules for what constitutes a suspicious pattern are known and can be encoded. What we are building is not a novel technology; it is an operational tool that applies known techniques to a specific fleet in a specific way. That is the right kind of thing for a small operator to build in-house rather than to rent from someone else.

What the prototype does now

Provenly currently ingests DMARC aggregate reports for the domains we operate mail for. It parses the XML, stores the underlying records in a queryable form, correlates them with SPF alignment data, and surfaces the results in a dashboard we watch daily.

The specific things it lets us see:

Fleet-wide sending health. At a glance, how much of the outbound mail from our IPs is authenticating correctly at recipients, how much is failing, and which domains are contributing to which category. On a normal day, most domains show clean authentication and consistent volumes. When something starts to go wrong, the pattern shows up before any reputation damage occurs.

Per-domain history. For any specific customer domain, a timeline of what mail has been sent from where, whether it authenticated correctly, and what the receiving mail servers did with it. This turns a customer support conversation about a bounce into a fact-finding conversation with data, instead of an argument about what might have happened.

Anomaly detection. New sending sources appearing for a domain that has previously only sent from our infrastructure. Volume spikes that break from the domain’s normal pattern. Authentication failures clustering around specific customer accounts. Each of these can indicate a real problem, and each can be surfaced from the DMARC data before the reputation cost is paid.

SPF alignment tracking. Whether the SPF records for each domain match the infrastructure that is actually sending. Misalignment is one of the most common causes of legitimate email being flagged as suspicious, and it is entirely fixable once you know it is happening.

The tool does not do everything a mature commercial platform does. It does not yet do forensic reports (the per-message reports that some receivers send in addition to aggregate reports). It does not yet ingest our own mail server logs for one-to-one comparison with what receivers report, though this is on the roadmap. It does not do policy recommendation, DMARC record generation, or the tuning-heavy features that commercial platforms sell to marketing teams. Those may come later if they turn out to be useful. Right now, the point of the tool is to give us fleet-wide visibility into what is actually happening, so we can act on it, and that is what the prototype does.

What this changes for customers

Two things become possible that were not possible before.

The first is preventive reputation management. When a customer’s account starts behaving in a way that will eventually cause reputation damage, we can see it and address it before the damage occurs. In practice this means a proactive support conversation (“we noticed your mail is starting to send from a Microsoft 365 IP as well as our servers; did you set up a new mail service, and should we update your SPF record?”) rather than a reactive incident response (“your email has been bouncing for three days, let us figure out why”). The former is better for the customer, better for us, and better for the other customers who share infrastructure with them.

The second is honest customer-side deliverability support. When a customer asks us why their email is going to spam at some specific recipient, we can now look at what actually happened rather than guessing. The DMARC data shows whether the message authenticated correctly, whether the recipient’s server accepted it, and if not, what the specific failure was. This turns a class of previously unsolvable customer questions (“why does my email keep going to spam?”) into questions with concrete answers (“here is what the recipient’s mail server did with your message, here is why, and here is what needs to change on your setup”).

Eventually, we will offer the tool to customers directly as a service. Not as a bolted-on marketing product, but as a genuinely useful piece of infrastructure for customers who want visibility into their own email deliverability. Pricing will be modest because we built the tool for our own use rather than to fund a SaaS business. A public version will also be available for anyone who wants to check their own domain, because the information the tool surfaces is the kind of thing everyone should be able to see about their own email.

The broader point

Most of what hosting providers do is operational work that customers never see. The infrastructure runs, the mail flows, the incidents get handled. When something goes wrong, the customer notices; when things work, the customer does not think about it. This is the intended state, and it is a good state, but it means that most of the work that distinguishes a competent operator from an incompetent one is invisible.

Occasionally, the work becomes visible in a different way, through the tools the operator builds to do the work better. Provenly is one of those cases. We are building it because the existing tools do not fit our operation, because the alternative is continued reactive incident response on a problem that is at least partly preventable, and because giving ourselves and our customers real observability into what is actually happening on the email side is a durable improvement in the quality of the service.

It is also the kind of thing that a small operator can do that a large consolidated provider structurally cannot. Building a specific tool for a specific fleet, tuned to the specific patterns that matter to that fleet, is not a project that fits inside a large hosting company’s product development process. It is a project that fits inside a small operator’s ongoing engineering work, where the people running the fleet are also the people building the tools for it, and where the tool exists because the people using it every day understand why it matters.

The prototype is running. The rest is a matter of iteration. If you are a customer of ours and you have had email deliverability issues you never quite got to the bottom of, we can look at what actually happened for your domain the next time it comes up. If you are considering hosting with us and you care about email being handled properly, this is the kind of work that sits behind the offer. If you run infrastructure of your own and you have been putting up with the same reactive-only pattern that we have, the underlying insight is portable: the reports are already being sent, the information is already there, and building the tool to use it is easier than it looks.