close

Exchange Server

Microsoft Exchange Server

Exchange Server

How to licence Exchange Hybrid servers

images

As part of your Exchange Hybrid deployment you might introduce new Exchange Servers into your organization. If you’ve planned your deployment correctly, then these will be covered by Hybrid Exchange licences included within your Office 365 Enterprise subscription.

When you don’t need a Hybrid licence

First and foremost, you must consult Microsoft or your licensing specialist for correct guidance for whether you are licensed correctly. However, there is as a key scenario where you will not need to acquire Exchange Hybrid licences.

If you are running Exchange Server 2010, 2013, 2016 or 2019 then you already have Exchange Hybrid capabilities built in to your Exchange Servers today.

Your Client Access services will be used for Autodiscover services and Exchange Web Services based communications. This includes redirecting clients to the cloud, Federated Sharing for Free/Busy and Mailbox Moves. Your Hub Transport services also have the capability built-in to manage Hybrid mail flow between Office 365 and your Exchange Server.

Adding additional servers to your organization to support Exchange Hybrid is a common piece of bad advice shared regularly. If you have a healthy Exchange 2010+ organization today, then you almost certainly have everything you need and will not need to licence Hybrid Servers.

When you do need a Hybrid licence

If you are running Exchange Server 2003 or 2007 you will need to add Exchange 2010 or 2013 servers if you want to perform a Hybrid migration. As those servers don’t have any Hybrid components built-in, then for many organizations it means a part-migration to a newer version of Exchange Server. Typically, this means implementing co-existence with the newer version, and migrating some client-facing services across, such as Autodiscover, Exchange Web Services, ActiveSync and Outlook Anywhere.

It’s important to note that when you add Exchange Hybrid servers to your Exchange 2003/2007 organization you cannot move any mailboxes to the servers if you wish to qualify for a “free” Exchange Hybrid licence. That means you can’t (for example) stage mailboxes from Exchange 2003 to Exchange 2010 first, before moving them to Office 365.

Another key scenario where you are likely to need a Hybrid licence is after you have completed your migration from Exchange Server 2010 to Office 365. After moving your final mailboxes and if you have them, Public Folders, you will decommission Exchange Server 2010. Most organizations will keep Azure AD Connect in place after the migration completes, which means Hybrid Identity (where AD remains the master) is in place. You will therefore require require Exchange Server to manage those attributes – and potentially to relay SMTP email, too. This of course is a great use of an Exchange 2016 or higher server.

Finally – and it comes as a surprise to some organizations – if you have never had Exchange within the organization then you might need to install Exchange Hybrid servers for attribute management within the local AD. As mentioned above – if you use Azure AD Connect, you will have Hybrid identity in place. Many organizations running Domino today and migrating to Office 365 find they need to install an Exchange Hybrid server (or two) and utilize the free Hybrid licence.

Acquiring Exchange Hybrid licences

The process to acquire an Exchange Hybrid licence has recently changed. Previously, you would request Exchange Hybrid licences from the Office 365 portal. This of course, made it easy to request the licences you needed in advance in the same way you licenced Exchange Servers traditionally within your organization.

If you are licensing new Exchange Servers for Hybrid today, the process has changed. You will now licence new Exchange Hybrid servers within the Office 365 Hybrid Wizard.

When you run the Wizard, you will be able to choose the option Licence this server now to apply the Exchange Hybrid licence:

After choosing to licence the server, you’ll be provided with the option to copy product key if you need to apply the Hybrid licence key manually (for example, using the Exchange Admin Center, or PowerShell).

read more
Exchange 2016Exchange Server

How to use Mail Contact object to enable outgoing SMTP relay

download (1)

Consider the following scenario – you have a need to deliver email to and from an application server that receives email via SMTP. You want to use Exchange Online Protection, the SMTP domain of the application server can send email via SMTP, however it isn’t routable or contactable via the internet, and therefore can’t receive replies to messages sent. Your organization’s email is setup in a Hybrid configuration with on-premises Exchange Server, which is configured to allow your application servers to relay email outbound via Office 365.

One way to allow your application server to receive email from the internetvia Exchange Online is by using a Mail Contact object. This will accept email to Exchange Online, and then relay the mail back to on-premises for delivery to your application server. In this post, we’ll show you how to achieve this, and how to resolve common issues you might encounter.

Example configuration of SMTP relay

In our example scenario, we’ve got an application server sending messages as Application.Mailbox. It has two different email addresses – the internal address used within the application server, and the address defined within Office 365.

