A DNS suffix search list is the set of domain suffixes Windows appends to a short hostname before it queries DNS. Type fileserver and Windows tries fileserver.ad.contoso.com. In Intune, you set it with a single ADMX-backed setting called DNS suffix search list, available in the settings catalog and mapped to the DNS_SearchList policy in the ADMX_DnsClient area.
The setup itself takes minutes. What deserves attention is what the policy changes underneath. Microsoft's own documentation notes two things most guides skip: the list applies only to single-label names, and configuring a global search list turns off primary DNS suffix devolution. Both are covered below, along with verification on the client.
Before you start
What you will learn
- You'll build an Intune settings catalog profile that pushes a DNS suffix search list to Windows devices, then verify it both in the portal and on the client.
- Without a suffix list, users have to type full FQDNs to reach internal file shares and intranet sites. With one, the short name resolves. The catch is that the policy replaces the default suffix behaviour rather than adding to it.
Requirements
- You need the Microsoft Intune admin center with rights to create and assign configuration profiles, plus at least one enrolled Windows test device you can sync on demand.
- Windows 10 version 2004, 20H2 or 21H1 with KB5005101 (build 10.0.19041.1202 or later), or Windows 11 version 21H2 and later. Pro, Enterprise, Education, and IoT Enterprise editions are supported.
- Intune Administrator, or the Policy and Profile Manager role
Good to know
- About 20 minutes to build and assign the profile, plus one device sync to see the result.
Quick answer
Create a settings catalog profile in Intune for Windows 10 and later, add the DNS suffix search list setting, enable it, and enter a comma-delimited list such as ad.contoso.com,sub.ad.contoso.com. Assign it to a device group, sync a test device, then confirm with Get-DnsClientGlobalSetting. The setting is device-scoped and writes to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient.
Microsoft Intune admin center > Devices > Manage devices > Configuration > Create > New policy > Windows 10 and later > Settings catalog > DNS suffix search listGet-DnsClientGlobalSettingStep-by-step tutorial
6 stepsCapture the current suffix configuration
Know what the device resolves with today, so you can tell what your policy changed and what it broke.
On a representative test device, open PowerShell and record the global DNS client settings plus the per-interface suffixes. Keep the output. It's your rollback reference.
Pay attention to UseDevolution and DevolutionLevel, and to any ConnectionSpecificSuffix values that arrive from DHCP.
Get-DnsClientGlobalSetting
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffixIf ConnectionSpecificSuffix is populated from DHCP, note it. Those suffixes stop being appended to single-label queries once the global search list takes over, so they usually need to go into your list.
Create the settings catalog profile
Get an empty Windows profile ready to hold the DNS setting.
Microsoft Intune admin center > Devices > Manage devices > Configuration > Create > New policySign in to the Microsoft Intune admin center with an account that can create configuration profiles.
Go to Devices > Manage devices > Configuration, then select Create > New policy. Set:
- Platform: Windows 10 and later
- Profile type: Settings catalog
Select Create, then give the profile a name that says what it does, such as Windows - DNS suffix search list. Add a description naming the suffixes and the reason, because the next admin will thank you.
The settings catalog surfaces settings generated from Windows configuration service providers. This one is ADMX-backed, so it behaves like its Group Policy equivalent under Computer Configuration > Network > DNS Client.
Add and configure the DNS suffix search list
Set the actual suffixes, in the order you want Windows to try them.
Configuration settings > Add settings > search "DNS suffix search list"On Configuration settings, select Add settings. In the settings picker, search for:
DNS suffix search listSelect the setting, close the picker, and switch it to Enabled. Enter your suffixes as a single comma-delimited string, no spaces:
ad.contoso.com,sub.ad.contoso.comOrder matters. Windows attaches one suffix at a time, left to right, and only moves to the next when the previous query fails.
Microsoft's policy text is explicit: use a comma-delimited string, and specify at least one suffix. Don't copy the format from the neighbouring DNS servers setting, which is space-delimited instead. Put the suffix that resolves most of your traffic first to keep query latency down.
Assign the profile to a pilot device group
Limit the blast radius while you find out what the change breaks.
Microsoft Intune admin center > Devices > Manage devices > Configuration > (profile) > AssignmentsSelect Next through Scope tags to Assignments. Add a dedicated pilot device group, not a user group.
Review the summary and select Create. Then sync one assigned device from Settings > Accounts > Access work or school, or from the device page in Intune.
DNS_SearchList is device-scoped only. Microsoft's Policy CSP reference marks it as Device with User explicitly unsupported, so assigning to a user group won't give you per-user behaviour.
Check the deployment status in Intune
Confirm the policy was delivered and processed before you go hunting on the client.
Microsoft Intune admin center > Devices > Manage devices > Configuration > (profile) > Device statusOpen the profile and review Device status or Device and user check-in status. Your test device should report Succeeded.
If it reports an error, check three things in order: the device's Windows build against the prerequisites, the assigned group membership, and whether a conflicting profile or an on-premises GPO also sets DNS client policy on hybrid-joined machines.
A Succeeded status means the policy was written, not that resolution behaves the way you expect. That's what the next step is for.
Verify the effective configuration on the client
Prove the suffixes are live and that short names actually resolve.
Back on the test device, read the effective global settings, confirm the registry value the policy writes, and run a real query against a short hostname you know exists.
Finish with an end-to-end test by opening an internal resource by short name, for example \\fileserver\share.
$global = Get-DnsClientGlobalSetting
$global | Select-Object UseSuffixSearchList, UseDevolution, DevolutionLevel
$global.SuffixSearchList
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -Name SearchList -ErrorAction SilentlyContinue
Resolve-DnsName fileserverRun ipconfig /flushdns first if the device previously failed to resolve those short names, since negative responses are cached. The registry value name SearchList comes from DnsClient.admx; Microsoft's Policy CSP table leaves the value name blank for list-style policies.
How to Read the Output, and What Changed Underneath
Get-DnsClientGlobalSetting is the single source of truth here. SuffixSearchList should list your suffixes in the exact order you typed them, and that order is the order Windows tries them: one suffix per query, left to right, stopping at the first success.
Two behaviours changed the moment the policy applied. First, the list only covers unqualified single-label names, meaning names with no dots at all. A query for server.corp is an unqualified multi-label name and is not handled by the search list; that needs the separate Allow DNS suffix appending to unqualified multi-label name queries policy. Second, per Microsoft's DNS client documentation, devolution isn't used once a global suffix search list is configured. If your estate leaned on devolution to walk up to a parent domain, add that parent to the list explicitly.
- SuffixSearchList matches your configured string in order, the device reports Succeeded in Intune, and short single-label names resolve without the FQDN.
- SuffixSearchList is empty despite a Succeeded status, which usually points at an unsupported Windows build or edition. Or resolution that previously worked now fails, which points at a suffix you dropped: the search list replaces the primary and connection-specific suffixes rather than adding to them.
- The global search list is in effect and is being used for single-label queries.
- Tried left to right. The first entry should cover most of your traffic.
- Under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient. Proof the policy landed, independent of the Intune report.
Troubleshooting
Short names with a dot in them still don't resolve
Cause: The DNS suffix search list only applies to unqualified single-label names. A name like server.corp contains a dot, so it's an unqualified multi-label name and falls outside the policy.
Enable Allow DNS suffix appending to unqualified multi-label name queries in the same settings catalog profile. It maps to DNS_AppendToMultiLabelName and lets Windows append suffixes to multi-label names after the original query fails.
Names that resolved before the policy now fail
Cause: The search list replaces the default suffix behaviour. Without it, Windows appends the primary DNS suffix and the connection-specific suffixes. With it, only the listed suffixes are tried, and devolution stops.
Compare against the baseline you captured in step 1. Add the primary DNS suffix, any DHCP-supplied connection-specific suffix, and any parent domain that devolution used to reach, then re-sync the device.
Intune reports Succeeded but SuffixSearchList is empty
Cause: The device runs a Windows build or edition that doesn't support the ADMX-backed policy, or a conflicting policy is winning.
Check the build with winver against the prerequisites: Windows 10 version 2004, 20H2 or 21H1 need KB5005101, Windows 11 needs 21H2 or later. On hybrid-joined devices run gpresult /h report.html and look for an on-premises GPO setting DNS client policy.
Name resolution feels slower after the change
Cause: Suffixes are tried sequentially, one query at a time. A long list means a failed lookup walks the whole list before giving up.
Trim the list to what's actually needed and put the busiest suffix first. Every entry after the one that succeeds costs nothing, but every entry before it costs a round trip.
The setting doesn't appear in the settings picker
Cause: The search term doesn't match, or the picker is filtered to a different category.
Clear any category filter and search the exact friendly name DNS suffix search list. In the Group Policy equivalent it lives under Computer Configuration > Network > DNS Client, which is a useful cross-check if you're unsure you've found the right setting.
Frequently asked questions
Does this work on Entra-joined devices with no Active Directory?
Yes. DNS_SearchList is a device-scoped ADMX-backed policy delivered over MDM, so domain join isn't a requirement. The device still needs to reach a DNS server that can answer for those suffixes, typically over VPN or a private connection.
Should the suffixes be separated by commas or spaces?
Commas. Microsoft's policy description calls for a comma-delimited string such as microsoft.com,serverua.microsoft.com. Note that the neighbouring DNS servers policy uses a space-delimited list instead, which trips people up.
Does the search list add to the domain suffix or replace it?
It replaces it. Microsoft's documentation states that when the policy isn't configured, the primary DNS suffix and connection-specific suffixes are appended to unqualified queries. Once you enable the search list, those are no longer used, so include them in your list if you still need them.
Can I assign a different suffix list per user?
No. The Policy CSP reference marks DNS_SearchList as device scope with user scope unsupported. If different populations need different lists, split them into separate device groups and assign a profile to each.
Do devices need a reboot for the suffixes to take effect?
Not usually. Microsoft calls out a mandatory Windows restart only for the Primary DNS suffix policy, not for the search list. A policy sync is normally enough, though ipconfig /flushdns helps when failed lookups were cached.
