Did you know that more than 3.1 billion domain spoofing emails are sent per day? And over 25% of these get into Office 365, which has over 60 million commercial users.

That means the data of over 15 million people is at risk every day.

Let that sink in.

Even giants like Facebook, Microsoft, and Google aren’t safe from email spoofing. This raises the question: how can you protect your business from spoofing and spam emails that steal your data?

This is where Domain-based Message Authentication, Reporting, and Conformance (DMARC) comes in. But how does DMARC protect your business from spoofing emails? Let’s find out.

What Is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a software protocol that takes care of emails that aren’t authenticated by the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

It essentially protects both email senders and recipients from email spoofing, phishing, spam, and impersonation fraud, which is the most common cause of data leaks.

DMARC helps email users specify actions that need to be taken when incoming emails fail SPF and DKIM authentication. It does this by labeling emails that have failed to pass SPF and DKIM protocols.

Prevention Policies: How DMARC Handles Email Spoofing and Spam

DMARC usually requires domain owners to add a policy (p=) tag in their DMARC record. The tag tells the protocol on how to deal with a suspicious email. There are three types of policy tags you could use to protect yourself against email spoofing and spam:

· The p=none policy — This policy gives users insights into who sent the DMARC-failed email but doesn’t stop the email from entering their inbox.

· The p=quarantine policy — This policy sends DMARC-failed emails into your spam folder, reducing the chance of you opening them.

· The p=reject policy — This policy stops DMARC-failed emails from coming into your inbox entirely. It prevents email spoofing attacks.

How to Implement a DMARC Policy to Handle Email Spoofing and Spam

Here’s a rule to follow: Don’t go too hard too fast. Let us explain. If you implement the p=reject policy directly, you may inadvertently block emails from your colleagues and friends, which can be a huge problem when collaborating on projects.

So, instead of doubling down on all suspicious emails, begin with the p=none policy first, collect data about the percentage of suspicious domains sending you emails, and input the percentage (using the pct option) into a quarantine policy.

For instance, if you find that 20% of the emails you receive are from suspicious domains, you should input that number into your quarantine policy like this: p=quarantine pct=20, which means 20% of the incoming messages will be quarantined.

You can increase this percentage as you become aware of other suspicious domains. Or you can even scrap this policy and instead use the reject policy once you reach the 100% suspicious domain mark. It’s entirely up to you.