You are here: Home / Blog / What is Spoofing and How to Defend Against It?

What is Spoofing and How to Defend Against It?

by Lalita Negi on November 30th 2018

The information contained here revolves around the way office 365 reduces the attacks from phishers who utilises fake sender domains that actually are spoofed. So, this article will highlight all things related to anti-spoofing protection to benefit office 365 users. This aim is achieved by evaluating messages of emails and blocking messages that can’t be verified with standard methods of email authentication and other reputation techniques for sender.

In addition, we will also describe the reason for the new change to be introduced and how consumers should prepare themselves for it, how to see affected messages, how to register complaint on those messages, how to reduce false positives, and how to wholly prepare for the new change.

Knowing Anti-Spoofing Technology of Microsoft

The anti-spoofing technology of Microsoft is implemented to the advanced threat protection of office 365 as well as E5 consumers initially. But, due to the way, all filters of it learn from one another, the consumers who are non-ATP or outlook.com consumers may get affected from it.

Learning How Spoofing Contributes to Phishing Attacks

When we talk about the user’s protection, Microsoft strictly takes the risk of phishing attacks. Here, one famous technique that most of the phishers and spammers use is called spoofing. In spoofing, a message seems to come from some place or some person other than its real source and at this condition, the sender gets forged. Spoofing usually works in various phishing campaigns prepared to get user data. The anti-spoofing technology of Microsoft basically evaluates this kind of forgery made from ‘from: header’. This header is the one which appears in the email client such as outlook. At a time, Microsoft feels fully confident about a spoofed from: header, it clearly declares such message to be spoofed.

After learning some basic things about spoofing, now it is the time to prepare yourself to battle against it. Following information will tell office 365 users how they should prepare themselves for new protection relating anti-spoofing.

Office 365 Users Tips to protect against Spoofing

Information for Office 365 Administrators

For the office 365 organization admin, there are many important things that they should be familiar with. Here are those things in detail:

Learning Why We Believe Email Authentication Can’t Be Sufficient to Battle Against Spoofing

Although, the security for anti-spoofing is based on SPF, DMARC, and DKIM email authentication to avoid marking any message as a spoof. An example in this regard is when the sending domain never publishes the records of SPF or they are wrongly set up, the message would be taken as spoofed unless there is a smart back-end insight with Microsoft that claims the authenticity of the message.

Taking an example for when anti-spoofing protection had not been deployed, the message could have appeared with no DKIM, SPF, or even DMARC records.

Another condition for an E5 or advanced threat protection customer, the value for compauth is stamped and then, non-E5 and non-ATP consumers will not be affected. Here is an example copy for given statement

Authentication-Results: spf=none (sender IP is 1.2.3.4)
smtp.mailfrom=example.com; contoso.com; dkim=none
(message not signed) header.d=none; contoso.com; dmarc=none
action=none header.from=example.com; compauth=fail reason=001

From: sender @ example.com
To: receiver @ contoso.com

Now, in case example.com sorted this condition by settling down SPF record, not with DKIM record, it will qualify compauth as the domain which approved SPF setup with domain in from: address. Here is the example copy:

Authentication-Results: spf=pass (sender IP is 1.2.3.4)
smtp.mailfrom=example.com; contoso.com; dkim=none
(message not signed) header.d=none; contoso.com; dmarc=bestguesspass
action=none header.from=example.com; compauth=pass reason=109

From: sender @ example.com
To: receiver @ contoso.com

But, there is also a chance for a phishing attacker to setup DKIM and SPF and then, log a message with domain of their own, yet declare a separate domain in from: address. In such condition, neither DKIM or SPF needs a domain to cope up with from: address domain, hence, until example.com sent DMARC records, it will be labelled as spoof with DMARC: here is a copy example for the same.

Authentication-Results: spf=pass (sender IP is 5.6.7.8)
smtp.mailfrom=maliciousDomain.com; contoso.com; dkim=pass
(signature was verified) header.d=maliciousDomain.com;
contoso.com; dmarc=none action=none header.from=example.com;

From: sender @ example.com
To: receiver @ contoso.com

Within client email, only from: domain gets visible, not DKIM or SPF domain. This way, it can be misleading for a user to consider a message to come from a certain domain. However, in reality it came from any suspicious domain.

For such cause, office 365 mandates that the from: domain cope with the DKIM or SPF domain signature. If it fails to do so, it should have some additional signs that show the legitimacy of the message inside. Failure to both conditions will lead to compauth fail for the message. Check the following example copy for the same:

Authentication-Results: spf=none (sender IP is 5.6.7.8)
smtp.mailfrom=maliciousDomain.com; contoso.com; dkim=pass
(signature was verified) header.d=maliciousDomain.com;
contoso.com; dmarc=none action=none header.from=contoso.com;
compauth=fail reason=001

From: sender@contoso.com
To: someone@example.com

This way, the anti-spoofing protection of office 365 safeguards users from domains that have authentication issues and also against domains with authentication, but do not relate with the from: address domain because it is the address users related to and considers the sender of message.

So, whenever you receive any message that has problem with composite authentication or labelled as spoofed message, even after passing the DKIM and SPF, it implies that the approved DKIM and SPF domain are not related with from: address domain.

Server Consultancy Menu