Beatfox602

Sign in with PIN or smartcard. Microsoft Exchange is Microsoft's email server solution. In layman's terms, it's a piece of software that runs on a server and manages all your emails. Incoming, outgoing, saved, drafts, calendars–everything is done through Microsoft Exchange and stored on the server. Microsoft Exchange isn’t the only way a company can manage their emails.

• Microsoft Exchange 365
• Microsoft Exchange 365 Account

1. In Exchange server, type the name of your Exchange server. If you’re connecting to your Microsoft 365 email, the Exchange server name is partner.outlook.cn. If you’re not using Microsoft 365, see Find your Exchange server name later in this article. The Domain box will be populated with the text Optional. Leave the Domain text box empty.
2. Get the essential productivity tools that just keep getting better with Microsoft 365. Exchange Online is a hosted solution that you can get by itself or with a Microsoft 365 subscription. Exchange Server 2019 is an on-premises solution. See plans & pricing.
3. Open a service request in the Microsoft 365/Office 365 Admin Center. Premium, Unified and Paid Technical Support. Get technical support for on-premise Microsoft products and services. Microsoft Store Support. Get help with choosing a Microsoft product, or ask about a previous purchase from the online or physical store.

Important

The improved Microsoft 365 security center is now available. This new experience brings Defender for Endpoint, Defender for Office 365, Microsoft 365 Defender, and more into the Microsoft 365 security center. Learn what's new.

Applies to

Domain-based Message Authentication, Reporting, and Conformance (DMARC) works with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate mail senders and ensure that destination email systems trust messages sent from your domain. Implementing DMARC with SPF and DKIM provides additional protection against spoofing and phishing email. DMARC helps receiving mail systems determine what to do with messages sent from your domain that fail SPF or DKIM checks.

Tip

Visit the Microsoft Intelligent Security Association (MISA) catalog to view third-party vendors offering DMARC reporting for Microsoft 365.

How do SPF and DMARC work together to protect email in Microsoft 365?

An email message may contain multiple originator or sender addresses. These addresses are used for different purposes. For example, consider these addresses:

• 'Mail From' address: Identifies the sender and specifies where to send return notices if any problems occur with the delivery of the message, such as non-delivery notices. This appears in the envelope portion of an email message and is not usually displayed by your email application. This is sometimes called the 5321.MailFrom address or the reverse-path address.

• 'From' address: The address displayed as the From address by your mail application. This address identifies the author of the email. That is, the mailbox of the person or system responsible for writing the message. This is sometimes called the 5322.From address.

SPF uses a DNS TXT record to provide a list of authorized sending IP addresses for a given domain. Normally, SPF checks are only performed against the 5321.MailFrom address. This means that the 5322.From address is not authenticated when you use SPF by itself. This allows for a scenario where a user can receive a message which passes an SPF check but has a spoofed 5322.From sender address. For example, consider this SMTP transcript:

In this transcript, the sender addresses are as follows:

• Mail from address (5321.MailFrom): phish@phishing.contoso.com

• From address (5322.From): security@woodgrovebank.com

If you configured SPF, then the receiving server performs a check against the Mail from address phish@phishing.contoso.com. If the message came from a valid source for the domain phishing.contoso.com then the SPF check passes. Since the email client only displays the From address, the user sees that this message came from security@woodgrovebank.com. With SPF alone, the validity of woodgrovebank.com was never authenticated.

When you use DMARC, the receiving server also performs a check against the From address. In the example above, if there is a DMARC TXT record in place for woodgrovebank.com, then the check against the From address fails.

What is a DMARC TXT record?

Like the DNS records for SPF, the record for DMARC is a DNS text (TXT) record that helps prevent spoofing and phishing. You publish DMARC TXT records in DNS. DMARC TXT records validate the origin of email messages by verifying the IP address of an email's author against the alleged owner of the sending domain. The DMARC TXT record identifies authorized outbound email servers. Destination email systems can then verify that messages they receive originate from authorized outbound email servers.

Microsoft's DMARC TXT record looks something like this:

Microsoft sends its DMARC reports to Agari, a third party. Agari collects and analyzes DMARC reports. Please visit the MISA catalog to view more third-party vendors offering DMARC reporting for Microsoft 365.

Implement DMARC for inbound mail

You don't have to do a thing to set up DMARC for mail that you receive in Microsoft 365. We've taken care of everything for you. If you want to learn what happens to mail that fails to pass our DMARC checks, see How Microsoft 365 handles inbound email that fails DMARC.

Implement DMARC for outbound mail from Microsoft 365

If you use Microsoft 365 but you aren't using a custom domain, that is, you use onmicrosoft.com, you don't need to do anything else to configure or implement DMARC for your organization. SPF is already set up for you and Microsoft 365 automatically generates a DKIM signature for your outgoing mail. For more information about this signature, see Default behavior for DKIM and Microsoft 365.

If you have a custom domain or you are using on-premises Exchange servers in addition to Microsoft 365, you need to manually implement DMARC for your outbound mail. Implementing DMARC for your custom domain includes these steps:

Step 1: Identify valid sources of mail for your domain

If you have already set up SPF then you have already gone through this exercise. However, for DMARC, there are additional considerations. When identifying sources of mail for your domain there are two questions you need to answer:

• What IP addresses send messages from my domain?

• For mail sent from third parties on my behalf, will the 5321.MailFrom and 5322.From domains match?

Step 2: Set up SPF for your domain

Now that you have a list of all your valid senders you can follow the steps to Set up SPF to help prevent spoofing.

For example, assuming contoso.com sends mail from Exchange Online, an on-premises Exchange server whose IP address is 192.168.0.1, and a web application whose IP address is 192.168.100.100, the SPF TXT record would look like this:

As a best practice, ensure that your SPF TXT record takes into account third-party senders.

Microsoft Exchange 365

Step 3: Set up DKIM for your custom domain

Once you have set up SPF, you need to set up DKIM. DKIM lets you add a digital signature to email messages in the message header. If you do not set up DKIM and instead allow Microsoft 365 to use the default DKIM configuration for your domain, DMARC may fail. This is because the default DKIM configuration uses your initial onmicrosoft.com domain as the 5322.From address, not your custom domain. This forces a mismatch between the 5321.MailFrom and the 5322.From addresses in all email sent from your domain.

If you have third-party senders that send mail on your behalf and the mail they send has mismatched 5321.MailFrom and 5322.From addresses, DMARC will fail for that email. To avoid this, you need to set up DKIM for your domain specifically with that third-party sender. This allows Microsoft 365 to authenticate email from this 3rd-party service. However, it also allows others, for example, Yahoo, Gmail, and Comcast, to verify email sent to them by the third-party as if it was email sent by you. This is beneficial because it allows your customers to build trust with your domain no matter where their mailbox is located, and at the same time Microsoft 365 won't mark a message as spam due to spoofing because it passes authentication checks for your domain.

For instructions on setting up DKIM for your domain, including how to set up DKIM for third-party senders so they can spoof your domain, see Use DKIM to validate outbound email sent from your custom domain.

Step 4: Form the DMARC TXT record for your domain

Although there are other syntax options that are not mentioned here, these are the most commonly used options for Microsoft 365. Form the DMARC TXT record for your domain in the format:

where:

• domain is the domain you want to protect. By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as housewares.contoso.com or plumbing.contoso.com.

• TTL should always be the equivalent of one hour. The unit used for TTL, either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds), will vary depending on the registrar for your domain.

• pct=100 indicates that this rule should be used for 100% of email.

• policy specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to none, quarantine, or reject.

For information about which options to use, become familiar with the concepts in Best practices for implementing DMARC in Microsoft 365.

Examples:

• Policy set to none

• Policy set to quarantine

• Policy set to reject

Once you have formed your record, you need to update the record at your domain registrar. For instructions on adding the DMARC TXT record to your DNS records for Microsoft 365, see Create DNS records for Microsoft 365 when you manage your DNS records.

Best practices for implementing DMARC in Microsoft 365

You can implement DMARC gradually without impacting the rest of your mail flow. Create and implement a roll-out plan that follows these steps. Do each of these steps first with a sub-domain, then other sub-domains, and finally with the top-level domain in your organization before moving on to the next step.

