Configure Sign-In URLs for Outlook Web App

Applies to: Office 365 for professionals and small businesses, Office 365 for enterprises, Live@edu

Before your users can sign in to their Exchange Online mailbox using Outlook Web App, you have to tell them what URL to use. You have the following options:

Do you want to keep things simple? That’s easy!

  • For Microsoft Live@edu, use http://outlook.com.
  • For Microsoft Office 365, especially Microsoft Office 365 for professionals and small businesses, use http://mail.office365.com.
    Note   Because federated identity and hybrid deployments aren't so simple, you should follow the guidance later in this topic at Federated identity in Office 365 for enterprises. Also, you can’t use https in the URL with mail.office365.com. Even though the URL starts with http, the URL is immediately redirected to use https for the entire session, including authentication and accessing your mailbox in Outlook Web App.

Do you want to provide a customized URL for your organization? For example, if your domain is contoso.com, do you want to have your users sign in to their mailbox at http://webmail.contoso.com? If so, you need to do a little bit of work.

Let’s take a look at your options for customized URLs for Microsoft Office 365 and for Live@edu.

Microsoft Office 365

  • Non-federated identity in Office 365
    • Direct access URLs in Office 365
    • Customized URL using a CNAME record in Office 365
    • Customized URL using Web page redirection in Office 365
  • Federated identity in Office 365 for enterprises
    • Direct access URLs in Office 365 for federated users
    • Customized URL using a CNAME record in Office 365 for federated users
    • Customized URL using Web page redirection in Office 365 for federated users
    • Special consideration for hybrid deployments

Live@edu

  • Direct access URLs in Live@edu
  • Customized URL using a CNAME record in Live@edu
  • Customized URL using Web page redirection in Live@edu

Non-federated identity in Office 365

With non-federated identity, all users who have mailboxes in the cloud use Office 365–generated credentials to access their Microsoft Office 365 resources. You can create new user accounts and passwords for Office 365 users in the Office 365 portal. Alternatively, in Office 365 for enterprises, you can use directory synchronization to automatically provision users from the on-premises Active Directory. Either way, ultimately, credentials are generated and managed by Office 365.

Direct access URLs in Office 365

In this example, the Office 365 domain is contoso.com. The user accounts of the Office 365 users are in this domain.

Office 365 users can directly access their mailboxes at the following URLs:

Top of page

Customized URL using a CNAME record in Office 365

When you create a CNAME record at the DNS hosting service for your Office 365 domain, you can provide users a customized URL to open their mailbox using Outlook Web App. For example, if your Office 365 domain is contoso.com, you configure a CNAME record so webmail.contoso.com redirects users to mail.office365.com. You can tell Office 365 users to access their mailbox at http://webmail.contoso.com. The CNAME record looks like this:

  • Alias   webmail
  • Target   mail.office365.com

The advantage of using a CNAME record for a customized URL is it’s easy to configure.

These are the disadvantages of using a CNAME record for a customized URL:

  • It's not very flexible. A CNAME record can't directly point to a URL target such as http://outlook.com/\<domain_name>. The target must be a valid DNS host name, such as mail.office365.com.
  • You can't apply SSL to the customized URL. However, even if you don't apply SSL to the customized URL, the sign-in page where users provide their credentials has SSL applied, and their credentials are encrypted at that point. In fact, access to all Office 365 services is protected by SSL, regardless of whether SSL is used in the URL.

Top of page

Customized URL using Web page redirection in Office 365

If you have a Web server that's publically accessible from the Internet, you can configure a Web site to redirect users to Exchange Online. For example, you can configure the Web site http://webmail.contoso.com to redirect users to http://mail.office365.com or http://outlook.com/contoso.com.

How do you configure the Web page redirection? That depends on the Web server you're using.

These are the advantages of using Web page redirection for a customized URL:

  • It's very flexible. You can configure the Web page to redirect users to a URL, and not just a host name. You also control how the redirection works. For example:
    • Do you want the Web page to silently redirect users to Exchange Online?
    • Do you want to briefly show users a customized status page before they are redirected to Exchange Online?
    • Do you want to provide users an entire portal where they can access Outlook Web App by clicking a button or link?
  • You can apply SSL to the customized URL. Note that if you do this, you have to decide what to do when users access the customized URL using http://. Do you want to automatically redirect them to https://? Or do you want the redirection to stop with an error stating that https:// is required?

