Here is the objection, stated as fairly as we know how: a piece of software you did not write, running on infrastructure you do not control, is making autonomous changes to the DNS records that determine whether your organisation's email gets delivered. Get it wrong and invoices don't reach customers, password resets don't reach staff, and nobody finds out until someone picks up the phone to complain.
That should make you uncomfortable. It makes us uncomfortable, and we build the thing.
What Can Go Wrong When Automation Writes DNS?
DMARC enforcement is unusual among security controls because the failure mode is not "an attacker gets in". The failure mode is your own legitimate mail stops being delivered. A DMARC policy of p=reject instructs receiving mail servers to discard messages that fail authentication. If a sending service you forgot about — a payroll system, a CRM, a state office's mail relay — was never authorised, publishing p=reject tells the world's mail servers to throw its mail away. Silently. At scale. That is a self-inflicted outage with a blast radius equal to your entire mail flow.
So when a vendor says their platform will "automatically progress your DMARC policy to enforcement", the correct response is not enthusiasm. It is scrutiny.
This article is our attempt to earn that scrutiny rather than deflect it. We build DMARC Busta, and our Autopilot writes DNS records autonomously. We have an obvious interest in you concluding that this is safe. Read accordingly, and check the claims.
What's the Difference Between Read-Only and Write-Capable AI in DMARC Tools?
Almost every DMARC platform on the market now advertises automation or machine learning of some kind. Most of it operates on the read side.
The read side is everything that happens to information on its way to you. Parsing XML aggregate reports from dozens of receivers. Resolving IP addresses to sending services. Classifying an unfamiliar source as "probably your marketing platform" rather than "probably a spoofer". Ranking which of your forty sending sources deserves attention first. Producing a recommendation on a dashboard.
If the read side is wrong, you are shown a misleading chart. That is annoying and it wastes your afternoon. It does not take your mail down. The blast radius of a bad read is bounded by a human's attention.
The write side is different in kind, not degree. The write side is a process that takes the output of all that analysis and changes a live DNS record. If the write side is wrong, mail stops. There is no human in the loop to catch it, because the entire point of automation is that there isn't.
Plenty of tools blur this line in their marketing, and the blur is commercially convenient. "AI-driven DMARC" sounds equally impressive whether the machine is colouring in a dashboard or rewriting your _dmarc TXT record. Those are not the same product and they do not carry the same risk.
To be direct about where we sit: DMARC Busta does both. Autopilot reads aggregate report data and it writes DNS records without asking you first. The write side is where every hard engineering question lives, and it is the only part worth interrogating.
Four Questions to Ask Any AI-Enabled DMARC Vendor
These questions are not about us. Ask them of any vendor, including us, and the answers will tell you most of what you need to know.
1. What does the automation decide on its own, and what needs a human?
Every autonomous system has a boundary. Find out exactly where it is drawn, and confirm that the boundary is enforced in code rather than described in a brochure. A vendor who cannot tell you crisply which actions execute without approval has not thought carefully about the question.
2. What data drives those decisions?
There is a meaningful difference between a decision derived from your own aggregate report history — counts of messages that passed and failed authentication, per source, over a defined window — and a decision produced by a language model asked to reason about your email.
The first is arithmetic against evidence you can audit. The second is inference. Inference is genuinely useful for summarising, explaining, and drafting. It is the wrong instrument for deciding whether to publish a record that can discard mail, because it is not reproducible: the same inputs need not produce the same output twice, and there is no threshold you can point at afterwards to explain what happened.
Ask specifically: does a language model sit anywhere in the path between the report data and the DNS write?
3. What happens when it gets it wrong?
Not if. Any system that has published enough records has published a record it should not have. What you want to understand is the recovery story: can the change be reversed, who or what reverses it, how quickly, and how do you find out that anything happened at all?
Be sceptical of "automatic rollback" as a headline feature. Ask the follow-up: has it ever actually run in production, and what triggered it? An untriggered safety mechanism is a hypothesis, not a guarantee.
4. Can you see precisely what changed, and why?
After the fact, you should be able to retrieve: the timestamp, the previous value of the record, the new value, and the reason the system believed the change was warranted. If a platform can show you that a record changed but cannot show you what it changed from, you cannot reconstruct an incident, and you certainly cannot reverse it by hand at 2am.
How Does Autopilot Decide When to Change a Policy?
Concretely, and with the caveats included.
The policy decisions are deterministic. Autopilot's progression logic evaluates a set of rules — each one a list of predicates such as "DMARC pass rate over the trailing seven days is at least 95%" — against metrics computed from your DMARC aggregate report data. A rule either matches or it does not. No language model sits anywhere in the path between the report data and a policy change. The same domain state produces the same decision every time, and every proposal records which named rule fired.
Where we do use a language model, and where we never do. The title of this article says "AI", so here is our exact boundary. The DMARC policy — the record that decides whether failing mail is quarantined or rejected — is never changed on the say-so of a language model. Sender classification is different. Most sending sources are classified by deterministic evidence: DKIM alignment, a match against the domain's own mail servers, a registry of known services, hard volume floors. For the uncertain middle band, where that evidence is inconclusive, we do consult a language model — and its answer is constrained to a fixed set of outcomes: include the sender, mark it already covered, ignore it, or send it to a human. A model recommendation is only ever applied without review when it reports at least 90% confidence, a sender that has sent nothing is never auto-included, and anything less clear lands in a queue for a person. On a domain with managed SPF, an applied "include" does end up in a DNS record — so we hold ourselves to our own second question and disclose it, rather than rounding it down to "no AI in the write path". Ask every vendor for their boundary at this level of specificity.
The sequence is fixed. Policy moves in one direction through none → quarantine → reject. There is no path that jumps a domain from none straight to reject. (Until mid-2026 the quarantine step was also staged in percentage increments using DMARC's pct tag. The revised DMARC standard retired pct — receivers never applied intermediate percentages consistently — so we removed the ramp fleet-wide: a domain now moves to full quarantine in one gated step, and dwells there before reject is considered.)
Advancement requires sustained evidence, not a snapshot. For a domain on the standard path, moving off p=none requires all of the following to hold at once: at least 14 days in the current phase, a DMARC pass rate of at least 95% across the trailing seven days, at least ten messages observed in that window, no open critical anomalies, and SPF and DKIM correctly in place. Moving from quarantine to reject requires a further 14 days at quarantine with the same evidence held, and additionally requires that no rollback has occurred in the previous seven days. A separate fail-closed gate sits in front of every advance regardless of what the rules say: the domain's dominant sender must show sustained, corroborated authentication on both SPF and DKIM, or the advance is refused. A single good day does not move anything.
Automated changes cannot weaken a policy — with one designed exception. Before any write, the system reads the live DNS record and compares it to what is about to be published. If an automated change would move the policy backwards relative to what is actually live, the write is refused and the refusal is recorded. The one exception is the rollback safety net, described below, which exists precisely to step a policy back when your legitimate mail is failing under enforcement. Nothing else automated can downgrade a policy; a human always can.
Writes are rate-limited and verified. A domain accepts at most three automated changes in any 24-hour period, and a record that changed in the last 60 minutes will not be touched again. After each publish, a separate job re-reads the live record from DNS to confirm the change took effect, retrying on a short ladder before marking the publish confirmed or failed and raising an alert on failure.
Every change is recorded. Each DNS write is logged with its timestamp, the previous value, the new value, whether it was automated, and what initiated it. Separately, the Autopilot event log records the rule that fired, the domain's phase, and the policy state at the time of the decision.
One honest qualification on that last point, because the distinction matters: the change log stores the previous and new record values, and the event log stores which rule matched. The specific metric values that satisfied the rule's predicates at that instant — the exact pass rate, the exact message count — are not durably written alongside every change. You can always see what changed, when, and which rule was responsible. Reconstructing the precise numbers that rule was reading requires the report data itself. We are closing that gap; it is not closed today.
You can stop it — and here is exactly what "stop" means. Autopilot can be paused for a single domain or across an entire account, at any time, and the pause takes effect immediately: no further policy progression, no new sender approvals. What a pause deliberately does not switch off is the safety tier — repairs that fix broken records, and the rollback net that can step a policy back — because those only ever act to protect the domain, never to advance enforcement; and a managed SPF record continues to track its already-approved sender list. If you want every automated behaviour halted, safety included, set the domain's automation level to manual. A domain only comes under autonomous control when someone enables it — either per domain, or by setting an account-level default that applies to domains added afterwards. If that default is left alone, nothing is enrolled automatically. Any policy can be reverted from the domain's DMARC page, which requires a reason and an explicit confirmation.
There is one deliberate exception to the evidence requirement, and we would rather describe it than have you discover it. A domain that sends little or no mail can never accumulate the report volume the standard gates demand — it would sit at p=none forever, permanently spoofable. For those domains an owner may attest, explicitly and on the record, that the domain's sending is understood, which allows a faster path to enforcement. That path still requires SPF and DKIM to be correctly configured, delegation verified against live DNS, and no open critical anomalies, and it still dwells at quarantine before reject. What it trades away is the volume and pass-rate evidence, in exchange for a human putting their name to the assertion. It is a human decision, recorded against a user, not an inference the machine makes on your behalf.
The Part We Find Hard
Autonomous DNS writes are the risk. Not the reports, not the dashboard, not the classification. The write.
Deterministic rules remove one class of problem — nothing is improvised, and every decision can be replayed — but they do not remove the underlying difficulty, which is that the rails have to be tight enough that the automation cannot cause damage even when the inputs are strange. Report data arrives late, or not at all. A receiver reports a day twice. A domain's mail pattern changes the week you happen to evaluate it. The interesting failures are never the ones where a threshold was slightly off; they are the ones where an assumption held everywhere except one edge, and the code marched straight through it.
Guardrails like refuse-to-weaken, rate limiting, recency protection, phase gating and post-write verification exist precisely because the rules alone are not sufficient. Every one of them was added because we could describe a way the system could misbehave without it. That list is not finished, and we are actively hardening it.
We will not tell you Autopilot has never made a mistake — it operates on live infrastructure, and any honest vendor with production traffic will say the same. Our automatic rollback is the concrete example. An earlier version of that trigger fired on evidence that should never have triggered it — domains with little or no traffic, and in one case a domain whose mail was passing — so we took it offline and rebuilt it from the decision logic up. The current trigger acts only on evidence from your authorised senders in real receiver data, and missing data now blocks a rollback instead of causing one. It was re-armed in July 2026 only after it was shown to suppress every one of those historical false firings, it is capped fleet-wide so that a single bug cannot cascade a rollback across many domains, and the day it was armed we ran a full end-to-end drill — a real automated rollback, executed through the production pipeline, on a domain we own — to prove the write path. What it has not yet done is fire against a genuine customer degradation. Until it has, we describe it as a live, tested safety net — not a guarantee. If a vendor's rollback story has no equivalent history attached, ask why.
What we do stand behind is narrower and more useful: the only automated action that can weaken a policy is that rollback safety net, it will not move faster than its rate limits, it will not progress without sustained evidence or an explicit human attestation, it records what it did and what the value was before, and you can pause or reverse it yourself at any time without contacting us.
Is No Enforcement Safer Than Automated Enforcement?
The risk of automated enforcement is easy to picture, which is exactly why it dominates the conversation. The risk of no enforcement is diffuse, boring, and considerably more likely to be the one you are actually living with.
In our scan of 10,586 Australian domains, 44.9% of the domains that publish a DMARC record are stalled at p=none — 3,339 organisations that did the difficult part, published the record, and then stopped. p=none instructs receivers to do nothing. It gathers telemetry. It stops no spoofed mail whatsoever. Only 39.1% of scanned domains are at an enforcing policy.
Those domains are not stalled because their operators are careless. They are stalled because progressing a DMARC policy correctly means reading aggregate reports every week, recognising each sending source, chasing down the ones nobody recognises, and repeating that for months before anyone dares touch the policy. It is unglamorous, it is never the most urgent thing on the list, and in most organisations it belongs to someone with a great deal else to do.
So the honest comparison is not "automated enforcement versus safe manual enforcement". It is "automated enforcement versus a record that sits at p=none for three years while the domain remains spoofable to anyone who cares to try". The cost of that inaction is not hypothetical, and it is measurable: our full findings are at dmarcbusta.com/research/australia-2026.
Automation is not obviously safe. Neither is a policy nobody has moved since 2023. Both positions carry risk, and only one of them is usually named out loud.
What to Take Away
Not a recommendation to buy anything. A framework.
Whether you use DMARC Busta or another platform, ask these four questions:
- What does it decide autonomously, and what requires a human? The boundary should be enforceable in code, and someone should be able to state it in a sentence.
- What data drives the decision? Aggregate report history and explicit thresholds, or model inference. Ask whether a language model sits between the data and the DNS write.
- What happens when it is wrong? Who reverses it, how fast, and how are you told. Treat any untriggered "automatic rollback" as unproven until the vendor tells you when it last ran.
- Can you see what changed and why? Timestamp, previous value, new value, and the reason. If the previous value is missing, you cannot reconstruct an incident.
The answers tell you everything you need to know about whether the automation is trustworthy. A vendor who answers all four precisely, including the parts that are unflattering, is a vendor who has thought about the failure modes. A vendor who answers with the word "AI" has told you only that they would prefer you did not ask a fifth question.
If you want to see how ours behaves before letting it write anything, Autopilot can be enabled per domain and paused at any time, and every change it makes is recorded with the value it replaced.
Frequently Asked Questions
Is it safe to let AI change DNS records?
It depends entirely on what the "AI" is actually doing at the moment of the write. Automation that changes DNS from deterministic, threshold-gated rules over your own report history — logged with the previous value, reversible, and pausable — is an engineering risk that can be inspected and bounded. A system where model inference directly produces DNS changes cannot make the same promises, because the same inputs need not produce the same output twice. Don't accept or reject "AI" as a label; ask the four questions above and judge the answers.
Can automated DMARC enforcement break my email?
Yes — and so can manual DMARC enforcement. Any move to p=quarantine or p=reject can affect legitimate mail if a genuine sending service was never authorised. That risk is why the gates exist: sustained pass rates over multi-week windows, minimum observed volume, a fixed one-way sequence, a refusal to advance while critical anomalies are open, and a rollback path when real mail starts failing. The practical question is not whether enforcement carries risk, but whether the automation's gates are stricter and more consistent than the manual process it replaces.
Do AI DMARC tools hallucinate?
Language models can produce confident, wrong answers — that is a property of the technology, and a vendor who denies it outright is not being straight with you. What matters is whether a model's output can reach your DNS. In DMARC Busta, policy changes never come from a language model: progression is decided by fixed rules over report data. A model is consulted only to help classify uncertain sending sources, its answer is constrained to a fixed set of recommendations, senders with no observed volume are never auto-included, and low-confidence answers go to a human instead of being applied.
How do I audit what an automated tool changed?
Ask for the change log, and check it contains four things for every DNS write: the timestamp, the value before the change, the value after, and whether the change was automated or human-initiated. In DMARC Busta that log is on the domain's history, and the Autopilot event log separately records which named rule proposed each change and the phase the domain was in. You can cross-check any entry against your DNS provider's own audit trail, because the previous value is recorded — a log that only shows what a record changed to cannot be reconciled against anything.
What should I show my cyber insurer about automated DNS changes?
Ask your insurer what they need — questionnaires differ, and we won't guess at underwriting requirements. What you can put in front of them from our side: the per-change audit trail (timestamp, previous value, new value, and what initiated the change), the fact that automation can be paused at any time without vendor involvement, the rollback mechanism, and the deterministic rules that gate policy changes. Those are the artefacts that let someone else verify how your DNS is governed, which is usually what the question behind the question is.
References and Further Reading
- DMARC Busta — Australia 2026 DMARC research dataset (10,586 domains scanned; 44.9% of DMARC-publishing domains at
p=none; 39.1% enforcing) - RFC 7489 — Domain-based Message Authentication, Reporting and Conformance (DMARC)
- RFC 9989 / 9990 / 9991 — the DMARCbis revision of the DMARC specification
- DMARC Busta — Autopilot: policy progression, guardrails and audit trail
Figures cited from the DMARC Busta Australian domain scan are point-in-time and are refreshed as the dataset is rescanned. Thresholds and guardrails described here reflect the system as it currently operates and are subject to change as the automation is hardened.
