Tag Archives: SPF

SPF, DKIM and DMARC in Exchange Online Protection

In the previous two blog posts I’ve explained how to implement Exchange Online Protection as a message hygiene solution for your on-premises Exchange environment, both for inbound as well as outbound mail flow.

In this blog post I’ll go more into detail when configuring Exchange Online Protection

SPF, DKIM and DMARC

When Exchange Online Protection is fully up-and-running you can continue configuring SPF, DKIM and DMARC for message authentication purposes. This will make sure your email domain is much harder to spoof and receiving email systems know that the source of your email is a trusted source.

SPF

SPF has been around for years, and in my previous blog post I already mentioned the SPF record needed for use with Exchange Online Protection. If you want to read more about implementing SPF, please check my SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I blog post.

When only using Exchange Online Protection your SPF record will look like v=spf1 include:spf.protection.outlook.com -all.

DKIM

The good thing about Exchange Online Protection is that it supports DKIM signing and verification out of the box. The only thing you have to do is enable it in the Exchange Admin Center!

Logon to the Exchange (Online Protection) Admin Center, select protection in the navigation menu and click DKIM in the toolbar. When you click enable, an error message (in yellow) is shown that you need to create the appropriate DNS records first (click to enlarge).

EOP-DKIM

The error message reads (for search engine purposes):
CNAME record does not exist for this config. Please publish the following two CNAME records first.
selector1-domain-com._domainkey.tenantname.onmicrosoft.com
selector2-domain-com._domainkey.tenantname.onmicrosoft.com

The description isn’t that clear when you’re not a DKIM guru, but you need to create the following CNAME records:

Selector1._domainkey.domain.com CNAME selector1-domain-com._domainkey.tenant.onmicrosoft.com
Selector2._domainkey.domain.com CNAME selector2-domain-com._domainkey.tenant.onmicrosoft.com

When the DNS records are created you can use the MXToolbox to check if they are valid:MXToolbox-DKIM

If an email is sent from the on-premises Exchange server via Exchange Online Protection to for example Gmail, you can check the headers. If configured correctly you can see the SPF check passes, you can see the DKIM signature created by EOP and you can see the authentication results as well. It should read spf=pass and dkim=pass under Authentication Results as shown in the following screenshot (click to enlarge):

EOP-DKIM-Signed

For more information regarding DKIM and Exchange, please check my SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II blogpost.

DMARC

When DKIM and SPF are configured correctly you can create a DMARC record in public DNS. A DMARC policy will tell a receiving mail server what to do with email that does not comply with other settings. For example, if email is coming from a mail server that’s not listed in the SPF record it might well be spoofed. If the DKIM signature is missing it might be spoofed, if the DKIM signature is not valid, the message might be tempered with. If this is the case, you can define a policy that will reject such a message. The DNS record will be like this:

v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:dmarcreports@exchange2019.nl

The RUA is an email address where DMARC reports are sent to, so it’s a good thing to have such a mailbox on your Exchange server.

When sending an email from the Exchange server via EOP to Gmail when SPF, DKIM and DMARC are configured, you can see information like the following screenshot in the email headers (click to enlarge):

EOP-DKIM-Signed-DMARC

Everything is configured correctly now and spoofing is much harder to achieve for malicious users.

For more information regarding DMARC and Exchange, please check my SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III blog post.

Summary

In this blogpost I showed you how to configure SPF, DKIM and DMARC in Exchange Online Protection to prevent spoofing by malicious users.
In my next blog I’ll go more into detail about configuring the message hygiene options themselves in Exchange Online Protection.

Implementing Exchange Online Protection for on-premises Exchange Part II

In my previous blogpost I’ve explained how to implement Exchange Online Protection (EOP) for inbound messaging. In this blogpost I’ll explain what it takes to use EOP for outbound messaging.

As explained, the desired configuration should like this this:

Exchange 2019 EOP

Directory synchronization is in place (not explained in previous blog post), Send Connector from EOP to Exchange on-premises is created, MX record has changed to EOP and messages are delivered through EOP to the mailboxes on-premises.

Outbound mail flow

For outbound mail flow, two connectors need to be created:

  • One Send Connector on the on-premises Exchange server that will send all outbound messages to EOP. This send connector will most likely replace the existing Internet Send Connector that typically uses DNS to send external email to recipients.
  • One Receive Connector on EOP that accepts messages only from the Send Connector that was created on-premises.

For security purposes, TLS is enforced by default so a valid 3rd party certificate is required.

To create the Receive Connector in EOP, open the Exchange (Online Protection) Admin Center, select mail flow and click Connectors. Click the + icon just like when creating the connector in the previous blog post, but right now select Your organization’s email server in the From: dropdown box and Office 365 in the To: dropdown box as shown in the following screenshot (click to enlarge):

EOP-Route2

Click Next and follow the wizard. There are two ways for Exchange Online Protection to identify your outbound on-premises Exchange server. This can be either by its certificate or by its IP address. In the example below, I’ve selected the certificate and its FQDN for identification, but you can also enter and IP address (click to enlarge):

Receive-Connector-EOP