1. Monitor the impact of implementing DMARC

   Start with a simple monitoring-mode record for a sub-domain or domain that requests that DMARC receivers send you statistics about messages that they see using that domain. A monitoring-mode record is a DMARC TXT record that has its policy set to none (p=none). Many companies publish a DMARC TXT record with p=none because they are unsure about how much email they may lose by publishing a more restrictive DMARC policy.

   You can do this even before you've implemented SPF or DKIM in your messaging infrastructure. However, you won't be able to effectively quarantine or reject mail by using DMARC until you also implement SPF and DKIM. As you introduce SPF and DKIM, the reports generated through DMARC will provide the numbers and sources of messages that pass these checks, and those that don't. You can easily see how much of your legitimate traffic is or isn't covered by them, and troubleshoot any problems. You'll also begin to see how many fraudulent messages are being sent, and from where.

2. Request that external mail systems quarantine mail that fails DMARC

   When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, and you understand the impact of implementing DMARC, you can implement a quarantine policy. A quarantine policy is a DMARC TXT record that has its policy set to quarantine (p=quarantine). By doing this, you are asking DMARC receivers to put messages from your domain that fail DMARC into the local equivalent of a spam folder instead of your customers' inboxes.

3. Request that external mail systems not accept messages that fail DMARC

   The final step is implementing a reject policy. A reject policy is a DMARC TXT record that has its policy set to reject (p=reject). When you do this, you're asking DMARC receivers not to accept messages that fail the DMARC checks.

4. How to set up DMARC for subdomain?

   DMARC is implemented by publishing a policy as a TXT record in DNS and is hierarchical (e.g. a policy published for contoso.com will apply to sub.domain.contonos.com unless a different policy is explicitly defined for the subdomain). This is useful as organizations may be able to specify a smaller number of high-level DMARC records for wider coverage. Care should be taken to configure explicit subdomain DMARC records where you do not want the subdomains to inherit the top-level domain's DMARC record.

   Also, you can add a wildcard-type policy for DMARC when subdomains shouldn't be sending email, by adding the sp=reject value. For example:

How Microsoft 365 handles outbound email that fails DMARC

If a message is outbound from Microsoft 365 and fails DMARC, and you have set the policy to p=quarantine or p=reject, the message is routed through the High-risk delivery pool for outbound messages. There is no override for outbound email.

If you publish a DMARC reject policy (p=reject), no other customer in Microsoft 365 can spoof your domain because messages will not be able to pass SPF or DKIM for your domain when relaying a message outbound through the service. However, if you do publish a DMARC reject policy but don't have all of your email authenticated through Microsoft 365, some of it may be marked as spam for inbound email (as described above), or it will be rejected if you do not publish SPF and try to relay it outbound through the service. This happens, for example, if you forget to include some of the IP addresses for servers and apps that send mail on behalf of your domain when you form your DMARC TXT record.

How Microsoft 365 handles inbound email that fails DMARC

If the DMARC policy of the sending server is p=reject, Exchange Online Protection (EOP) marks the message as spoof instead of rejecting it. In other words, for inbound email, Microsoft 365 treats p=reject and p=quarantine the same way. Admins can define the action to take on messages classified as spoof within the anti-phishing policy.

Microsoft 365 is configured like this because some legitimate email may fail DMARC. For example, a message might fail DMARC if it is sent to a mailing list that then relays the message to all list participants. If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they will be marked as spam and not rejected. If desired, users can still get these messages in their inbox through these methods:

• Users add safe senders individually by using their email client.

• Administrators can update the Spoof Intelligence reporting to allow the spoof.

• Administrators create an Exchange mail flow rule (also known as a transport rule) for all users that allows messages for those particular senders.

For more information, see Create safe sender lists.

How Microsoft 365 utilizes Authenticated Received Chain (ARC)

All hosted mailboxes in Microsoft 365 will now gain the benefit of ARC with improved deliverability of messages and enhanced anti-spoofing protection. ARC preserves the email authentication results from all participating intermediaries, or hops, when an email is routed from the originating server to the recipient mailbox. Before ARC, modifications performed by intermediaries in email routing, like forwarding rules or automatic signatures, could cause DMARC failures by the time the email reached the recipient mailbox. With ARC, the cryptographic preservation of the authentication results allows Microsoft 365 to verify the authenticity of an email's sender.

