Tips and Tricks for Adding a Domain to Office 365

There are three steps to adding a domain to your Office 365 tenant:

  1. Prove that you own the domain (aka domain validation or domain proof).
  2. Add users and assign licenses (optional).
  3. Set domain purpose and configure DNS.

Once these three steps are complete the domain is active for use in Office 365.

Domain validation (Step 1 in the Add a Domain wizard ) is done to prove that you own the domain you are adding to Office 365. It involves adding a TXT record to your external DNS with a specific text string (something like MS=ms15068668) that Office 365 provides in the wizard. If Office 365 can read that TXT record in the zone’s public DNS it “proves” that you own the domain.
Note that the domain proof TXT record is only needed once for domain validation.  Once domain validation is complete, you can safely delete it from public DNS. If for some reason you remove the domain from Office 365 and add it again, you will need to revalidate the domain and the domain proof TXT record will have a different value.

The second step is to add users and assign Office 365 licenses. Most of my customers use DirSync to synchronize Active Directory objects with Office 365, so this step is unnecessary. In this case I usually select, I don’t want to add users right now.

The third step is to set the domain purpose and configure external DNS so you can use this domain in Office 365. This is the step that trips most people up because Office 365 is so unforgiving about the DNS records it expects. Office 365 expects you to only use the records they specify, exactly as provided in the wizard.

But if you update or add these SPF and MX records required for Exchange Online, it will affect your mailflow sooner than you probably intended.

The trick here is to uncheck all the Office 365 services and then click Next to activate the domain without specifying a purpose. This has no effect on the way Office 365 works for the domain – the services still work and user licenses are unaffected. It simply bypasses the DNS configuration and checks.

Once the domain has been activated you will be able to assign that domain as a sign-on domain for cloud users.

After a short while you will see the newly activated domain in the Exchange Admin Center (Mail Flow > Accepted Domains) and you will be able to add email addresses using that domain to cloud users.

How to Configure an Internal SMTP Relay Server for Office 365

Most organizations have internal application servers and appliances that send emails to users or groups. Examples include copier/scanners and application servers, such as backup servers that notify admins of a completed or failed backup job.

If the organization has Exchange on-prem you would normally configure an internal relay send connector in Exchange and configure the internal resources to send emails to Exchange. But what do you do when you’ve migrated all your mailboxes to Office 365 and have decommissioned your Exchange servers?

The solution is to install an IIS SMTP relay server in your internal network, configure it to accept email from specific IP addresses, and forward emails to Office 365. You can also configure the SMTP relay for external domains, if necessary.

Here’s how to do it:
  • Install the SMTP Server feature and its dependencies to a new or existing Windows server. This will be your relay server and your firewall needs to allow it to send SMTP traffic (TCP port 25) outbound to the Internet. I typically use the DirSync server, if there is one.
Adding the SMTP Server feature and its dependencies to Windows Server 2012
  • Open Internet Information Services (IIS) 6.0 Manager to configure the SMTP relay.
  • Configure the properties of [SMTP Virtual Server #1] as follows:
    • On the Access tab:
      • Authentication: Only Anonymous access is checked.
      • Relay: Only the list below. Add IP addresses or ranges of servers allowed to relay.
      • Note – It’s important to only allow IP addresses you trust to relay through this server. Any IP address you enter here will be allowed to send emails on behalf of your domain.
    • On the Messages tab:
      • Adjust message size limits. The default message size limit is 2048 KB (2 MB).  You may want to change it to 10240 KB (10 MB) or more to allow for larger messages from copier/scanners, etc.
    • On the Delivery Tab:
      • Outbound Security: Anonymous access only and no TLS encryption.
      • Outbound Connections: Port 25
      • Advanced: Leave the Smart Host field blank
  • Add new remote domains:
    • Right-click Domains > New > Domain and add the domain(s) hosted in Exchange Online.
    • If the relay server is allowed to relay emails to other external domains add a new *.com remote domain. Repeat for *.org, *.net, etc. as necessary.
    Add Office 365 and other remote domains if required for external relay
    • For properties of each domain hosted in Exchange Online:
      • Check Allow incoming mail to be relayed to this domain
      • Forward all mail to this smart host:
      • Outbound Security: Check Anonymous access and TLS encryption
    • For properties of all other remote domains (if any):
      • Check Allow incoming mail to be relayed to this domain
      • Outbound Security: Check Anonymous access and do not check TLS encryption.
  • Restart IIS.  Be aware that whenever you restart IIS, the SMTP virtual server usually stays stopped – start it.

  • The SMTP Server feature can be added to any Windows 2003 or better server. I usually use the DirSync server if there is one.
  • Unlike Exchange, TLS for IIS 6 SMTP servers is not opportunistic. If the virtual server or a remote domain is configured to use TLS email will not be sent if the remote domain does not support TLS. Office 365 offers TLS, so we can use it.
  • The configuration above allows the IIS 6 SMTP server to send emails to the Internet for the remote domains configured, so you should add the public NAT IP address for this server to your existing SPF record to prevent non-delivery. Use from the SMTP server to determine the NAT IP address.
  • Monitor the %systemdrive%\Inetpub\mailroot\Queue folder to ensure that emails are being delivered.
    • If emails are not being delivered to Office 365 users, test sending email via Telnet. The IP address may be blocked by an Exchange Online Protection (EOP) blocklist and you will see that response from EOP. If so, send a delist request from your Office 365 admin account to letting them know the IP address that should be delisted. In my experience it takes up to 36 hours for Microsoft to delist it.
    • If emails are not being delivered to external domains, ensure that you have a remote domain type (*.com, *.eu, etc.) configured for those email addresses.
  • You can enable logging in the properties of the SMTP virtual server for further troubleshooting. Use the NCSA Common Log File Format. IIS does not automatically groom or delete logs like Exchange does, so turn logging off when you’re done troubleshooting.
  • The best practice is to create an A record in internal DNS for using the SMTP relay server’s IP, and configure all application servers and appliances to use that FQDN for email forwarding. That makes it easier to update in the future.

How to Determine Which Receive Connectors are External Relay Connectors

There are times, particularly during an Exchange migration, when you want to determine which Exchange receive connectors are configured as external relays. External relay receive connectors allow connections (usually from anonymous users) to be relayed to another external domain. When these connectors accept connections from anonymous users they are sometimes called “open relay”connectors. A common use case for this is to allow internal application servers to send emails to external users.

In the course of an Exchange migration, you will usually create new receive connectors on the new Exchange servers that have the same settings as the old Exchange servers. Most of these settings are easy to see and copy, but the ability of a receive connector to perform as an external relay is configured using the ms-Exch-SMTP-Accept-Any-Recipient extended AD permissions which is not so visible.

The following EMS one-liner is useful to determine which receive connectors in the organization are open relay connectors so you can configure the new ones likewise:

Get-ReceiveConnector | Get-ADPermission | Where {$_.User -Like ‘*anon*’ -And $_.ExtendedRights -Like ‘ms-Exch-SMTP-Accept-Any-Recipient’} | ft Identity, User, ExtendedRights

If your existing external relay receive connectors use a specific account rather than anonymous (NT AUTHORITY\ANONYMOUS LOGON) users, change ‘*anon*’ to the specific account name.

See the following articles for more information about Exchange receive connectors: