Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

3.1.3. Domains, Branding, and Tenant Settings

💡 First Principle: Tenant-wide settings are the defaults every identity inherits before any policy runs — the sign-in names users type (domains), the pages they see (branding), and the baseline powers ordinary members hold (user, group, and device settings). Defaults are policy; review them like policy.

Custom domains: add contoso.com, prove ownership via a DNS TXT record, verify, then set primary. UPNs can then use the friendly domain. Rules the exam checks: the initial *.onmicrosoft.com domain is permanent; a domain must be empty of references before removal; federated vs managed domain status ties into 3.4's authentication choices; subdomains inherit verification of the parent in most cases.

Company branding customizes the sign-in experience (background, logo, hints, footer links) — including per-language variants. Its security value is anti-phishing familiarity and the fact that branding appears after home-realm discovery (users type their UPN first, then see your branding).

Tenant settings worth auditing (each a recurring one-liner in stems): User settings — can users register applications? (default yes; tighten it), access the Entra admin portal (restricting the portal is not restricting the API), LinkedIn connections. Group settings — who can create Microsoft 365 groups (default: everyone; commonly restricted to a group of owners), naming policy (prefix/suffix + blocked words), group expiration (auto-cleanup with owner renewal). Device settings — who may join/register devices, maximum devices per user, local administrator behavior on Entra-joined machines. External collaboration settings preview 3.3 — who can invite guests, and guest permission levels.

⚠️ Exam Trap: "Restrict access to the Microsoft Entra admin center" (user setting) only hides the portal from non-admins — PowerShell and Graph still work. Truly limiting what users can read/do requires role and permission changes, not the portal switch.

Reflection Question: Your org wants users to stop creating M365 groups ad hoc, but Teams creation must keep working for a "Team Creators" group. Which single group setting achieves both halves at once?

See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder18 professional certifications