In this example, our Office 365 email address is: Application.Mailbox@wordfish.co.uk

The internal application server email address is: Application.Mailbox@resdomain.local

Contact Object
Contact Object

So that the Office 365 email address can be used to relay mail back to the on-premises application server, the non-routable email domain needs a specific connector configured to route messages to the application server’s specific on-premises domain.

It’s important to note that you could instead add the domain to the hybrid connector, but we don’t recommend this. This is because if you re-run the Hybrid Configuration Wizard, which you may need to do periodically, the domain will be removed from the connector created and managed by the hybrid wizard.

The other key component of allowing email to route from Office 365 back to on-premises is ensuring that the on-premises environment is able to send the email to the application server, as shown below:

Routing Email Externally

In a configuration like this, we’ll also expect that because the application server needs to send SMTP messages, the on-premises Exchange environment can be used for relay via the Hybrid configuration, as shown below:

Routing Email Externally

After implementing this configuration, email can be sent and received from the application server. And all may appear well, initially…

Some emails are reported as spam or not delivered

After time, one common issue that may be reported is that there are mail delivery issues with some mail servers on the internet.

Generally, you will check that records, like your SPF records are set up correctly. You check and find that SPF is setup correctly and you are not on any bad reputation lists. Email delivery in general is fine.

However, sending a test email via the Application server and analysing the headers shows some interesting results.

Send Test Email

After sending a test message to replicate the issue, open the message headers in a client like Outlook. You can then copy and paste the headers into the Microsoft Message Header Analyser.

This is a useful tool, as it helps you easily examine the properties contained in the message headers and quickly identify the offending issue. In the example below, we’ve highlighted what appears to be the underlying issue:

Return Path

You’ll see above that we can see in the Return-Path, the envelope ‘from’ address, is set to the internal resdomain.local domain.

While this is valid on the internet, many receiving mail servers will consider an invalid Return-Path domain enough of a reason to mark the message as spam, or completely reject the message.

As this example is a lab environment, it is possible to easily reconfigure the network and Office 365 so that messages can be relayed directly from the application server. We’ll change the configuration for testing purposes to the configuration shown below:

Direct Test

Upon making the configuration changes, we’ll re-perform the SMTP relay test, as shown below:

Direct Test

After the message is received, we’ll follow the same investigation process as before and examine the message headers once the email has been successfully received. Routing directly, rather than via Exchange Hybrid shows that this time the Return-Path is as expected:

Proper Return Path

So, what’s going on?

Conclusion

Look at the unusual capitalisation of the Return-path in the first example and note that it’s exactly the same as the emboldened address in the Mail Contact object (the reply address):

SMTP Bad Default Reply to Address

Exchange on-premises is receiving the email then using the Mail Contact object as the envelope-from address when relaying it through to Office 365. It is not changing the reply address seen by the user, so at first glance everything behaves as expected.

Although Office 365 has the same Mail Contact object, the behaviour is not the same. Exchange Online is not changing the envelope address.

You could consider relaying all your application servers through Office 365 and Exchange Online directly. However this configuration isn’t suitable for many organizations, because it requires extensive firewall changes including allowing application servers to directly communicate over the internet.

Instead, we’ll choose to correct this by updating our application servers’ contact object within the Exchange on-premises environment. You’ll find the most straight-forward fix here is to set the correct address as the reply-to address in the Mail Contact, as shown in the example below:

SMTP fixed reply to address
read more
Exchange Server

How to keep your emails out of the recipient’s spam folder

11-Reasons-Why-Your-Emails-Go-in-the-Spam-Box

Email is still as important as ever, despite the click-bait headlines and numerous communications start-ups claiming that email is dead and <insert fad here> will be the future of office communication. Email is so popular that even Spam Email is still a thing, accounting for 14.5 billion messages a day in 2017 – 45% of all email messages. Luckily companies like Microsoft have become experts at filtering the wheat from the chaff when it comes email and we hardly ever notice the barrage of spam thrown against our email servers. Unfortunately, sometimes a legitimate email may end up in a spam folder – which is bad news if you’re relying on that email to convey something important to a customer or supplier.

Email servers, such as those managed by Microsoft for Office 365, rely on a range of open standards and technologies to separate the good emails from the spam. As an email administrator, it is incredibly important that all the systems that your company uses to send emails are correctly configured to use these standards to ensure that your outgoing emails don’t end up in the recipient’s quarantine or spam folder.

