MS-102 Deploy and manage a Microsoft 365 tenant Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Update the MX record at the DNS registrar to point to Exchange Online

  Why it's wrong here

  Updating the MX record at the DNS registrar makes the internet point inbound SMTP traffic for tailspintoys.com to Exchange Online, but this is a downstream mail-flow step. Before doing so, the accepted domain must be set as authoritative so Exchange Online knows it owns routing for the domain and will accept messages for recipients rather than relaying them back to the previous mail system. If you change MX first while the domain is still marked as Internal relay, mail can loop, bounce, or remain stuck in queue because Exchange Online still believes another system is responsible for that domain. The MX update is necessary only after the domain type change is completed.

• ✓

  Change the domain type from 'Internal relay' to 'Authoritative' in Exchange admin center

  Why this is correct

  In the Exchange admin center, open Mail flow > Accepted domains, select the tailspintoys.com entry, and set its type to Authoritative. This tells Exchange Online that it is the only authorized mail system for that domain, so it will accept all inbound messages and attempt to deliver them to valid mailboxes in the organization, while generating non-delivery reports for unknown recipients. This is the required first configuration task because neither creating recipients nor updating MX records will make Exchange Online the owner of the address space until the accepted domain type is changed.

• ✗

  Create the shared mailbox 'info@tailspintoys.com' in Exchange Online

  Why it's wrong here

  Creating the shared mailbox info@tailspintoys.com does not make Exchange Online authoritative for the domain and therefore does not ensure mail is routed correctly. A shared mailbox is only a recipient object that must have a valid, verified domain as its email address, but if the accepted domain is still in Internal relay mode, messages to info@ may be relayed to the on-premises/third-party system or rejected because Exchange Online does not consider itself responsible for the domain. Provisioning a shared mailbox is a post-domain-change action; it should follow the authoritative configuration, not replace it.

• ✗

  Disable the internal relay option for the domain in the Microsoft 365 admin center

  Why it's wrong here

  There is no 'Internal relay' toggle in the Microsoft 365 admin center; the mail-routing behavior for an accepted domain is controlled by the domain type in the Exchange admin center, under Mail flow > Accepted domains. 'Internal relay' is one of the accepted domain types, not an optional checkbox that can simply be switched off, and disabling a relay flag would not convert the domain to authoritative. The correct change is to edit the accepted domain and select 'Authoritative' (or use Set-AcceptedDomain in PowerShell), which changes both how Exchange Online advertises responsibility for the domain and how it routes unknown recipients.

Go deeper

Related to this question