How to create Allow rules in Office 365 for senders over IPv6 (and also for IPv4)

Office 365 now permits anonymous inbound email over IPv6. Most of the functionality works the same in IPv4 as IPv6. However, there are some differences for inbound messages where customers want to allow messages from a particular domain or sender.

Whereas in IPv4, customers could create IP Allow rules, this functionality does not exist in IPv6. The reason is that it is cumbersome to manage IPv6 ranges and you won’t get them all correct anyhow.

Fortunately, it is easier (sort of) to manage IP Allows and Blocks in IPv6. IPv6 requires the senders to authenticate with either SPF or DKIM. Office 365 stamps the results of the SPF check into the Authentication-Results header, for example:

From: user@example.com

Authentication-Results: spf=pass (sender IP is 2207:eab0:3001:a01::123)
 smtp.mailfrom=user@example.com; contoso.com; dkim=pass (signature was
 verified) header.d=example.com;

This header can be used to create Allow rules. You no longer need to keep track of IP addresses, you can just allow the domain.

1. The simple, but less secure, way to create Allow rules for IPv6 (and also works for IPv4)

To quickly allow a message over IPv6, create an Exchange Transport Rule (ETR) that does the following:

a) Looks for spf=pass or dkim=pass in the Authentication-Results header

b) Looks for the sender domain you want to allow

To do this using the Exchange Admin Center:

Creating the Allow rule this way requires the domain to authenticate. In IPv6, a domain must pass SPF or DKIM to be allowed into the system, and the advantage of this quick way of creating ETRs is that it also works for IPv4; only real email from the domain bypasses filtering. If the domain is not authenticated in IPv4, this rule will not work and so a spoofed message will undergo filtering most of the time.

2. The more complicated, but more secure, way to create Allow rules for IPv6 (and also works for IPv4)

The above ETR works most of the time, but spammers and phishers can craft messages in such a way to pass SPF or DKIM but still spoof the From: address that is displayed in the email client. For example, the spammer can set up their own SPF and DKIM records, but change the From: address to show a different sender than the one that was authenticated.

From: user@example.com

Authentication-Results: spf=pass (sender IP is 2207:eab0:3001:a01::123) smtp.mailfrom=spammer@spammer.com; contoso.com; dkim=pass (signature was verified) header.d=spammer.com;

This is not the most commonly used spam technique but it occurs often enough to cause problems for some users. To prevent this, create an Exchange Transport Rule (ETR) that does both of the following:

a) Looks for spf=pass or dkim=pass in the Authentication-Results header

b) Looks for the authenticated domain in the Authentication-Results header by searching for text patterns (not “text includes”)

This uses a combination of regular expressions instead of simple text matches. The two regular expressions in the Authentication-Results header to look for in the ETR are:

spf=pass \(sender IP is [a-z\d\:\.]+\) smtp.mailfrom=[a-z\d_]+\@<example.com>

dkim=pass \(signature was verified\) header.d=<example.com>

Replace the highlighted text with the domain you want to allow (but do not include the angle brackets). After you are done, the rule should look something like this:

This is more complicated than the simple way but it prevents spammers from spoofing a domain and then getting a free pass to the inbox.