Sunsetting a Free Privacy Service Without Breaking Trust

A free service can become a liability without failing

You are deciding whether a free privacy service should keep running, move to a specialist, or stop with a clear deadline. Mullvad is ending its public encrypted DNS service, which it had operated since 2022, and is shifting resources to fund Quad9.

The shutdown decision came four years after the service launched, and Mullvad will partner with Quad9 instead of operating the infrastructure itself. Operating a privacy-oriented public resolver requires specialized expertise, and the Quad9 Foundation is the leading organization in that area. Mullvad's VPN users do not need the public resolver because the VPN already encrypts traffic and resolves DNS internally.

Manually configured DNS-over-HTTPS users have until November 2, 2026, to move to Quad9. Mullvad Browser users who keep default DNS-over-HTTPS settings or the bundled ad-blocking option will be moved to Quad9 without manual action. The public note did not disclose the Quad9 sponsorship amount or give a precise DNS shutdown date beyond the manual-user deadline.

The sunset test comes before the announcement

Keep a public service only if it advances the core mission, is affordable, and can be operated safely. If not, name the liability, choose a specialist successor, set a deadline, automate migration where possible, and publish the reason. One failed gate is enough to start planning a move, because a useful service can still be the wrong thing for this organization to own.

• Name the liability. Write the cause in one line before you draft the announcement. A new employee should be able to repeat it, and the cause should point to a concrete operational or strategic reason, not a vague feeling of strain.
• Check mission fit. Ask whether the service still serves the reason the organization exists, not just the reason it was built. The answer needs to be a yes or no, with the no tied to a specific mission gap.
• Price safe operation. Include staffing, monitoring, incident response, abuse handling, legal review, and the support load from users who need help. The estimate must be realistic, not a hope that volunteers will cover the gaps.
• Choose a specialist successor. Pick a named organization with the operational depth to run the service, including the boring parts: status pages, abuse reports, and long-term maintenance. Avoid a generic promise of better support.
• Set a deadline and automate what you can. The plan needs to be a public date plus a default path that moves users who do not act. The failure mode is a vague sunset with no path for people who cannot read release notes.
• Publish the reason. The note must name the cause, the successor, and the reason for the move. A user should be able to forward it to a colleague and still understand the next step.

A legible migration protects trust

Say who is affected, what changes, what happens by default, and where to go if the default does not fit. Users should not have to infer the plan from a changelog, and the shutdown should read as care rather than cleanup.

If the successor is better resourced, say that plainly. If the old service was a stopgap, say that too. The reader should be able to tell whether the move protects the mission or merely removes a cost.

For users who cannot act, the path should be visible in the product, not only in the blog. A settings page, a banner, or an in-app notice can carry the same facts as the announcement. The message should be short enough to read on a phone and specific enough to prevent a broken default.

A useful postmortem protects the team

Record what the service did well, what made it unsustainable, and what the team learned about operating public infrastructure. Do not turn the shutdown into a character judgment. The team made a reasonable choice with the information they had.

Leave a record that future teams can use. Note the trigger that made the service a liability, the alternatives considered, and the migration path chosen. That record is the difference between a controlled exit and a repeat of the same mistake.

The finished note should protect the team, explain the cause, and give the next operator a clear starting point.