The disadvantage of using Web page redirection for a customized URL is it can be more work to configure than CNAME redirection.

Top of page

Federated identity in Office 365 for enterprises

When you use federated identity in Office 365 for enterprises, users who have Exchange Online mailboxes can use their on-premises Active Directory credentials to access their Exchange Online mailbox and all other Office 365 resources. For more information, see Exchange Hybrid Deployment and Migration with Office 365.

Direct access URLs in Office 365 for federated users

In this example, the federated Office 365 domain is contoso.com. The user accounts and e-mail addresses of the federated Office 365 users are in this domain. For example, a user named Tamara Johnston has the e-mail address and identity tamara.johnston@contoso.com.

Office 365 federated users can directly access their mailboxes at the following URLs:

Note   Federated users can't use http://outlook.com directly. The URL must contain the domain name, which helps determine where to send users for authentication.

Top of page

Customized URL using a CNAME record in Office 365 for federated users

When you create a CNAME record at the DNS hosting service for your federated Office 365 domain, you can provide users a customized URL to open their mailbox using Outlook Web App. For example, if your federated Office 365 domain is contoso.com, you configure a CNAME record so cloudmail.contoso.com redirects users to outlook.com. You can tell Office 365 federated users to access their mailbox at http://cloudmail.contoso.com. The CNAME record looks like this:

  • Alias   cloudmail
  • Target   outlook.com

The advantage of using a CNAME record for a customized URL is it’s easy to configure.

These are the disadvantages of using a CNAME record for a customized URL:

  • The top-level domain of the CNAME record must match the federated Office 365 domain. For example, to use the CNAME record cloudmail.contoso.com, your federated Office 365 domain name must be contoso.com. You can't use the CNAME record cloudmail.fabrikam.com if your federated Office 365 domain is contoso.com.
  • Be careful when you use subdomains in the CNAME record. For example, if your federated Office 365 domain is contoso.com, you can use the CNAME record cloudmail.contoso.com, but you can't use cloudmail.test.contoso.com. Likewise, if your federated Office 365 domain is contractors.contoso.com, you can use the CNAME record cloudmail.contractors.contoso.com, but you can't use cloudmail.test.contractors.contoso.com or cloudmail.contoso.com.
  • It's not very flexible. A CNAME record can't directly point to a URL target such as http://outlook.com/\<domain_name>. The target must be a valid DNS host name, such as outlook.com.
  • You can't apply SSL to the customized URL. However, even if you don't apply SSL to the customized URL, the sign-in page where users provide their credentials has SSL applied, and their credentials are encrypted at that point. In fact, access to all Office 365 services is protected by SSL regardless of whether SSL is used in the URL.

Customized URL using Web page redirection in Office 365 for federated users

If you have a Web server that's publically accessible from the Internet, you can configure a Web site to redirect federated Office 365 users to Exchange Online. For example, you can configure the Web site http://cloudmail.contoso.com to redirect users to http://outlook.com/contoso.com or http://outlook.com/owa/contoso.com.

How do you configure the Web page redirection? That depends on the Web server you're using.

These are the advantages of using Web page redirection for a customized URL:

  • It's very flexible. You can configure the Web page to redirect users to a URL, and not just a host name. You also control how the redirection works. For example:
    • Do you want the Web page to silently redirect users to Exchange Online?
    • Do you want to briefly show users a customized status page before they are redirected to Exchange Online?
    • Do you want to provide users an entire portal where they can access Outlook Web App by clicking a button or link?
  • You can apply SSL to the customized URL. Note that if you do this, you have to decide what to do when users access the customized URL using http://. Do you want to automatically redirect them to https://? Or do you want the redirection to stop with an error stating that https:// is required?

The disadvantage of using Web page redirection for a customized URL is it can be more work to configure than CNAME redirection.

Top of page

Special consideration for hybrid deployments

