You are the admin of your O365 tenant, your company is growing, and your internal communications department comes to you and says something like the following:
“We are trying to send e-mails to our employees regarding this event we are planning via this external event company. These e-mails never arrive. Can you please whitelist “event@ourcompany.com” in our mailservers?”
Welcome to the world of anti-spam, spoofing, and phishing. Your next move can be critical for the security of your company data. As with many things … doing it the correct way takes more knowledge, time, and effort.
Compare this situation with the following:
Your company is now a bank. The employee’s safety is the most valuable treasure you have, so it’s locked in the vault.
Somebody outside the company complains he does not have a key to enter the vault. Do you:
A) Provide a working key to the vault, so the person is granted access as requested with minimal delay.
B) Look into why the person does not have a working key and consider this may be intentional to keep the vault safe. In this case, the person does not even work for the bank.
If you choose A, I hope you will never be in charge of an actual bank that holds my stuff. As a sysadmin, the only right answer is, of course, B.
So, what IS your next move in a situation like this?
Your next move is: find the rootcause. Whitelisting is your last resort. Fixing the actual problem is your top priority.
In 9 out of 10 times, the external company that is being used offers to use their own mail infrastructure to send out these invitations. The mailserver used is not listed as authorized to send mails using the company’s domain, i.e., event@ourcompany.com.
The reason for this is simple once you understand the concept of spoofing. Let’s say the event company is not an event company but is now sending emails with a FROM address of your CEO. The e-mail instructs finance people to make money transfers that harm the company. There is nothing that prevents this malicious not-event company from doing so. Therefore it is a good thing the receiving mailservers have ways to validate all incoming e-mails.
Sender Policy Framework
The most important thing is to give receiving mailservers a chance to validate the incoming e-mails that use your domain as a sender address. This can be done by activating SPF (Sender Policy Framework). Without going into details, it suffices to say that you can list the mailservers you own with a simple DNS record and designate them publicly as valid servers for your domain. Any mailserver in the world can query this list and make decisions based on that information.
Therefore, the solution to the problem in this article is to add the remote mail server’s IP address to the SPF record in your DNS for the domain ourcompany.com. You will find that the anti-spoofing mechanism will allow the emails in when they originate from that server’s IP address.
Had you chosen to whitelist that e-mail address as a whole, you would have opened up the floodgates for everyone, everywhere using that e-mail address. As time progresses, more and more will be added, and in a few years’ time, you will have many whitelisted that are bypassing your security measures. You do not want to be in that situation.