A 311 resident-services desk wants a public-facing permitting mailbox on a verified city domain. What should the admin confirm in Microsoft 365 admin center before relying on that address?

A 311 resident-services desk that wants a public-facing permitting mailbox on a city domain must first confirm in Microsoft 365 admin center that the domain name is added and verified for the organization. Verified accepted domains are the foundation for trustworthy SMTP addressing and for service addresses that residents will see on forms and flyers. Without that verification, admins cannot reliably depend on @city.gov (or similar) addressing for the permitting mailbox.

Assigning Exchange Online licenses to service desk staff fails by concept: licenses prove staff can use Exchange services, not whether the city domain is added and verified for the organization's mail. Applying a retention policy to the permitting mailbox content fails because retention governs how long messages are kept, not whether the domain is verified for SMTP mail flow. Enforcing multi-factor authentication for delegated users fails because MFA protects sign-ins, not whether the domain is an accepted, verified email domain for the permitting mailbox.

Exam caveat: AB-900 domain questions reward the organization-level prerequisite—add and verify—before workload-specific configuration. Distractors often mix license, retention, or MFA scenarios into mail-domain problems; discard anything that does not establish tenant domain trust.

Operational check: open Microsoft 365 admin center domains, confirm the city domain is listed and verified, ensure the permitting mailbox primary or proxy address uses that domain, send a test message from an external account to the public address, and only then publish the address on 311 materials. If verification is pending or failed, fix DNS with the municipal DNS team before go-live.