The gap
Install a filtering DNS profile on an iPhone and it works well: it applies to every app, on Wi-Fi and on cellular, and it logs what was reached. Then open Settings -> General -> VPN & Device Management -> DNS, switch from the profile to Automatic, and the whole thing is off. Nothing asks for a passcode. The profile is still installed, so at a glance the setup still looks intact.
This is not a flaw in any particular DNS provider. It is how iOS presents DNS configurations, and every provider's profile behaves the same way. If your setup depends on a DNS profile and you have not addressed this, you do not have a lock. You have a preference.
iPhone and iPad: supervision is required
There is one setting that fixes this, and it only works on a supervised device. We checked the alternatives thoroughly, because it would be convenient if there were an easier route.
The setting that works
Apple's DNS payload has a ProhibitDisablement key. Apple's description: "If true, the system prohibits users from disabling DNS settings. This key is only available on supervised devices." NextDNS exposes it in its profile generator as Prohibit Disablement, with the same supervised-only warning.
What does not work
Screen Time cannot help. Its Allow Changes To section covers eight items, none of which are DNS, VPN, or profiles. Apple's entire restrictions payload contains no DNS key at all. There is no unsupervised setting, official or otherwise, that locks this.
What supervising your own iPhone actually involves
- Back up the phone. Supervision erases it. This is the part that stops most people, and reasonably so.
- Turn off Find My and sign out of your Apple Account, or Activation Lock will block the next step.
- On a Mac, install Apple Configurator from the Mac App Store. It is free, and currently needs macOS 15.7 or later.
- Erase the phone and connect it by cable at the Hello screen, before Setup Assistant runs.
- Choose Prepare -> Manual Configuration, and tick Supervise devices.
- Choose Do not enroll in Device Management. You do not need an MDM server, and there is a literal option for this.
- Create an organisation and a supervision identity. Back this up. Changing it later means erasing and starting again.
- Install your prepared profile over the cable, then restore your backup.
One genuinely useful quirk: a profile installed this way counts as manually installed, and Apple documents that a manually installed DNS profile also applies to cellular, whereas one pushed by an MDM only applies to managed Wi-Fi. For a personal setup the Configurator route is not a compromise, it is the better option.
The profile needs more than the DNS payload
This is the part most guides miss. Turning on Prohibit Disablement stops the DNS being switched to Automatic. It does nothing about the profile simply being deleted, and the profile generators do not add that protection for you.
| What you add | What it stops |
|---|---|
ProhibitDisablement in the DNS payload | Switching DNS to Automatic |
PayloadRemovalDisallowed at the top level | Deleting the profile |
| A profile removal password payload | Removal even by someone who gets that far |
| Blocking interactive profile installation | Installing a looser profile alongside it |
| Blocking VPN creation | A VPN or proxy app rerouting around DNS entirely |
| Blocking Erase All Content and Settings | Wiping the phone from Settings to escape |
| Blocking host pairing | Plugging into another Mac to manage the device |
Provider-generated profiles are usually offered signed by default, and a signed profile cannot be edited. If you intend to add removal protection, generate it unsigned. Second, leave the DNS payload's failover option off; letting the device fall back to the network's own resolver when yours is unreachable is a hole in both the block and the record.
Every row in that table is supervised-only on iPhone. That is the complete answer to why supervision is unavoidable here.
Supervision applied with Apple Configurator does not survive a DFU restore. Anyone with a Mac, a cable, and twenty minutes can strip it off. So if you supervise your own phone, using your own Mac, holding your own supervision identity, you have built an elaborate speed bump for yourself and not a lock.
For this to be real, the trusted person has to run Configurator and keep the supervision identity, the profile removal password, and your Apple Account password. If that is not something they are willing to do, be honest with yourself that supervision is not actually available to you, and use the detection approach instead. A lock you can undo in an afternoon is not worth wiping your phone for.
Mac: much easier, and no supervision needed
This is the one place in the whole guide where macOS is genuinely stronger than iPhone, for two reasons.
There is no off switch
macOS does not present a DNS profile the way iOS does. Where iPhone offers a selector you can flip to Automatic, System Settings on a Mac only shows read-only text naming the server in use. The disable affordance that makes this a problem on iPhone is simply not in the Mac interface.
A standard account really protects it
macOS has a genuine administrator split, and it is enforced here. Removing a configuration profile requires admin authentication. So does changing DNS servers on any network service. A standard user cannot do either.
The Mac setup, in order
- Convert the daily account to Standard, with the trusted person holding the only administrator account. Everything else rests on this, so do it first and confirm no second admin account exists with a password you know.
- Generate the DNS configuration profile from your provider, choosing Mac as the device type, and generate it unsigned so it can be edited.
- Add
PayloadRemovalDisallowedand a profile removal password known only to the trusted person. Both of these work on a normal Mac with no supervision and no MDM. - Have the trusted person install it through System Settings -> General -> Device Management, entering the admin password. It has to be the graphical route; the command-line tool has not been able to install profiles since macOS 11.
- Give the profile a device name so its entries are attributable in the log.
Result: removal needs the admin password and the removal password, changing DNS needs the admin password, and there is no toggle to disable it. That is a substantially stronger position than an unsupervised iPhone, achieved without erasing anything.
What a standard user can still do on a Mac
Be realistic about the remaining gaps rather than assuming the profile settles it.
- Browser-level encrypted DNS is the big one. Chrome and Firefox can resolve names themselves, in-process, bypassing the system resolver without needing admin rights. Close this with browser policy and by turning on your provider's bypass-method blocking.
- Running apps from the home folder. A standard user can still run a browser or proxy tool out of Downloads without admin rights.
- Another device entirely, or a phone on cellular. No Mac setting addresses that.
Check when it was last updated before relying on one. A menu bar app that offers an enable/disable switch to whoever is logged in is the opposite of what you want here, and an abandoned one may silently fail to apply on current macOS while still appearing installed. The configuration profile is the route to use. Where a provider offers a command-line daemon that runs as root and restarts itself, that is a reasonable second layer, because a standard user cannot stop it.
While you are here: close Private Relay
If you use iCloud Private Relay, it encrypts DNS resolution away from your filtering provider. That means Safari traffic is neither filtered nor logged, which quietly undoes both halves of the setup.
- Turn off Limit IP Address Tracking for each network, on each device. Note it must be done per network and per interface, and the setting syncs across your devices.
- Better, because it does not depend on a toggle you could flip back: block Apple's Private Relay hostnames at your DNS provider. Apple documents that a network refusing to resolve these will cause Private Relay to decline to engage and prompt the user instead. Several filtering providers include this in their bypass-blocking option already.
- On a supervised iPhone, the restriction that disables Private Relay outright is the reliable version.
If you will not supervise: detect instead of prevent
Most people reading this will not erase their phone, and that is a reasonable decision rather than a failure of nerve. The honest alternative is not a weaker lock. It is a different strategy: accept that the profile can be switched off, and make switching it off immediately visible.
This works because of an asymmetry worth thinking about. Turning the filter off does not just unblock things, it stops the log. A phone in daily use produces a constant stream of DNS queries. When that stream ends, the record of your day ends with it, and that absence is as legible as anything the log would have contained.
- The trusted person owns the account, so you cannot clear the log or shorten its retention to cover a gap.
- Agree explicitly that a gap is an event. Say it out loud, at setup, while things are calm. This is the sentence that does the work, because it converts turning the filter off from a way to hide into the most visible thing you could do.
- Remove the innocent explanations in advance. Pay for a tier that does not stop working when a monthly quota runs out, and mention travel or a flat battery when it happens, so a real gap is not lost in noise.
- Pair it with a tool that alerts on being disabled, if you can. A notification the moment protection stops beats a log reviewed on Sunday.
- Put the review cadence in writing on the handoff worksheet, so this does not quietly lapse after a good month.
Most filtering DNS services have no tamper alert at all. If the profile is switched off, nothing is sent to anyone; the log simply stops. That is workable, but only if someone is actually looking, so check whether yours can notify before you rely on it. The same caution applies to accountability apps: coverage varies enormously, and at least one well-known product states in its own documentation that it cannot detect being uninstalled on iPhone, and only reports a device as inactive after it has been silent for seven days. A week is not an alert.
A heartbeat that catches more than silence
Silence tells you the phone stopped sending queries. It does not tell you the phone is running normally but unprotected, which is what actually happens when the DNS is switched to Automatic while everything else carries on. Those look different from the outside and only one of them is obvious.
Some providers publish a status endpoint that reports whether their filtering is in use for the request. Fetching that on a schedule turns "is the filter on right now?" into a question with a recorded answer, rather than something inferred from an absence.
- Find whether your provider offers a test or status URL that reports whether traffic is going through them.
- Set up a scheduled automation on the phone to fetch it, using the Shortcuts app and a Time of Day trigger.
- Turn off Ask Before Running so it runs without prompting.
- Have the result go somewhere the trusted person can see.
Several blocking apps report that as of iOS 26.4, released April 2026, disabling an app's Screen Time access can be made to require the Screen Time passcode rather than just Face ID or the device passcode. If that holds, it closes the long-standing hole where any blocking app could be switched off in Settings in seconds, and it makes a partner-held passcode meaningfully stronger than it used to be.
Two caveats. It is reported by app vendors rather than documented by Apple, so confirm it yourself before building a plan on it. And it is not on by default, so it does nothing unless you deliberately turn it on. If it works as described, it is the single most useful thing an unsupervised iPhone user can enable.
Where to go next
More guides
Use these when you need a checklist, a specific bypass closed, or a clearer handoff plan.
Guardrails
Built-in controls and exact menus for each device.
Friction
DNS filters, browser policy, hosts files, and router rules.
Lockout
Trusted-person handoff, admin separation, and recovery control.
Trusted person
Who holds what, and the rules you agree in advance.
Test your setup
Browser, DNS, mobile data, recovery, and reset-path tests.
Mobile data
Close cellular, Private DNS, VPN, and hotspot gaps.
Urge plan
What to do before trying to bypass.
Trusted handoff worksheet
Printable inventory for passcodes, recovery paths, and refusal rules.
Glossary
Plain-language definitions for DNS, DoH, VPNs, MDM, recovery keys, and more.