Exchange Online is Microsoft’s cloud-hosted email and calendaring service within Microsoft 365.
For a senior Microsoft 365 administrator, knowing how to create a mailbox is not enough.
You should be able to troubleshoot:
- Mail delivery
- NDRs
- Accepted domains
- DNS and MX records
- Connectors
- Mail flow rules
- Shared mailboxes
- Distribution groups
- Mailbox permissions
- Send As
- Send on Behalf
- Message Trace
- Spam filtering
- Mailbox provisioning
- Hybrid mail flow
- On-premises to Exchange Online communication
- Exchange Online PowerShell
This part focuses specifically on those Exchange Online administration and troubleshooting areas.
General Microsoft 365 tenant administration, licensing fundamentals and generic Service Health concepts were covered in Day 5 Part 1 and are not repeated here.
1. Exchange Online
Q1. What is Exchange Online?
Exchange Online is Microsoft’s cloud-hosted messaging service.
It provides capabilities including:
- Calendaring
- Contacts
- Mailboxes
- Distribution groups
- Shared mailboxes
- Mail flow
- Anti-spam and anti-malware capabilities
- Mailbox administration
- Exchange Online PowerShell
Exchange Online is part of Microsoft 365.
Q2. What is an Exchange Online mailbox?
An Exchange Online mailbox is a cloud-hosted mailbox used to store a user’s email and other mailbox data.
Depending on the mailbox type and configuration, it can contain:
- Email messages
- Calendar
- Contacts
- Tasks
- Other mailbox data
Users can access Exchange Online through clients such as:
- Outlook
- Outlook on the web
- Mobile clients
- Supported applications using Microsoft APIs/protocols
User mailbox
A user mailbox is associated with an individual user account and is normally used by that individual.
Shared mailbox
A shared mailbox is intended for multiple authorized users to access a common mailbox.
Typical examples:
support@company.com
sales@company.com
info@company.com
Users are granted appropriate permissions such as:
- Full Access
- Send As
- Send on Behalf
A shared mailbox should not be treated as simply another user account.
Q4. What is Full Access permission on a mailbox?
Full Access allows a user to access the contents of another mailbox.
For example, a support administrator may receive Full Access to:
support@company.com
Full Access by itself does not automatically grant Send As permission.
If the user also needs to send messages as the mailbox, appropriate Send As or Send on Behalf permission must be configured.
Q5. What is Send As permission?
Send As allows a user to send a message that appears to come directly from another mailbox or mail-enabled object.
For example:
User: zohaib@company.com
Send As:
support@company.com
The recipient normally sees:
From: support@company.com
rather than “Zohaib on behalf of support.”
Q6. What is Send on Behalf permission?
Send on Behalf allows a user to send a message on behalf of another mailbox.
The recipient sees something similar to:
Zohaib on behalf of support@company.com
Therefore:
Send As ≠ Send on Behalf
The required permission should match the organization’s business requirement.
Because Full Access and sending permissions are separate.
I would check whether the user has:
- Send As
or
- Send on Behalf
depending on the required behavior.
I would also verify:
- Correct mailbox
- Correct user
- Permission assignment
- Permission propagation
- Outlook/client state
- Any mail-flow restrictions
2. Accepted Domains
Q8. What is an accepted domain in Exchange Online?
An accepted domain is a domain that Exchange Online recognizes as belonging to the organization for email processing.
For example:
company.com
If the domain is configured appropriately, Exchange Online can accept messages for recipients using that domain.
Microsoft documents two primary accepted-domain types in Exchange Online:
- Authoritative
- Internal relay
An authoritative domain means Exchange Online is authoritative for recipients in that domain.
If a message is addressed to an unknown recipient in an authoritative domain, Exchange Online rejects the message rather than attempting to relay it to another email system.
This is typically appropriate when all recipients for that domain are hosted in Microsoft 365.
Microsoft also associates authoritative-domain behavior with Directory-Based Edge Blocking for invalid recipients.
Q10. What is an internal relay accepted domain?
An internal relay domain allows recipients for the domain to exist both:
- In Microsoft 365
- On another email system such as an on-premises Exchange organization
Exchange Online delivers mail to known recipients in Microsoft 365 and can relay mail for unknown recipients to the configured external email system.
A connector is required for the Microsoft 365-to-on-premises routing path when mail for those recipients needs to be sent to the organization’s own email server.
This is particularly relevant in hybrid or coexistence scenarios.
| Feature | Authoritative | Internal Relay |
|---|---|---|
| Microsoft 365 owns recipients | Yes | Not necessarily all |
| Unknown recipient | Rejected | Can be routed elsewhere |
| Typical use | Fully cloud-hosted domain | Hybrid/coexistence |
| On-premises recipients | Generally not expected | Supported |
| Connector to on-premises | Not normally required for the domain itself | Required when mail must be relayed there |
The key interview answer is:
Authoritative means Exchange Online is responsible for recipients in the domain. Internal relay allows some recipients to remain on another messaging system.
3. Mail Flow and DNS
Q12. What is the purpose of an MX record in Microsoft 365 mail flow?
The MX record identifies where internet email for a domain should be delivered.
For a fully cloud-hosted Exchange Online environment, the domain’s MX record is normally configured to point to the Microsoft 365/Exchange Online Protection mail-routing endpoint.
Therefore:
Internet sender
↓
DNS MX lookup
↓
Microsoft 365
↓
Exchange Online processing
↓
Recipient mailbox
The exact MX value is tenant/domain-specific.
Q13. Does changing the MX record immediately migrate all mailboxes to Exchange Online?
No.
Changing the MX record changes where new inbound internet email is directed.
It does not itself:
- Create mailboxes
- Migrate mailbox data
- Configure users
- Complete hybrid configuration
- Move existing mailbox content
Mailbox migration and DNS/mail-flow changes are separate tasks.
Q14. A domain’s MX record still points to the on-premises Exchange server. Can users already have Exchange Online mailboxes?
Yes.
A hybrid or staged coexistence environment can have mailboxes in both locations.
The exact mail-flow design determines how messages are routed.
The important point is:
MX records determine the external inbound mail-routing path; they do not by themselves determine where every mailbox is hosted.
Microsoft documents hybrid/multiple-location scenarios where mailboxes exist both on-premises and in Exchange Online.
Q15. What is Exchange Online Protection (EOP)?
Exchange Online Protection is Microsoft’s cloud-based email protection service associated with Exchange Online and Microsoft 365.
It provides protection and mail-flow processing capabilities including areas such as:
- Anti-spam
- Anti-malware
- Mail filtering
- Mail-flow processing
Exchange Online mail is processed through Microsoft’s protection infrastructure before reaching the mailbox.
4. Connectors
Q16. What is an Exchange Online connector?
A connector is a configuration that controls or customizes mail flow between Microsoft 365 and another email system or organization.
Connectors can be used for scenarios such as:
- Exchange Online ↔ on-premises Exchange
- Microsoft 365 ↔ partner organization
- Devices/applications → Microsoft 365
- Specific routing/security requirements
Microsoft notes that most Microsoft 365 organizations do not need connectors for normal internet mail flow; connectors are used for specific scenarios.
Q17. When would you need a connector between Exchange Online and an on-premises Exchange server?
A connector may be required when mail needs to flow between:
Exchange Online
↕
On-premises Exchange
Examples include:
- Hybrid Exchange
- Coexistence
- On-premises recipients
- Specific routing requirements
- Secure mail flow between the environments
Microsoft’s documented configuration uses connectors for Microsoft 365-to-on-premises and on-premises-to-Microsoft 365 mail flow.
Q18. Does every Microsoft 365 organization need an Exchange connector for normal email?
No.
Normal internet mail flow generally does not require an administrator-created connector.
Connectors are needed for particular routing or security scenarios.
Examples include:
- On-premises Exchange
- Partner organizations
- Specific applications/devices
- Special mail-routing requirements
Q19. How would you configure a printer or application to send email through Microsoft 365?
The correct design depends on the application’s capabilities and the organization’s requirements.
Possible approaches can include:
- Authenticated SMTP where supported and appropriate
- Direct delivery
- Microsoft 365 connector-based relay
- Other Microsoft-supported application/device mail-flow methods
For connector-based relay, I would restrict the connector appropriately using supported controls such as source IP or certificate where applicable.
I would not create an unrestricted anonymous relay.
Microsoft documents connector scenarios specifically for printers, devices and applications.
Q20. What is the difference between an Exchange connector and a mail-flow rule?
Connector
Controls how mail flows between Microsoft 365 and another email system or organization.
Mail-flow rule
Applies conditions and actions to messages as they pass through Exchange Online.
For example:
Connector:
Microsoft 365 → On-premises Exchange
Mail-flow rule:
If message contains specific condition
↓
Add disclaimer / reject / redirect / modify / moderate
They solve different problems and can be used together.
5. Mail Flow Rules
Q21. What is a mail-flow rule in Exchange Online?
A mail-flow rule, also known as a transport rule, applies conditions, exceptions and actions to messages.
Examples include:
- Rejecting messages
- Redirecting messages
- Adding disclaimers
- Adding/modifying message headers
- Applying moderation
- Applying specific message-handling actions
Microsoft provides many conditions and exceptions for Exchange Online mail-flow rules.
Q22. Give an example of a mail-flow rule.
Example requirement:
Add a disclaimer to messages sent outside the organization.
The rule could be conceptually:
Condition:
Message is sent outside the organization
Action:
Append external-email disclaimer
The actual conditions and actions should be configured according to the organization’s requirements.
Q23. What should you check if a mail-flow rule is unexpectedly affecting messages?
Check:
- Rule conditions.
- Exceptions.
- Rule enabled/disabled status.
- Rule priority/order.
- Sender/recipient scope.
- Message headers.
- Message Trace.
- Whether another rule also processed the message.
- Whether a DLP policy or other security control was involved.
Message Trace can provide information about which mail-flow rule affected a message.
Q24. How do you troubleshoot a message that was rejected by a mail-flow rule?
I would use Message Trace.
I would identify:
- Sender
- Recipient
- Time
- Message ID if available
- Delivery status
- Rule information
- Action taken
Message Trace can show the mail-flow rule associated with a message and the action taken, such as rejection, quarantine, redirection or moderation.
6. Message Trace
Q25. What is Message Trace?
Message Trace is an Exchange Online troubleshooting tool used to track email messages through the service.
It can help determine:
- Whether a message was received
- Whether it was delivered
- Whether it failed
- Whether it was rejected
- Whether it was filtered
- Whether a mail-flow rule affected it
- Where the message is in processing
Microsoft documents Message Trace as a primary troubleshooting mechanism for Exchange Online mail-delivery problems.
Q26. A user says, “I sent an email, but the recipient never received it.” What would you do?
I would first collect:
- Sender address
- Recipient address
- Approximate time
- Subject
- Whether the recipient is internal or external
- NDR/bounce message if any
Then I would run Message Trace.
I would determine whether the message:
- Was received by Exchange Online
- Was delivered
- Failed
- Was rejected
- Was redirected
- Was quarantined/filtered
- Was affected by a mail-flow rule
I would then follow the trace result rather than guessing.
Q27. What information should you collect before running a Message Trace?
At minimum:
- Sender
- Recipient
- Date/time range
- Subject where useful
- Message ID if available
The more specific the search criteria, the easier it is to identify the correct message.
Microsoft recommends using as many useful search criteria as possible when investigating a message.
Q28. Can Message Trace show whether a mail-flow rule affected a message?
Yes.
Message Trace can identify mail-flow rule processing and show the action taken.
For example, a rule may have:
- Rejected
- Redirected
- Quarantined
- Moderated
- Modified
the message.
Microsoft documents this capability in its Message Trace guidance.
7. NDR Troubleshooting
Q29. What is an NDR?
NDR stands for Non-Delivery Report.
It is commonly known as a bounce message.
An NDR informs the sender that a message could not be delivered or encountered a delivery problem.
The NDR normally contains useful information such as:
- Recipient
- Error code
- Diagnostic information
- Remote server response
A senior administrator should troubleshoot the specific error rather than treating every NDR as the same problem.
Q30. A user receives a “recipient not found” NDR for an internal user. What would you check?
I would check:
- Recipient address.
- Whether the recipient object exists.
- Recipient type.
- Primary SMTP address.
- Proxy/alias addresses.
- Directory synchronization if applicable.
- Accepted domain configuration.
- Whether the recipient was recently created, renamed or migrated.
- Message Trace.
In hybrid environments, I would also verify that the recipient exists correctly in both the on-premises and cloud directory representations.
Q31. A user can email external recipients but cannot email one internal recipient. What does that suggest?
The issue is likely recipient-specific rather than a general outbound-mail problem.
I would investigate:
- Recipient address
- Recipient object
- Mailbox state
- Aliases
- Distribution-group restrictions
- Mail-flow rules
- Recipient restrictions
- Hybrid routing
- Message Trace
Comparing one working internal recipient with the affected recipient can quickly narrow the problem.
Q32. A user cannot send email to any external recipient, but internal email works. What would you investigate?
I would check:
- Mail-flow rules
- Outbound restrictions
- User/account restrictions
- Anti-spam policies
- Connectors
- Transport configuration
- Message Trace
- NDR details
- Service Health
Because internal mail works, I would focus on the external-mail path rather than mailbox connectivity alone.
8. Mailbox Permissions and Delegation
Check:
- Full Access permission.
- Correct mailbox.
- Correct user.
- Permission propagation.
- Outlook/client behavior.
- Whether the mailbox is actually a shared mailbox.
- Whether the user can access it through Outlook on the web.
- Any access restrictions.
Testing Outlook on the web can help distinguish a mailbox-permission issue from a local Outlook/client problem.
I would verify:
- Full Access
- Send As
- Send on Behalf
- Correct mailbox
- Permission propagation
- Outlook profile/client
- Message Trace/NDR if the message is submitted but rejected
Full Access alone does not imply Send As.
Q35. What is mailbox delegation?
Mailbox delegation means giving another user permissions to perform specific actions against a mailbox.
Common delegation permissions include:
- Full Access
- Send As
- Send on Behalf
Each provides a different capability.
9. Distribution Groups
Q36. What is a mail-enabled security group?
A mail-enabled security group combines:
- Security-group functionality
- Email distribution functionality
It can therefore be used for certain access-control scenarios while also receiving email.
This differs from a normal distribution group, which is primarily intended for email distribution.
Q37. A distribution group receives messages from internal users but not external senders. What would you check?
I would check the group’s configuration regarding external senders.
Then verify:
- Whether external senders are allowed.
- Whether the sender is actually external.
- Mail-flow rules.
- Message Trace.
- Group restrictions.
- Any anti-spam/security controls.
I would not change the setting without confirming that the business requirement really allows external senders.
10. Hybrid Exchange
Q38. What is a hybrid Exchange deployment?
A hybrid Exchange deployment connects an on-premises Exchange organization with Exchange Online.
It allows organizations to maintain mailboxes in both environments while providing integration between them.
Depending on the configuration, hybrid functionality can include:
- Mail flow
- Free/busy
- Mailbox migration
- Directory integration
- Cross-premises coexistence
The exact architecture depends on the Exchange versions and hybrid configuration.
Q39. In a hybrid environment, an Exchange Online user cannot email an on-premises mailbox. What would you check?
I would check:
- Recipient representation in Microsoft 365.
- Accepted domain configuration.
- Internal relay configuration where required.
- Microsoft 365-to-on-premises connector.
- On-premises Exchange receive configuration.
- DNS/routing.
- Firewall.
- TLS/certificate requirements.
- Message Trace.
- On-premises Exchange message tracking/logs.
Microsoft specifically documents connectors for routing mail between Microsoft 365 and on-premises email servers.
Q40. An on-premises user cannot email an Exchange Online user in a hybrid environment. What would you check?
I would check the reverse path:
On-premises Exchange
↓
Outbound routing
↓
Microsoft 365 connector
↓
Exchange Online
↓
Recipient mailbox
I would verify:
- Recipient object
- Accepted domain
- Connector
- DNS
- TLS
- Firewall
- On-premises send configuration
- Message Trace in Exchange Online
- On-premises message tracking
I would determine exactly where the message stops.
Q41. What is the purpose of connectors in hybrid mail flow?
Connectors define how mail should flow between the two environments.
For example:
On-premises Exchange
↓
Microsoft 365
and:
Microsoft 365
↓
On-premises Exchange
Both directions may require appropriate configuration.
Microsoft’s documented hybrid routing scenario uses connectors for both directions.
Q42. What is an internal relay domain useful for in hybrid Exchange?
An internal relay domain is useful when recipients for the same SMTP domain exist in both:
- Exchange Online
- On-premises Exchange
For example:
user1@company.com → Exchange Online
user2@company.com → On-premises Exchange
Exchange Online can deliver mail to cloud recipients and route messages for on-premises recipients through the appropriate connector.
Microsoft documents this exact use of internal relay domains in coexistence scenarios.
11. Exchange Online PowerShell
Q43. How do you connect to Exchange Online PowerShell?
Use the Exchange Online PowerShell module:
Connect-ExchangeOnline
Authentication then establishes the administrative session.
For security and compatibility, administrators should use the current supported Exchange Online PowerShell module and authentication methods.
Q44. How do you check a mailbox using PowerShell?
For example:
Get-Mailbox user@company.com
This can be used to inspect mailbox properties.
For broader reporting:
Get-Mailbox -ResultSize Unlimited
should be used carefully in large environments because returning very large datasets can consume resources.
Q45. How do you check mailbox permissions?
A common Exchange Online PowerShell command is:
Get-MailboxPermission -Identity support@company.com
For Send As permissions:
Get-RecipientPermission -Identity support@company.com
The exact permission type being investigated determines which cmdlet is appropriate.
Q46. How do you check distribution-group membership?
Use:
Get-DistributionGroupMember -Identity "Support Team"
For example:
Get-DistributionGroupMember -Identity "IT Support"
This is particularly useful when troubleshooting missing recipients.
12. Advanced Mail-Flow Scenarios
Q47. A message is delivered to the recipient’s Junk Email folder. Does Message Trace necessarily show it as failed?
No.
A message can be delivered to the mailbox and subsequently classified as spam.
Microsoft’s Message Trace documentation notes that spam-filtered messages can have a delivery status of Delivered even though they ended up in Junk Email or quarantine.
Therefore:
“Delivered” in Message Trace does not necessarily mean “arrived in the Inbox.”
You may need to investigate filtering and mailbox folders as well.
Q48. A message is delayed but not permanently rejected. How would you troubleshoot it?
I would:
- Run Message Trace.
- Check the message events.
- Determine where the message currently is in processing.
- Check for temporary failures.
- Check throttling or service issues.
- Check connectors if applicable.
- Check recipient-side processing.
- Review any NDR or delayed-delivery notification.
A temporary SMTP error does not necessarily mean permanent message failure.
Q49. A mail-flow rule was deleted after an email was processed. Can Message Trace still identify the rule?
Potentially, yes.
Microsoft documents that Message Trace can return a rule identifier even when the original rule no longer exists.
In such cases, the trace can show information indicating that the message was processed by a rule that has since been modified or deleted.
This is particularly useful during post-incident investigations.
Q50. How would you troubleshoot a complete Exchange Online mail-flow incident in production?
I would use a structured approach.
Step 1 — Define the scope
Determine:
- One sender?
- One recipient?
- One department?
- Internal mail?
- External mail?
- All users?
- One direction only?
Step 2 — Check Microsoft 365 Service Health
Determine whether Microsoft has an active Exchange Online incident.
Step 3 — Test a controlled message
For example:
User A → User B
User A → External recipient
External sender → User A
This helps identify which mail-flow direction is affected.
Step 4 — Run Message Trace
Check:
- Sender
- Recipient
- Time
- Status
- Events
- Rules
- Filtering
- Routing
Step 5 — Check DNS
For external mail flow, verify:
- MX
- SPF
- Other relevant DNS records
Step 6 — Check accepted domains
Verify:
- Correct domain
- Authoritative vs internal relay
- Recipient existence
Step 7 — Check connectors
If hybrid, partner or application routing is involved, verify the relevant connector.
Step 8 — Check mail-flow rules
Look for:
- Reject
- Redirect
- Quarantine
- Moderation
- Header modification
- Other actions
Step 9 — Check recipient configuration
Verify:
- Mailbox
- Aliases
- Group membership
- Permissions
- Restrictions
Step 10 — Check hybrid infrastructure if applicable
Investigate:
- On-premises Exchange
- Send/receive connectors
- DNS
- Firewall
- TLS/certificates
- Message tracking
Step 11 — Verify the fix
Send controlled test messages in each affected direction.
Step 12 — Document the root cause
Document:
- What failed
- Why it failed
- What was changed
- Which users were affected
- How the issue was resolved
- Preventive actions
This is the type of structured methodology expected from a senior Microsoft 365 administrator.
13. Important Exchange Online Commands
Connect to Exchange Online
Connect-ExchangeOnline
Get mailbox
Get-Mailbox user@company.com
Get user
Get-User user@company.com
Get distribution groups
Get-DistributionGroup
Get distribution-group members
Get-DistributionGroupMember -Identity "IT Support"
Check mailbox permissions
Get-MailboxPermission -Identity support@company.com
Check Send As permissions
Get-RecipientPermission -Identity support@company.com
View accepted domains
Get-AcceptedDomain
View connectors
Get-InboundConnector
Get-OutboundConnector
Note that current Microsoft documentation uses the concepts From and To in the Exchange admin center rather than emphasizing the older “inbound/outbound” terminology, although the PowerShell cmdlet names still use Get-InboundConnector and Get-OutboundConnector.
View transport rules
Get-TransportRule
14. Exchange Online Troubleshooting Flow
Use this process for most mail-flow incidents:
Email Problem
|
v
Define Scope
|
+-----------+-----------+
| |
Internal External
| |
v v
Check Recipient Check DNS/MX
| |
+-----------+-----------+
|
v
Message Trace
|
v
Check Mail Flow
|
+------------+------------+
| | |
Rule/Policy Connector Filtering
| | |
+------------+------------+
|
v
Check Recipient
|
v
Check Hybrid if applicable
|
v
Test Fix
|
v
Verify Delivery
|
v
Root Cause
15. Quick Revision
Exchange Online
- Exchange Online = cloud-hosted Microsoft messaging service.
- User mailbox = individual mailbox.
- Shared mailbox = common mailbox for authorized users.
- Full Access ≠ Send As.
- Send As ≠ Send on Behalf.
Accepted Domains
- Authoritative → Exchange Online is responsible for recipients in the domain.
- Internal relay → recipients can exist in Microsoft 365 and another messaging system.
- Internal relay is important in coexistence/hybrid scenarios.
Mail Flow
- MX determines external inbound routing.
- Connectors customize mail flow between Microsoft 365 and other systems.
- Mail-flow rules apply conditions/actions to messages.
- Message Trace is a primary troubleshooting tool.
NDR
- NDR = Non-Delivery Report.
- Always investigate the specific error/code.
- Recipient problems, routing, rules, connectors and filtering can all produce delivery problems.
Hybrid
On-premises Exchange
↕
Connectors
↕
Exchange Online
Check both directions separately.
PowerShell
Connect-ExchangeOnline
Get-Mailbox
Get-User
Get-DistributionGroup
Get-DistributionGroupMember
Get-MailboxPermission
Get-RecipientPermission
Get-AcceptedDomain
Get-InboundConnector
Get-OutboundConnector
Get-TransportRule
16. Exam Answer Summary
1. What is an accepted domain?
An accepted domain is a domain that Exchange Online recognizes for mail processing. An authoritative domain means Exchange Online is responsible for recipients in that domain, while an internal relay domain allows some recipients to remain on another messaging system.
2. What is a connector?
A connector is a mail-flow configuration used to control or customize mail flow between Microsoft 365 and another email system, organization, partner or application.
3. What is Message Trace?
Message Trace is an Exchange Online troubleshooting tool used to track messages and determine whether they were received, delivered, delayed, rejected, filtered or affected by a mail-flow rule.
4. Full Access vs Send As?
Full Access allows a user to access a mailbox. Send As allows the user to send messages that appear to originate directly from that mailbox. Full Access alone does not grant Send As.
5. How would you troubleshoot an NDR?
I would collect the sender, recipient, time and NDR error, then run Message Trace and identify where the message failed. I would check recipient configuration, accepted domains, mail-flow rules, connectors, filtering, DNS and hybrid routing as applicable.
6. How would you troubleshoot hybrid mail flow?
I would identify the direction of the failure, verify the recipient representation, accepted domain, connector, DNS, firewall, TLS/certificate requirements and Message Trace, then correlate the cloud trace with on-premises Exchange message tracking.
17. Senior Interview Tip
For Exchange Online troubleshooting, avoid saying:
“I will check the mailbox.”
Instead, think in terms of the complete mail-flow path:
Sender
↓
DNS / MX
↓
Microsoft 365 / EOP
↓
Mail-flow rules
↓
Connectors if applicable
↓
Recipient resolution
↓
Mailbox
↓
Junk / Inbox / Quarantine
For hybrid:
Internet
↓
Microsoft 365
↓
Connector
↓
On-premises Exchange
↓
Recipient
or the reverse direction.
The senior-level skill is knowing where the message stopped and why.
Microsoft 365 Progress
Part 1 — Microsoft 365 Administration, Tenant & Core Concepts
Covered:
- Microsoft 365 architecture
- Tenants
- Domains
- Subscriptions
- Licenses
- Service plans
- Admin centers
- Administrative roles
- Least privilege
- Users and groups
- Microsoft 365 groups
- Distribution groups
- Service Health
- Message Center
- Basic Microsoft 365 troubleshooting
- Microsoft 365 PowerShell
Part 2 — Exchange Online Administration, Mail Flow & Troubleshooting
Covered:
- Exchange Online
- Mailboxes
- Shared mailboxes
- Full Access
- Send As
- Send on Behalf
- Accepted domains
- Authoritative domains
- Internal relay
- MX
- Exchange Online Protection
- Connectors
- Mail-flow rules
- Message Trace
- NDRs
- Distribution groups
- Mail-enabled security groups
- Hybrid Exchange
- Hybrid mail flow
- Exchange Online PowerShell
- Advanced mail-flow troubleshooting
- Production Exchange incidents
Next Part
The next part will add the Microsoft 365 collaboration layer without repeating Parts 1–2.
It will cover:
- SharePoint Online architecture
- SharePoint sites
- Communication sites
- Team sites
- Hub sites
- SharePoint permissions
- SharePoint groups
- Microsoft 365 group-connected sites
- OneDrive architecture
- OneDrive vs SharePoint
- Sharing
- External sharing
- Sync
- Storage
- Version history
- Recycle Bin
- Site collection concepts
- Site permissions troubleshooting
- OneDrive provisioning/troubleshooting
- Real-world SharePoint/OneDrive scenarios