Microsoft 365 currently utilizes ARC to verify authentication results when Microsoft is the ARC Sealer, but plan to add support for third-party ARC sealers in the future.

Troubleshooting your DMARC implementation

If you have configured your domain's MX records where EOP is not the first entry, DMARC failures will not be enforced for your domain.

If you're a customer, and your domain's primary MX record does not point to EOP, you will not get the benefits of DMARC. For example, DMARC won't work if you point the MX record to your on-premises mail server and then route email to EOP by using a connector. In this scenario, the receiving domain is one of your Accepted-Domains but EOP is not the primary MX. For example, suppose contoso.com points its MX at itself and uses EOP as a secondary MX record, contoso.com's MX record looks like the following:

All, or most, email will first be routed to mail.contoso.com since it's the primary MX, and then mail will get routed to EOP. In some cases, you might not even list EOP as an MX record at all and simply hook up connectors to route your email. EOP does not have to be the first entry for DMARC validation to be done. It just ensures the validation, as we cannot be certain that all on-premise/non-O365 servers will do DMARC checks. DMARC is eligible to be enforced for a customer's domain (not server) when you set up the DMARC TXT record, but it is up to the receiving server to actually do the enforcement. If you set up EOP as the receiving server, then EOP does the DMARC enforcement.

For more information

Want more information about DMARC? These resources can help.

• Anti-spam message headers includes the syntax and header fields used by Microsoft 365 for DMARC checks.

• Take the DMARC Training Series from M³AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).

• Use the checklist at dmarcian.

• Go directly to the source at DMARC.org.

See also

This full step-by-step guide is available as a PDF. Please click here to download!

If you are planning an Exchange to Office 365 migration, then it can be quite confusing to understand the steps you need to take and in which order.

In this article, we’ll walk through the steps and decisions you need to take when migrating to Exchange Online. In part one we’ll consider the two most important first steps – deciding upon a migration approach and performing the core steps for identity. In part two, we’ll perform the Exchange Hybrid configuration and perform the migration of Mailboxes.

And, although we’re going to cover a lot of information in a short amount of time, you’ll find detailed guidance linked throughout.

Preparing your Exchange to Office 365 Migration

Before you begin a migration, it’s important to make sure that the source environment you are migrating from is in a good state.

If the Exchange environment you are running today isn’t healthy, then often that can serve as the motivator to move. After all, what can be an easier solution to bad day-to-day Exchange performance than moving to Office 365?

Unfortunately if you are experiencing day-to-day issues with Exchange, such as user issues accessing Exchange remotely, error messages and slow access times to mailboxes – or worse, database corruption – then moving to Office 365 will most likely be another source of trouble; not just for people accessing the environment you are trying to migrate from, but also when migrating as it’s likely you’ll experience failures along the way.

Microsoft Exchange 365 Account

Your first step before beginning a migration should be to ensure that the environment is reasonably error free and correct any underlying issues prior to migration.

Read More: Patching your Exchange Environment

Hybrid migration or tool-based migration?

If you are thinking about moving your Exchange environment to Office 365 then you’re probably aware there are many options available.

From Microsoft, you have options for a Staged Migration and a Cutover Migration as well as a Hybrid Migration, and from third-party vendors a large number of different tools on the market for email archive migrations.

In general, if you have a version of Exchange Server that’s supported by Microsoft (Exchange Server 2010 and above) and it is part of your Active Directory then your default option should be an Exchange Hybrid Migration.

An Exchange Hybrid is based on either minimal or full Exchange Hybrid and creates a relationship between your on-premises Exchange servers and Exchange Online. This allows native mailbox moves, similar to between on-premises Exchange servers, with Outlook clients natively switching over without even needing to re-download offline copies of email. With full Hybrid, this also extends to secure mail flow between the two environments and co-existence functionality like free/busy and calendar sharing.

Azure AD

Azure AD Connect complements Exchange Hybrid, and you should expect to use Hybrid if you plan to synchronize your identity to the cloud. Azure AD Connect synchronizes your local Active Directory domain to Office 365, creating a copy of local AD accounts in Azure Active Directory that link back to the master copies. Azure AD Connect is also the part of the puzzle that maintains a consistent Global Address List between on-premises and the cloud.

