Overview
The Apple DNS Settings Policy configures encrypted DNS on company-owned Macs, iPhones, and iPads enrolled in Swif.
You can create multiple DNS configurations, select DNS over HTTPS (DoH) or DNS over TLS (DoT), and specify which domains use each resolver. On supported devices, you can also allow failover to the system resolver or prevent users from disabling the configuration.
Encrypted DNS protects DNS queries between the device and the selected resolver. Any filtering or reporting depends on the DNS service you choose.
Important: An incorrect DNS configuration can prevent websites, applications, and Swif management services from resolving hostnames. Validate the configuration on a test device before deploying it broadly. A device that loses DNS connectivity may be unable to receive a remote correction.
Requirements
Requirement | Details |
Supported platforms | macOS 11 or later, iOS 14 or later, iPadOS 14 or later |
Device ownership | Company-owned |
Management | Enrolled in Swif through Apple MDM |
Apple enrollment methods | Device Enrollment or Automated Device Enrollment; User Enrollment is not supported for this payload |
Network scope | Managed Wi-Fi networks when delivered through MDM |
Allow Failover | macOS 26, iOS 26, or iPadOS 26 or later |
Prohibit Disablement | Supervised devices only |
DNS service | A reachable DoH or DoT resolver with a valid server certificate |
Apple identifies this payload as com.apple.dnsSettings.managed and permits multiple DNS Settings payloads on a device. Apple: DNS Settings deployment reference
Managed Wi-Fi Scope
Apple states that DNS settings installed through MDM apply only to managed Wi-Fi networks. Configure the relevant Wi-Fi network through MDM before relying on this policy. Do not assume coverage for manually joined Wi-Fi, Ethernet, or cellular connections. Apple: DNS Settings payload specification
Domain matching controls which queries use a resolver within the applicable network scope. It does not extend that scope to other network interfaces.
Before You Begin
Confirm the provider's endpoint, certificate hostname, and any required server addresses. Test public websites, internal applications, VPN access, and Swif check-ins.
For an initial deployment:
Assign the policy to a small test group with local administrator access available.
Leave Prohibit Disablement off until DNS behavior and recovery have been tested.
Decide whether availability or keeping DNS on the chosen resolver takes priority when that resolver is unavailable.
Confirm how an administrator can restore connectivity if remote management stops working.
Swif's field guidance states that Server URL validation only checks that the value starts with https://. Saving the policy does not prove that the hostname, path, certificate, or service works.
Policy Settings
Multiple DNS Settings Payload Content
This required list contains your DNS configurations. Add an entry for each configuration you need.
Each entry contains:
DNS Settings, including protocol, endpoint, optional addresses, domain matching, and failover.
Prohibit Disablement, which applies to that entry.
Multiple entries are not a documented priority-ordered failover chain. Prefer clearly scoped configurations and test any overlapping domain rules.
DNS Protocol
Select the encrypted transport used by the resolver.
Value | Protocol | Required endpoint field |
| DNS over HTTPS | Server URL |
| DNS over TLS | Server Name |
Swif default: HTTPS.
Selecting a protocol displays its corresponding endpoint field. Use the endpoint supplied for that protocol; a DoH URL and a DoT hostname are different inputs.
Server URL
Required when DNS Protocol is HTTPS.
Enter the provider's complete DoH endpoint, including https:// and its path. For example:
https://cloudflare-dns.com/dns-query
The device uses the hostname or address in this URL to validate the server certificate. When DNS Server Addresses is omitted, it also uses the URL's hostname or address to determine the resolver addresses.
A provider's website homepage is not necessarily a DoH endpoint. A misspelled host or incorrect path can leave the device without working DNS.
Server Name
Required by Swif when DNS Protocol is TLS.
Enter the provider's DoT hostname. For example:
one.one.one.one
Use a hostname, without https:// or a URL path. The device uses it to validate the server certificate and, if no server addresses are supplied, to determine the resolver addresses.
DNS Server Addresses
Optional, with no predefined addresses.
Enter the resolver's IP addresses as separate list entries. IPv4 and IPv6 addresses can be mixed.
These addresses form an unordered list. Their position does not establish primary and secondary priority. Use addresses belonging to the resolver identified by the URL or server name.
Supplying IP addresses does not remove the need for the required endpoint field or a valid server certificate.
Supplemental Match Domains
Optional, with no predefined domains.
Use this list to select which DNS queries use the configured resolver. If it is not set, the resolver applies to all domains within the policy's applicable network scope.
For example, example.com and *.example.com both match app.example.com and service.internal.example.com, but not app-example.com. Apple supports a single wildcard prefix; a wildcard is not required for subdomain matching.
Enter domain names, not website URLs. This is a DNS routing rule, not a website allowlist or blocklist.
For internal domains, the selected resolver must be able to resolve the private DNS records. A public resolver generally cannot resolve an organization's private zones.
Allow Failover
Allows the device to use the default system DNS resolver if failover is needed.
Value | Behavior |
On | Allows failover to the default system resolver. |
Off | Does not permit that failover through this setting. |
Swif default: Off (false).
Requires macOS 26, iOS 26, or iPadOS 26 or later. Do not rely on this setting to provide recovery on earlier versions.
Failover can improve availability, but the system resolver may use unencrypted DNS or different filtering rules. Leaving failover off can prevent matching DNS queries from resolving when the configured service is unavailable.
This option does not mean “try the next DNS entry” and does not guarantee recovery from every configuration error.
Prohibit Disablement
Prevents users from disabling the DNS settings.
Value | Behavior |
On | Prohibits users from disabling the configuration on supervised devices. |
Off | Does not prohibit disablement through this setting. |
Swif default: Off (false).
This setting is available only on supervised devices. It controls DNS disablement; MDM profile removal restrictions are separate.
Create the Policy
In the Swif Admin Dashboard, go to Device Management > Policies.
Create a policy and select Apple DNS Settings Policy.
Enter a descriptive policy name.
Add an entry under Multiple DNS Settings Payload Content.
Under DNS Settings, select the protocol and enter its required endpoint.
Add server addresses and match domains if needed.
Configure Allow Failover for devices running OS 26 or later.
Set Prohibit Disablement as appropriate for supervised devices.
Save and assign the policy to a test device or group.
Allow the device to check in, review installation status, and verify DNS operation on the applicable managed Wi-Fi network.
Expand deployment only after testing succeeds.
Example: Blocklist using NextDNS
Create a "NextDNS " account for testing purposes.
Add Facebook to the blocked list:
Find the DNS info:
Configure the policy:
Verify DNS is set on the device:
Facebook is blocked on the browser and the apps.
Example: Cloudflare DNS over HTTPS
Add one DNS entry with these values:
Field | Value |
DNS Protocol | HTTPS |
Server URL |
|
DNS Server Addresses |
|
Supplemental Match Domains | Leave unset to apply to all domains in scope |
Allow Failover | Off for this example |
Prohibit Disablement | Off during testing |
This uses Cloudflare's standard, unfiltered public resolver. It does not add malware filtering. Cloudflare documents the DoH endpoint and resolver addresses.
With failover off, loss of access to the resolver can interrupt DNS resolution. If your organization accepts fallback to the system resolver, enable Allow Failover on OS 26 or later and test the fallback behavior.
Example: Cloudflare DNS over TLS
Use this as an alternative to the DoH example. Avoid deploying both as overlapping all-domain entries without testing.
Field | Value |
DNS Protocol | TLS |
Server Name |
|
DNS Server Addresses |
|
Supplemental Match Domains | Leave unset to apply to all domains in scope |
Allow Failover | Off for this example |
Prohibit Disablement | Off during testing |
The network must allow access to the resolver over TCP port 853. Cloudflare: DNS over TLS
Example: Route an Internal Domain to an Enterprise Resolver
If your organization operates a reachable encrypted resolver for private DNS, configure its DoH URL or DoT hostname and add your internal domain to Supplemental Match Domains.
For example:
corp.example.com
Queries for names such as portal.corp.example.com then match this configuration. Other names are outside this entry's domain scope and follow the remaining effective DNS configuration.
Replace the example domain with your own. Confirm that the resolver is reachable from the managed network and through any required VPN. Domain matching does not establish a VPN connection.
Verify the Policy
Confirm successful policy installation in Swif.
On the device, inspect installed profiles in Device Management on macOS or Settings > General > VPN & Device Management on iPhone and iPad. Menu names vary by OS version.
Connect to the intended managed Wi-Fi network.
Test public websites and required internal applications.
Confirm that the device continues checking in with Swif.
For scoped configurations, test names inside and outside the configured domains.
Use the DNS provider's logs or network diagnostics to confirm the resolver and encrypted transport actually used.
On a Mac, you can inspect installed profiles with:
sudo profiles show -type configuration
For the Cloudflare DoH example, this command tests direct endpoint reachability:
curl --fail --silent --show-error \
--header 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
A successful response proves the endpoint is reachable. It does not prove that the installed policy is handling system DNS. Cloudflare documents this DoH request format.
Troubleshooting
The profile is installed, but the expected resolver is not used
Check the managed Wi-Fi scope, match domains, and other DNS configurations. A VPN, DNS proxy, security client, or application-specific resolver can affect the result. Profile installation alone does not establish which resolver handled a query.
Websites or applications stop loading
Review:
The complete DoH URL or DoT server name.
Whether the provider supports the selected protocol.
Whether the supplied IP addresses belong to that service.
Server certificate validity and device date and time.
Firewall access to the endpoint, typically TCP
443for HTTPS or TCP853for DoT.Captive portal requirements and VPN behavior.
Whether Allow Failover is enabled and supported by the device OS.
Correct the policy or remove its assignment while the device is still reachable.
Internal domains no longer resolve
Check whether an all-domain configuration sends private names to a public resolver. Use an enterprise resolver that can answer those names, or review your domain-specific DNS and VPN configuration. Test private resources before deploying an all-domain public resolver.
Failover does not restore connectivity
Confirm OS 26 or later and inspect the delivered setting. The system resolver must also be reachable and functional. Failover cannot repair a broken network connection or guarantee that every endpoint error will trigger a successful fallback.
Users can still disable the configuration
Confirm supervision and that Prohibit Disablement is on for the relevant entry. Company ownership alone does not prove the device is supervised.
The device cannot check in after deployment
A remote removal or correction requires connectivity. Use this recovery order:
If permitted, locally disable the affected DNS configuration and restore working DNS.
Try an available network connection where the faulty configuration does not apply, then correct or remove the policy through Swif.
If connectivity cannot be restored, contact Swif Support for local recovery appropriate to the device's enrollment and profile restrictions.
Removing the MDM enrollment profile may be necessary as a last resort, but it also removes management and can affect other managed settings. Where Swif's removal-password mechanism applies, obtain the password before recovery. See Prevent device users from unenrolling.
Some enrollment profiles are non-removable. Do not assume a removal password can override that restriction. After recovery, correct the DNS policy before reenrolling or reassigning it.
Remove the Policy
Remove the assignment in Swif while the device is online, allow it to receive the removal, and confirm that the DNS profile is removed. Verify name resolution and continued Swif check-ins.
The resulting DNS behavior depends on the remaining network, VPN, and DNS configurations. Removing the policy does not necessarily restore a specific previous resolver.