Most email administrators understand that a big proportion of their outgoing emails come from a user’s Outlook or email client and are routed out via Office 365 or their local Exchange email server. However, it is always surprising to learn that these same email administrators have no idea what other systems send email out on behalf of their company’s domain name.

This post will walk you through configuring the two most effective technologies to ensure that your outgoing email is successfully delivered. These technologies are known as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

Both technologies require you to add some special records into the DNS zones for the domain names that you are sending email from. The recipient’s email server analyses the headers of each email message and looks up these DNS records to try and match details of the sending email server against what you have configured. If the sending email server passes these tests, it is incredibly unlikely that the message will be marked as spam or suspicious.

Audit your outgoing emails
Before you can get started on configuring these items, you need to make a full list of all the domain names and email servers that your outgoing messages come from. Obviously, there will be your normal email service, such as Office 365 or Exchange, but it’s important to capture the other 3rd parties that may be sending emails from your domain such as:

  • CRM systems
  • Marketing Automation Systems
  • Helpdesk ticketing systems
  • Notification and alert services

You will need to configure SPF and DKIM for all these services. Luckily, in 2018 most major providers have great support and documentation for configuring SPF and DKIM.

Implementing SPF for Office 365


Now that you have a documented list of all the places your email gets sent from, you can start by setting up SPF for your Office 365 environment. To get started, log into your DNS provider and create a TXT record for the root of the domain that you are sending email from. You will need to consult your DNS providers documentation for instructions on how to create a TXT record.
In the value area, you will need to add the actual SPF record. For most Office 365 customers, the record will look like this:

It can be broken down into three components:

You will need to add an include: part for every other email service that sends email from this domain name. The example below allows email to originate from Office 365, Amazon Web Services and a mail server with the IP Address of 203.12.45.55.

More information about all the options available within the SPF record can be found on the OpenSPF website.  You can validate that the record has been correctly applied using nslookup in a Windows command prompt window or PowerShell.  Simply open nslookup, set the lookup type to TXT using the set type=txt command, and then lookup the domain name as per the example below.

Spam Folder

You can check that the syntax of your DNS record is correct by pasting it into any one of the SPF syntax checking services that you can find online.  You will need to be aware that the SPF record has limitations in the number of servers or DNS lookups that can be added and there are a few other gotchas that you should look to avoid.

Once you have had your SPF record in place for a few weeks without problems, you can look to switch the ~all SoftFail at the end of the record to a more robust HardFail of -all.

Implementing DKIM for Office 365

Whilst SPF is a great technology for identifying IP addresses of email servers that are allowed to send email on behalf of a domain, it does have several limitations. I recommend that you also implement another technology called DKIM which takes email authentication one step further by signing an email message with a digital signature.

When DKIM is configured, each outbound email has a digital signature stamped into the message headers.  When an email message is received by the receiving email server, it looks up the DKIM public key from the domains DNS record and uses it to verify the DKIM signature it found.  If the signature is verified, the server knows that it was sent from a mail server that is authorised to use that domain and allows it through.

To enable DKIM in Office 365, you will need to create two CNAME DNS records in the hosted zone for your domain.  You will need to follow the instructions from your DNS provider to achieve this. 

The two records you need to create will look something like this:

The two parts you will need to fill in are:

<domainGUID>The domain GUID is the same as the one that is in your MX record, usually the first part of it.  For example:  babelmate-com.mail.protection.outlook.com
<initialDomain>The Initial Domain is the domain you used to sign up to Office 365, and ends in .onmicrosoft.com.  For example:   babelmate.onmicrosoft.com

Again, you can verify that you have set the records correctly using nslookup:

Now that the records are published, you need to enable DKIM for the domain via PowerShell.  First connect to Exchange via Online PowerShelland run the following command:

Domain is the name of the custom domain that you want to enable DKIM signing for. For example, for the domain babelmate.com:

You can validate that this is configured correctly by logging into the Exchange console and clicking on the Protection section.

Now that you have configured DKIM for Office 365, I highly recommend you also do this for all your other 3rd party mail services that you identified in your audit.  Each of these will have their own, but similar, way of configuring DKIM. For example here is how you can do it for SalesForce and HubSpot.

Alternatively, you can send an email from Outlook to an external email address and look at the mail headers.  Here you can see the SPF and DKIM headers in an email message I sent to my Gmail address:

If all your checks have passed you’re done!  Now your messages are incredibly unlikely to be marked as spam, and it will ensure that anyone spoofing your domain from unauthorised servers will have those messages flagged and blocked.

read more