Because AD and Azure AD Connect understand when there’s an existing Exchange organization in place, existing mailboxes on-premises won’t have mailboxes created in Office 365. You’ll be expected to use Exchange Hybrid to move mailboxes.

With a tool-based migration, the same rules do not apply. A fully Microsoft-supported Exchange Hybrid migration provides an excellent experience. However, especially in multi-forest environments it can be complex to set up correctly, hosted environments often do not allow for Azure AD Connect or Exchange Hybrid to be configured; and if you have legacy versions of Exchange it can involve installing additional servers running Exchange 2010 or higher which include the Hybrid components. Therefore, there are valid uses for a bespoke tool to migrate email to Office 365 – but in this article, we’ll assume you’ve made the decision to use Exchange Hybrid.

Read More: Methods for migrating to Office 365

Understanding pre-requisites and dependencies

Once you’ve decided that migrating to Office 365 using Exchange Hybrid is suitable for your organization, and you have a healthy environment to migrate, then you need to ensure you’ve completed necessary planning activities.

Many organizations who begin this journey will at this point ensure they have a design in place to support the changes that will take place. However, as you aren’t designing Office 365 or Exchange Online and instead designing the bridge to Office 365 then the design is often not as detailed as a full Exchange migration.

Instead, you are focusing on the changes necessary to your existing environment to make sure it is ready for the changes. In this article, we won’t cover this, but it’s worth remembering that most organizations, large and small, don’t just head into the unknown without making plans first.

The key pre-requisite for migrating to Exchange is ensuring the correct identity model is in place, first. There is a variety of options available when choosing an identity, but the most common scenario will be to utilize Azure AD Connect with synchronized identities and password hash sync.

Prior to this, we’ll perform a number of key tasks.

First, we’ll ensure that we’ve added all of our custom domains to our Office 365 tenant. These will need to match the email domains we use on-premises:

<Portal Domain

To add a new domain, choose <Path> and Add Domain. You’ll need to follow the steps, and verify each domain using a TXT record, similar to the one shown below:

Use your DNS provider’s control panel to add the corresponding TXT record to each domain, then continue the verification process.

Once you reach the point to add additional DNS records, it’s important you choose to Skip adding records such as Autodiscover or MX record changes.

This is crucial because at this point in the process your email is still looked after by on-premises systems, and you do not want to redirect clients to Office 365. The Hybrid relationship we create will manage this for us, later on. Best place to buy macbook air.

We’ll sign-in to Office 365 using a login ID in the same format as an email address. In an Exchange Hybrid relationship, we expect this to match the Active Directory UserPrincipalName for each user. However, in many organizations, the login IDs are not in a format that will be suitable

In the above example, the issue is with the UserPrincipalName (UPN) suffix – the contoso.local part that typically matches the full AD Forest Name. To resolve this, we’ll add a UPN suffix to match our email domains registered with Office 365 in Active Directory Domains and Trusts:

We’ll then update the UserPrincipalName value for each user using Active Directory users and computers (or, ideally, PowerShell) to match the email address:

In most cases, this will not cause any user issues with sign-in, as nearly all organizations still expect users to login with the Pre-Windows 2000 / CONTOSOusername format. However, you should always validate this before making changes. After making these changes, the formats for login IDs will be similar to below:

We’ll also run the Microsoft IDFix tool against the domain. This step will highlight other issues within your Active Directory relevant to the domain sync. IDFix identifies errors, such as invalid email addresses (known as Proxy Addresses), invalid characters in usernames and other data and common issues, like using an invalid UPN suffix.

Use the list of issues identified by ID to make the corrections recommended, then install Azure AD Connect. In the example below, we’ve chosen Use Express Settings:

We’ll then follow the wizard steps to connect both as a global administrator to our Azure AD/Office 365 tenant, and to our local Active Directory. You’ll remember above though we added an additional UPN suffix to our local AD due to it not being a valid domain to use with Office 365. This will be highlighted during the installation wizard, however, because we’ve dealt with this it will be safe to continue:

Because we chose the Express Settings the wizard has pre-selected that we’ll use Password hash synchronisation. Our final choice is to ensure that an Exchange Hybrid Deployment is selected before beginning the install. This will ensure Azure AD Connect writes-back Exchange-related attributes to our local AD:

