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.comAuthentication-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.
3. Why add conditions like SPF=pass or DKIM=pass?
Many customers today create Allow rules for various domains but spammers will frequently spoof those domains and then the message gets to their users’ inboxes. By requiring that a message passes SPF or DKIM, this will no longer occur. Only an authenticated message will skip filtering, meaning a spoofed message will not go unfiltered.
For IPv6, which requires SPF or DKIM, the above mechanisms will work. For IPv4, where a lot of domains still do not authenticate, this will result in some domains not skipping filtering. The means that some domains may get marked as spam even though you created a rule to skip filtering. For high value domains that are prone to spoofing this is okay – it’s better to avoid the malicious emails in your inbox. For low-value that are not prone to spoofing domains, it may be alright to simply create an Allow rule.
Related Articles:
Support for Anonymous Email over IPv6 in Office 365