Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


To change DNS settings on Mac running a current version of macOS—the steps are the same on a MacBook Air or MacBook Pro—open Apple menu > System Settings > Network, select the network service you are actually using, choose Details, then open DNS. Record the existing servers and their order before adding or removing any IPv4 or IPv6 address. Test hostname resolution afterward and restore the original list if the change does not solve the problem.
Key Takeaways
- DNS translates domain names; it does not repair Wi-Fi radio, router, provider, captive-portal, or app failures.
- Change the active service—such as Wi-Fi or Ethernet—not a similarly named inactive service.
- Preserve the original server list, order, and search domains before editing.
- Use only DNS details from a trusted network administrator or provider.
- Verify the same hostname before and after, then restore the recorded configuration if there is no improvement.
If you have not yet shown that DNS is the failing layer, start with the device and app troubleshooting guide or the Mac Wi-Fi scope checklist.
| Symptom | What it suggests | What to do first |
|---|---|---|
| Several domain names fail, but the local network is otherwise reachable | Possible DNS resolution issue | Compare another network and review DNS |
| Every device fails on one Wi-Fi network | Router or internet-service issue | Troubleshoot the shared network |
| One app or one site fails | App, account, site, extension, or filter issue | Test another app and unrelated domains |
| A captive sign-in page has not been completed | Network access is not yet authorized | Complete the trusted portal sign-in |
| Failure begins with a proxy, VPN, or content filter | Another network layer may own resolution | Review that layer before replacing DNS |
A DNS change cannot increase signal strength, renew an expired service account, or fix a disconnected modem. Public DNS also does not automatically make every connection faster or private: the result depends on the network, resolver policy, encryption path, caching, and the destinations used.
Create a recovery record first.
Apple documents adding and removing DNS servers and search domains from this page.[1] A server supplied automatically by the network may appear differently from a manually entered one. Do not delete a profile, certificate, or management setting to force an edit.
Stop if the Mac or network is managed, the fields are locked, or you do not know which values must be restored. Ask the administrator for the approved addresses and order.
Keep a small change log with the active service, network name, test time, original list, test list, and the same two hostnames for later comparison. Leave out passwords and other credentials. This makes the result reproducible and prevents a later Wi-Fi, VPN, or proxy change from being mistaken for a DNS improvement.
If the required service does not exist, Apple documents adding one from the Network actions menu.[2] First establish which connection should carry traffic, and do not create a duplicate merely because DNS editing did not fix an unrelated outage.
Changes made to Wi-Fi do not automatically become Ethernet settings, and settings for an unused adapter will not change the active connection. If you regularly use more than one service, treat each as a separate configuration with its own recovery record.
Only enter addresses supplied by your network administrator or a resolver provider you have deliberately chosen and reviewed.
Do not enter a website URL, a PAC address, a proxy server, or a search domain in the DNS server list. Do not copy an unknown resolver from a speed-test list. The operator can observe or influence name-resolution responses, so ownership and policy matter more than marketing claims.
Removing every manual entry usually lets the network's automatic DNS configuration apply again, but the exact result depends on the service and any profiles or VPNs. Do not remove organization-provided entries or search domains without approval. Search domains help resolve short internal names and should not be treated as interchangeable with resolvers.
Use the same small test set before and after the change:
Success means the previously failing names now resolve consistently without breaking known-good destinations. A page loading once is not proof that DNS caused the failure; caches, a restored internet link, or a captive-portal sign-in may have changed at the same time.
This guide intentionally avoids destructive cache-clearing commands. Reopening an app or reconnecting the tested service is enough for this diagnostic stage. If support needs lower-level evidence, follow its version-specific instructions and preserve the exact output.
Restore when the change does not help, makes results worse, or conflicts with a managed network.
If the list changes back automatically, another owner—such as DHCP, a profile, a VPN, or security software—may be supplying it. Do not repeatedly overwrite that state. Identify the owner and use its supported configuration path.
Return to scope rather than trying more random resolvers.
Collect the affected service, original and tested server lists, timestamps, network names without credentials, and exact errors before contacting the administrator, provider, or Apple Support.
Change DNS only after the symptoms point to name resolution. Select the active Mac network service, preserve the original IPv4/IPv6 servers and order, enter only trusted values, and verify the same names before and after. If the test does not produce a clear improvement, restore the recorded configuration and continue troubleshooting the actual failing layer.
Open System Settings > Network, select the active service, choose Details, then open DNS.
No. DNS translates names; it does not improve radio signal, interference, router coverage, or an internet-provider outage.
No. Performance varies by network, location, caching, resolver operation, and destination. Measure the actual problem instead of assuming a universal speed gain.
No. Resolver choice is only one part of the connection, and the operator and transport policy matter. It is not a substitute for understanding the full traffic path.
Yes, macOS accepts both formats. Enter each approved address separately and preserve the intended order.
No. DNS servers answer resolution queries; search domains help expand short names, often on internal networks.
DHCP, a configuration profile, VPN, security product, or administrator may be supplying them. Identify that owner instead of repeatedly deleting the values.
Not for this basic procedure. Reopen the affected app or reconnect the service, and use version-specific commands only when trusted support requires them. A VPN cannot record or restore your original macOS DNS settings; keep that rollback information yourself.
Sources checked 4 October 2026.
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.