Click Next to continue and follow the wizard. Check the configuration and click Save to have the Receive Connector created in Exchange Online Protection.

The on-premises outbound connector was already in place (through the Edge subscription) and this connector need to be changed from DNS delivery to smarthost delivery. Logon to the on-premises Exchange Admin Center, select mail flow and click connectors. Open the outbound connector, click delivery and select the route mail through smart host radio button. In the smart hosts box, use the + icon to add your domain specific EOP FQDN, which is something like yourdomain-com.mail.protection.outlook.com as shown in the following screenshot (click to enlarge):

EdgeSync-SendConnector

When Edge synchronization has synchronized all information to the Edge Transport server it is possible to test the new configuration. When sending an email from Exchange on-premises to my Gmail account and check the header information after receiving, it is clearly visible that mail flows via the Edge Transport server through Exchange Online Protection to Gmail (click to enlarge):

EOP-headers-2

Note. Do not forget to update your SPF record! If your SPF record is not updated, organizations that do check for SPF (like Gmail) will detect an incorrect IP address or FQDN and possibly reject the message. You can find the correct SPF record in your Office 365 Admin Center (under Setup | Domains) and will look like “v=spf1 include:spf.protection.outlook.com -all

Summary

In the previous two blogposts I showed you how to implement Exchange Online Protection as a message hygiene solution in front of your on-premises Exchange solution. It can be configured for use with an Edge Transport server, but it can also be configured directly from the Mailbox server, or when using a 3rd party SMTP solution in your organization’s perimeter network.

In the next blog I’ll explain more about configuring and customizing Exchange Online Protection.

 

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part III

In the previous two blogpost I discussed how to configure SPF, DKIM and DMARC for outbound messages using the TrendMicro Hosted Email Security solution, including Office 365 centralized mail transport. In this blog I’ll discuss SPF, DKIM and DMARC for inbound messages (i.e. the verification part) using the TrendMicro solution.

Inbound protection

For inbound protection there’s not too much configuration to do, the only thing when using an online service is enabling the services.

In HEC Console select Inbound Protection and select Domain-based Authentication. Here you’ll find the options for SPF, DKIM and DMARC:

image

Select the Sender Policy Framework (SPF) option and in the SPF window check the enable SPF checkbox and when needed, check the Insert an X-header into email messages checkbox:

image

Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part III

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part II

In my previous blog I showed you how I implemented Trend Micro Hosted Email Security (HES) in my Exchange 2010 environment. Interesting case, it’s an Exchange 2010 hybrid environment with mailboxes in on-premises Exchange 2010 as well as mailboxes in Exchange Online. Centralized mail transport is used, so mail to and from Office 365 always routes via HES and the on-premises Exchange 2010 servers to Exchange Online. In this blog I will focus on implementing SPF, DKIM and DMARC in Trend Micro Hosted Email Security.

SPF

SPF in itself is covered in more detail in a previous blog post “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I” which can be found here: https://jaapwesselius.com/2016/08/19/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-i/.

In this scenario, mail from the inframan.nl domain (including Office 365) is only routed via the Hosted Email Security environment so the SPF record is pretty simple:

v=spf1 include:spf.hes.trendmicro.com ~all

Set this TXT record in your public domain, start sending email and when checking the header information you’ll see your all good here:

image

DKIM

DKIM is a little more work to configure and takes a bit more time. DKIM is covered more in detail in part II of a previous series “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II” which can be found here: https://jaapwesselius.com/2016/08/22/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-ii/

DKIM is about signing header information using a private key, and to decipher the signature you need a public key which is stored in public DNS, accessible for every mail server on the Internet. No need to worry about the configuration, HES will deliver all the details.

In the HES console select Outbound Protection and select DomainKeys Identified Mail (DKIM) Signing.

image

Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part II

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part I

A couple of years ago I have been working with the TrendMicro Hosted Email Security (HES) solution and I was very satisfied with it. With the upcoming SPF, DKIM and DMARC awareness I was looking for online solutions that offer this kind of security measures and I found that HES now offers these solutions as well.

I have a hybrid Exchange environment with multi-role Exchange 2010 servers, Exchange 2010 Edge Transport servers and a hybrid configuration. There’s no dedicated Exchange 2016 server for this, the hybrid configuration just uses the existing Exchange 2010 servers. And this works well. There’s an additional namespace o365mail.inframan.nl, this is used solely for SMTP communication between Exchange Online and the on-premises Exchange 2010 servers (without the use of the Edge Transport servers). The configuration looks like this:

image

This a hybrid configuration with a centralized mailflow. All email is sent and received through the on-premises Exchange environment, including email from and to Office 365. So, email sent to the internet by users in Office 365 are sent first to the Exchange 2010 servers, and then via the Edge Transport servers to the Internet. This way you have full control over your Internet mail flow.

The Edge Transport servers don’t do a great job when it comes to message hygiene. You can configure Realtime Block Lists (RBL) like Spamhaus, configure content filtering using word lists and attachment filtering, but still (a lot of) spam ends-up in the user’s mailboxes. Therefore 3rd party solutions like Cisco Email Security Appliance (ESA, formerly known as IronPort) are used in front of on-premises Exchange solutions

Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part I