Analyze Drift: a beginner's guide

Configuration drift is the slow divergence between what a system is supposed to be configured as and what it actually is configured as right now. Every production DNS zone, email-security setup, and TLS configuration starts out in a known-good state. Then somebody makes a one-off change to ship a launch, somebody else adds a SaaS vendor in a hurry, a third person rotates a key without updating the docs — and six months later the live configuration has drifted far enough from the documented baseline that a planned change nearly causes an outage because nobody can predict what's actually there anymore. Drift is the silent precondition to most self-inflicted incidents (Wikipedia covers the general pattern as it applies across all systems).

You should care because drift analysis is how you find the changes nobody remembered making before they cause an outage. Manual config review on a quarterly basis catches some of this, but it's fundamentally a reactive practice — you're reviewing the current state against memory, not against a recorded baseline. Automated drift analysis runs a snapshot every day (or every hour), diffs it against the last known-good snapshot, and flags every change with a timestamp. Some of those changes will be expected; some will be surprising; the surprising ones are where incidents hide.

The five things every drift analysis looks at:

• Record-level diffs. Every DNS record, every TLS-cert parameter, every SPF/DMARC/DKIM field — compared field by field between the current state and the prior snapshot.

• Add / remove / modify classification. Distinguishing "new record appeared" from "existing record changed value" from "record deleted" matters because they suggest different root causes.

• Change authorship when available. If the DNS provider exposes audit logs, drift analysis can attribute changes to specific users — closing the loop between "something changed" and "who did it."

• Expected-drift suppression. Some changes are expected (TLS cert renewals every 90 days, Let's Encrypt rotations). Filtering out expected drift leaves only the noise that's actually worth investigating.

• Severity grading of the diff. A change in an SPF `include:` is higher-severity than a TTL tweak; a new CAA record affecting certificate issuance is higher still.

Three questions a drift analysis answers:

• What has changed in my DNS/email/TLS configuration since the last audit?

• Of those changes, which were expected and which are surprises worth investigating?

• Is the rate of drift accelerating over time — a sign that change-management discipline is slipping?

The cost of skipping drift analysis is the slow accumulation of unexplained configuration state that nobody on the team can speak authoritatively about. The fix is a snapshot-and-diff workflow running on a recurring schedule. Google's SRE workbook covers the operational discipline, and the same configuration-management thinking that powers infrastructure-as-code tools (Terraform plan/apply, Pulumi preview) applies directly: the diff is the value.

In one sentence: Diff current posture against a prior snapshot

Compares a domain's current posture against a prior-run snapshot (POST body) and reports score deltas, resolved findings, new findings, and severity escalations. Classifies the drift as improving, stable, regressing, or mixed.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Runs the current scan (SPF (Sender Policy Framework), DMARC (Domain-based Message Authentication, Reporting and Conformance), DKIM (DomainKeys Identified Mail), MTA-STS (Mail Transfer Agent Strict Transport Security), DNSSEC (Domain Name System Security Extensions)). Diffs category-level scores and grades against the prior snapshot. Matches findings by category + title to identify resolved (was present, now gone), new (now present, was not before), and escalated (severity increased). Classifies the overall drift direction based on score delta and net new-critical findings.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Analyze Drift tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Posture changes silently — a vendor rotates a DKIM (DomainKeys Identified Mail) key and coverage drops, a DNS (Domain Name System) migration drops DNSSEC (Domain Name System Security Extensions), a registrar sets clientHold. Drift analysis catches these regressions.

Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Store a weekly snapshot per domain; run drift analysis to flag regressions for triage. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Analyze Drift tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Analyze Drift tool is built for you:

• Can I get the entire story about a domain in a single report instead of running ten checks?

• What is the single document I would share with my team, my client, or my board?

• Where should I focus my next hour of work to make the biggest difference?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Account executives prepping a sales call, agencies producing a monthly client deliverable, investors doing diligence, and founders building a board deck. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you have to assemble the same snapshot by hand every time you need it — which means you stop bothering. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the Analyze Drift tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer and a change advisory board — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Weekly Posture Monitoring

Imagine you're a security engineer. Store a weekly snapshot per domain; run drift analysis to flag regressions for triage.

Why it matters: Catch silent regressions before they become findings in an external scan.

Story 2: Change-Management Sign-Off

Imagine you're a change advisory board. After a DNS (Domain Name System) migration, run drift against the pre-migration snapshot to verify nothing regressed.

Why it matters: Evidence-backed migration sign-off.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Analyze Drift tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Right before a sales call, to walk in already knowing the prospect.

• For a monthly client status update or executive summary.

• During M&A or investor diligence on a target domain.

• When you want to share "everything we know about this domain" in a single link.

If you can see yourself in even one of those bullets, the Analyze Drift tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Analyze Drift tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the Analyze Drift tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with Analyze Drift. If you're already running this check, the related ones often answer the next question that comes up:

• Compare Baseline — Evaluate current scan against a declarative policy baseline

• Fix Plan — Prioritized remediation action list from scan findings

• Website Health — Combined SEO, accessibility, and privacy audit

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check Analyze Drift and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

SPF (Sender Policy Framework) — A list, published in your DNS, of which servers are allowed to send email pretending to be you. Helps stop spammers from forging your address.

DKIM (DomainKeys Identified Mail) — A digital signature added to every email you send. The receiving mail server checks the signature to make sure the message really came from you and was not changed in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — An email rulebook you publish in your DNS. It tells receiving servers what to do with email that fails SPF or DKIM checks — ignore it, send it to spam, or block it entirely.

MTA-STS (Mail Transfer Agent Strict Transport Security) — A way to tell other mail servers "always use encryption when sending email to me, and refuse to fall back to unencrypted delivery."

DNSSEC (Domain Name System Security Extensions) — A way to digitally sign DNS records so attackers can't trick your computer into looking up the wrong server.