A hybrid deployment is a full-featured cross-premises messaging solution between Office 365 for enterprises and an on-premises Exchange organization. Some mailboxes will be in the on-premises Exchange organization, and some mailboxes will be in Office 365 for enterprises. On-premises mailbox users and Exchange Online mailbox users can't share the same Outlook Web App URL to access their mailboxes. However, you can use the on-premises Outlook Web App URL to educate Exchange Online mailbox users about the Outlook Web App URL that's appropriate for them. For more information, see the following topics:

The recommended Outlook Web App URL strategy for hybrid deployments is a CNAME record in combination with the TargetOwaURL parameter on the Set-OrganizationRelationship cmdlet as described in the hybrid deployment topics. The result is: when a user with an Exchange Online mailbox opens the Outlook Web App URL for on-premises mailbox users and attempts to access their mailbox, the login process stops and they’re presented with the Outlook Web App URL that they're supposed to use to access their Exchange Online mailbox. The Exchange Online users won't be automatically redirected to the URL for Exchange Online. They have to click on the link that's presented to them, and they also have the option to add the URL to their Favorites. Here's some additional guidance:

  • The Outlook Web App URL for on-premises mailbox users must be different than the Outlook Web App URL for Exchange Online mailbox users. For example, if the URL for your on-premises mailbox users is http://webmail.contoso.com, use http://cloudmail.contoso.com for your Exchange Online users.
  • Create the CNAME record as described in the Customized URL using a CNAME record in Office 365 for federated users section of this topic. For example, if your federated Office 365 domain is contoso.com, create a CNAME record for cloudmail.contoso.com that points to outlook.com.
  • For the TargetOwaURL parameter on the Set-OrganizationRelationship cmdlet, specify a URL that contains the CNAME record for your Exchange Online mailbox users. For example, if the CNAME record for Exchange Online users is cloudmail.contoso.com, use http://cloudmail.contoso.com for the TargetOwaURL parameter value.

Direct access URLs in Live@edu

In this example, the Live@edu domain is contoso.edu. The Windows Live IDs of the Live@edu users are in this domain.

Live@edu users can directly access their mailboxes at the following URLs:

Note   Currently, both URLs work equally well. However, future changes will most likely require that you use http://outlook.com/\<domain_name>. Why not get on board early?

Top of page

Customized URL using a CNAME record in Live@edu

When you create a CNAME record at the DNS hosting service for your Live@edu domain, you can provide users a customized URL to open their mailbox using Outlook Web App. For example, if your Live@edu domain is contoso.edu, you configure a CNAME record so webmail.contoso.edu redirects users to outlook.com. You can tell Live@edu users to access their mailbox at http://webmail.contoso.edu. The CNAME record looks like this:

  • Alias   webmail
  • Target   outlook.com

The advantage of using a CNAME record for a customized URL is it’s easy to configure.

These are the disadvantages of using a CNAME record for a customized URL:

  • It's not very flexible. A CNAME record can't directly point to a URL target, such as http://outlook.com/\<domain_name>. The target must be a valid DNS host name, such as outlook.com.
  • You can't apply SSL to the customized URL. However, even if you don't apply SSL to the customized URL, the sign-in page where users provide their credentials has SSL applied, and their credentials are encrypted at that point.

Top of page

Customized URL using Web page redirection in Live@edu

If you have a Web server that's publically accessible from the Internet, you can configure a Web site to redirect users to Exchange Online. For example, you can configure the Web site http://webmail.contoso.edu to redirect users to http://outlook.com or http://outlook.com/contoso.edu.

How do you configure the Web page redirection? That depends on the Web server you're using.

These are the advantages of using Web page redirection for a customized URL:

  • It's very flexible. You can configure the Web page to redirect users to a URL, and not just a host name. You also control how the redirection works. For example:
    • Do you want the Web page to silently redirect users to Exchange Online?
    • Do you want to briefly show users a customized status page before they are redirected to Exchange Online?
    • Do you want to provide users an entire portal where they can access Outlook Web App by clicking a button or link?
  • You can apply SSL to the customized URL. Note that if you do this, you have to decide what to do when users access the customized URL using http://. Do you want to automatically redirect them to https://? Or do you want the redirection to stop with an error stating that https:// is required?

The disadvantage of using Web page redirection for a customized URL is that it can be more work to configure than CNAME redirection.

Top of page