The short answer

If you use Intune, create these CNAME records in each email domain your users sign in with:

NameTypePoints to
enterpriseenrollment.example.comCNAMEenterpriseenrollment-s.manage.microsoft.com
enterpriseregistration.example.comCNAMEenterpriseregistration.windows.net

If you use a different device management tool, or none, these findings cost nothing. They are information, not a grade.

What the records do

How Windows uses the enrollment CNAME to find Intune, with and without the record Top, no record: a user adds a work account to Windows. Windows looks up enterpriseenrollment for the email domain, finds nothing, and asks the user for a server address they do not know, so the device often stays unmanaged. Bottom, record present: the same lookup finds a CNAME to manage.microsoft.com, Windows reaches Intune, and the device enrolls and receives its security policies. No enrollment record User adds account user@example.com Windows looks up enterpriseenrollment Nothing found Asks for a server name Device unmanaged No policies applied Users stuck at enrollment Devices skip compliance checks Enrollment record present User adds account user@example.com Windows looks up enterpriseenrollment CNAME to Intune manage.microsoft.com Device enrolled Policies and updates Enrollment from the email address Device can meet access policies How Windows uses the enrollment CNAME to find Intune, with and without the record Top, no record: a user adds a work account to Windows. Windows looks up enterpriseenrollment for the email domain, finds nothing, and asks the user for a server address they do not know, so the device often stays unmanaged. Bottom, record present: the same lookup finds a CNAME to manage.microsoft.com, Windows reaches Intune, and the device enrolls and receives its security policies. No enrollment record User adds account user@example.com Windows looks up enterpriseenrollment Nothing found Asks for a server name Device unmanaged No policies applied Users stuck at enrollment Devices skip compliance checks Enrollment record present User adds account user@example.com Windows looks up enterpriseenrollment CNAME to Intune manage.microsoft.com Device enrolled Policies and updates Enrollment from the email address Device can meet access policies
Microsoft documents the records as optional but recommended. Without them, users must enter the enrollment server address by hand.

How DNS Panopticon detects it

Security Posture looks up the two CNAME records for the scanned domain. They show up on the Endpoint Security card but never cost points and never grade the card on their own, because many device management tools leave no trace in DNS.

FindingSeverityWhen it appears
Devices can enroll in Microsoft IntuneInformationenterpriseenrollment points to manage.microsoft.com.
Devices can register with Microsoft Entra IDInformationenterpriseregistration points to enterpriseregistration.windows.net.
No device management records seenInformationNeither record exists. This says nothing about tools such as Jamf, Workspace ONE, Kandji or Google endpoint management.
Device management records couldn’t be checkedInformationThe lookups did not answer.

How to check it yourself

CommandWhat to look for
nslookup -type=CNAME enterpriseenrollment.example.comAn answer ending in manage.microsoft.com.
nslookup -type=CNAME enterpriseregistration.example.comAn answer of enterpriseregistration.windows.net.
Resolve-DnsName enterpriseenrollment.example.com -Type CNAMEThe same in PowerShell.
dig +short CNAME enterpriseregistration.example.comThe same on macOS or Linux.

In the Intune admin center, Devices → Device onboarding → Enrollment → Windows → CNAME Validation tests a domain’s record for you.

Why it matters

  • Managed devices are the basis of Zero Trust. Conditional Access policies can require a compliant, managed device before granting access, which only works if devices can enroll easily.
  • Fewer unmanaged devices. When enrollment is hard, users give up and work from devices that get no policies, encryption or update enforcement.
  • What it reveals. The records show that an organisation uses Microsoft device management. That is low-risk information, and the same is visible from the Microsoft 365 sign-in page, so there is no reason to hide them.

How to set it up

  1. List your sign-in domains. Each email domain your users sign in with needs its own pair of records.
  2. Create the two CNAMEs from the table above at your DNS host. Use a TTL of an hour or so.
  3. Use the right target for your cloud. Commercial tenants use the targets above. Microsoft documents different targets for US government clouds, so check its page if that applies.
  4. Validate with CNAME Validation in the Intune admin center, or the lookups above.
  5. Set enrollment restrictions in Intune, so that only the device types and owners you intend can enroll.

FAQ

Do these records let anyone enroll a device into our Intune?

No. They only tell Windows where your enrollment service is. A user still has to sign in with a valid work account, and Intune enrollment restrictions decide which devices are accepted.

We use Jamf (or another tool). Should we create these records?

Only if you also use Intune or Entra ID registration. Other tools use their own enrollment methods, and DNS Panopticon does not count the absence of these records against you.

Is enterpriseregistration still needed with Entra join?

Microsoft recommends both records. enterpriseregistration helps devices find the Entra ID device registration service, particularly in hybrid and older setups.

Sources and further reading