Rollout Plan: a beginner's guide

A rollout plan is a phased timeline for deploying a meaningful DNS or email-authentication change without causing self-inflicted outages along the way. The classic example is DMARC: moving a production domain from "no DMARC at all" to `p=reject` in a single change is a near-guaranteed way to block legitimate third-party email (forgotten SaaS senders, partner integrations, internal marketing platforms) the moment the policy takes effect. A proper rollout plan phases the change across weeks: deploy monitoring-only (`p=none` with reporting), analyze the reports for a month, fix every legitimate sender that's failing, move to `p=quarantine` with a low percentage, gradually increase the percentage, then move to `p=reject`. The same pattern applies to TLS hardening, HSTS preload, MTA-STS enforcement, and most other high-stakes DNS changes.

You should care because the mistakes that happen during DNS rollouts are almost always self-inflicted, and almost always avoidable with phasing. The patterns are well-documented (dmarcian's DMARC deployment guides covers the email case in depth). The reason teams skip the phasing isn't disagreement with the pattern — it's time pressure, missing documentation, and the false confidence of "we already fixed all the senders." A rollout plan makes the phasing an explicit artifact: each phase has an entry criterion, an exit criterion, and a documented duration, so the team can't accidentally skip ahead.

The five phases every DNS rollout plan includes:

• Pre-deploy validation. Run the check today, before any change, and record the current state as the baseline.

• Monitoring-only deployment. Turn on the new mechanism in reporting mode (`p=none` for DMARC, testing mode for MTA-STS, low max-age for HSTS) and collect data for at least a reporting cycle.

• Gradual enforcement ramp-up. Increase the enforcement percentage week by week (e.g., `p=quarantine pct=25` → `pct=50` → `pct=100` → `p=reject pct=10` → ... → `p=reject pct=100`) with checkpoints for legitimate-sender regressions.

• Post-deploy validation. Run the same check again after the rollout is complete; confirm the target state is live and no legitimate senders are failing.

• Rollback criteria. Documented thresholds for when to pause or back out — "if more than X% of legitimate mail starts failing, revert to the previous phase."

Three questions a rollout plan answers:

• What is the safest sequence for deploying this change?

• How long should I wait between phases, and what should I measure during each one?

• If something goes wrong in week three, what's my rollback path?

The cost of skipping a rollout plan is the outage that catches legitimate traffic because the change went faster than the underlying ecosystem could adapt. The fix is to treat every high-stakes DNS change as a multi-week deployment rather than a single-edit event. The Google SRE workbook's canary-deploys chapter applies directly: deploy the change to a small subset first, measure, expand. DNS doesn't have the same tooling as code deploys, but the same mental model works.

In one sentence: Phased timeline for hardening email-auth posture safely

Emits a phased rollout timeline for advancing email-authentication posture without breaking deliverability. Supports DMARC (Domain-based Message Authentication, Reporting and Conformance) p=none → quarantine → reject transitions, SPF (Sender Policy Framework) softfail → strict hardening, and MTA-STS (Mail Transfer Agent Strict Transport Security) testing → enforce moves. Each phase includes observable signals, rollback criteria, and recommended duration.

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:

Reads the current state of the domain's SPF/DMARC/MTA-STS configuration and generates a recommended phased rollout to the target state. For each phase: the record value to publish, how long to hold, what signals to monitor (TLS-RPT (TLS (Transport Layer Security) Reporting), aggregate reports, deliverability), and rollback criteria. Handles common targets: dmarc_reject, spf_strict, mta_sts_enforce.

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 Rollout Plan 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.

Moving DMARC (Domain-based Message Authentication, Reporting and Conformance) from p=none to p=reject overnight is how teams break their own email. A rollout plan sequences the change with observation windows so each phase is reversible if deliverability regresses.

Picture this in real life. Imagine an email admin. Here's the situation they're walking into: Move from DMARC (Domain-based Message Authentication, Reporting and Conformance) p=none to p=reject over 6 weeks with aggregate-report monitoring at each step. 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 Rollout Plan 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 Rollout Plan 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 Rollout Plan tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an email admin and a security engineer — 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: Safe DMARC Enforcement

Imagine you're an email admin. Move from DMARC (Domain-based Message Authentication, Reporting and Conformance) p=none to p=reject over 6 weeks with aggregate-report monitoring at each step.

Why it matters: Reach enforcement without breaking legitimate mail flows.

Story 2: MTA-STS Enforcement Rollout

Imagine you're a security engineer. Move MTA-STS (Mail Transfer Agent Strict Transport Security) from testing to enforce after TLS-RPT (TLS (Transport Layer Security) Reporting) reports stabilize.

Why it matters: Catch misconfigured MX before enforcement rejects legitimate inbound mail.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Rollout Plan 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 Rollout Plan 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 Rollout Plan 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 Rollout Plan 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.

You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.

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 Rollout Plan. If you're already running this check, the related ones often answer the next question that comes up:

• Fix Plan — Prioritized remediation action list from scan findings

• DMARC Check — Analyze DMARC policy, alignment, and reporting

• SPF Check — Validate SPF record syntax, DNS lookups, and policy

• MTA-STS Check — Validate email transport encryption policy

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 Rollout Plan 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.

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.

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."

TLS-RPT (TLS Reporting) — A way for your mail server to receive reports when other servers fail to deliver email to you over a secure connection — pairs with MTA-STS.

TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.