Once initial synchronization completes, you should be able to access the Microsoft 365 Admin Center and navigate to Users>Active Users and see synchronized accounts. You’ll see your AD users with a Sync Type of Synced with Active Directory:

Further Reading:

Other areas you’ll need to consider

In addition, before you migrate mailboxes to Office 365, you need to consider other pre-requisites. Key areas you need to consider include:

Legacy Archiving

If you currently use a solution like Veritas Enterprise Vault for archiving or journaling email then this configuration will not work as-is with Office 365. Instead, the most common approach is to move archives to Exchange Online after migrating mailboxes.

In this scenario, stubs (or shortcuts, to use the EV term) will be re-hydrated with the original archive messages; or moved to archive mailboxes in Exchange Online. Quadrotech’s Archive Shuttle can handle this task and works well with an Exchange Hybrid migration.

Outlook clients

You’ll need to run a supported version of Outlook when connecting to Office 365. The following versions of Outlook are supported:

• Office 365 ProPlus
• Outlook 2019
• Outlook 2016
• Outlook 2013

Ideally, use the newest version (Office 365 ProPlus) that you have available. Outlook 2013, 2016 and 2019 will work with Office 365. If you are running Outlook 2010 today, then this can work with Exchange Online but for security reasons you will most likely want to block the protocols it uses.

Mobile devices

If you use Microsoft ActiveSync today to connect to Exchange on-premises, then you can allow mobile devices to continue to use this protocol when connecting to Exchange Online. Expect though in all but the most unusual circumstances to need to reconfigure ActiveSync devices to work with Exchange Online.

Instead, consider deploying the new Outlook mobile client to devices. If you choose to move to Microsoft Intune, then you can also use Intune to deploy and configure the new Outlook client. This supports additionally functionality to ActiveSync including the ability to schedule Teams meetings directly from the client, and new functionality like Focused Inbox. From a security perspective it can ensure that you have control over data, such as attachment downloads.

Internet Publishing

The way you publish Exchange Server to the internet is important for a Hybrid deployment. This used to be crucial for all implementations, however, the new Hybrid Agent means that we can avoid many of the more complex areas for Exchange firewall and SSL certificate configuration for simple deployments.

There are a number of areas you must consider though:

• Autodiscover – In a Hybrid environment the Autodiscover service on-premises will be used by both on-premises mailboxes and Exchange Online mailboxes in Office 365. If you are moving to a model where users can access their mailboxes anywhere, then you will need to publish Autodiscover externally.
• Mail Flow – The Hybrid Agent removes the need to publish Exchange over HTTPS for mailbox moves and free/busy access. However, we’ll still need to allow mail flow between on-premises and Exchange Online. This requires TCP/25 connectivity both to and from Exchange Online Protection.
• Outbound access from Exchange servers to Exchange Online. Although the Hybrid Agent will allow access from Exchange Online to on-premises servers, your servers will still need to connect outbound for both the Hybrid Agent itself, and for requests such as free/busy.
• Client Access to Office 365. You’ll also need to ensure that all Office 365 clients like Outlook can access the service. Ideally this will be direct connection (instead of via a proxy server) accessing Office 365 by the fewest number of hops to the closest Microsoft Point of Presence. Use the Office 365 Network Onboarding Tool as a standing point.

In our example Exchange Organization, we’ve got a valid, third-party SSL certificate configured for Exchange Server for both our SMTP namespace (smtp.exchangelabs.co.uk) and HTTPS (autodiscover.exchangelabs.co.uk and outlook.exchangelabs.co.uk). We’ve allowed direct connectivity outbound on HTTPS to the required Office 365 and Exchange Online IP address ranges and SMTP connectivity to and from Exchange Online Protection.

Summary

In part one, we’ve selected the migration method to use for migration to Exchange Online, focusing on a Hybrid migration. We’ve then performed the core pre-requisite step for Exchange Hybrid – synchronizing Active Directory using Azure AD Connect. Finally, we’ve examined other areas, such as archiving, clients and connectivity.

In part two, we’ll implement Exchange Hybrid and perform mailbox moves.

Alternatively, you can download the full step-by-step guide here.