DMARC 101: How to Keep Phishing Attacks Out of Your Inbox

You have the latest antivirus program. The firewall is turned on. Passwords are strong and frequently updated. Now you can sleep at night knowing your organization is safe from cyberattacks, right?

Well, at least until John from HR decides to log in from a link he received in an email. He probably knew not to click on suspicious emails, but what is considered suspicious? That email could have arrived from your own domain.

Attackers can spoof your domain to trick employees or your customers into divulging confidential information or downloading a malicious file attachment. Phishing emails are arriving with smarter baiting tactics, becoming harder to identify. Defenses need to catch up as well.

Security teams, especially those responsible for domain integrity, should make sure to correctly implement the three anti-phishing standards: SPF, DKIM, and DMARC.

The ABCs of DMARC
Earlier this year, Congress passed the National Defense Authorization Act, which requires the Department of Homeland Security to either implement or come up with a plan to implement DMARC across all US-based email providers. DMARC, or Domain-based Message Authentication, Reporting & Conformance, needs results from SPF (Sender Policy Framework) and/or DKIM (DomainKeys Identified Mail) to work. For that reason, at least one of the two must be enabled for your domain to implement DMARC.

These are basically global phishing protection standards that enable receivers to verify that an email claiming to be from a particular domain was actually sent from a mail server authorized to send emails on behalf of that domain. For a sender, these methods can protect people from fraudulent emails that claim to be from your domain.

How Do They Work?
Speaking at a high level, the sender's domain puts SPF, DKIM, and DMARC records into the domain name system (DNS). The SPF DNS record includes the IP addresses and/or domain names of authorized email servers. DKIM utilizes an additional public-private key pair for verification. And the DMARC DNS record includes policy recommendations and requested reporting back to the sender.

Based on the results from SPF and/or DKIM, DMARC tells the receiving side what to do with those emails. DMARC policy can be set to accept all emails even if they fail SPF/DKIM, quarantine them, or reject them.

Why Rejecting All Failed Emails From the Get-Go Is a Bad Idea
Simply rejecting all emails that fail SPF or DKIM (a "hard fail," as it's called) right away isn't the best approach. There's a possibility that one of the methods could be misconfigured or the DNS records could be missing a third-party email server that's authorized to send emails on your domain's behalf. Sometimes, people don't even realize that they're using a different public IP address. If your DMARC policy is set to reject, there could be authentic, important emails that don't make it to the receiver's side.

The best approach for setting up DMARC is to first test the waters by setting the policy to "none," which essentially means your email traffic is monitored without any action. You can get the reports to determine whether you've configured DMARC properly. It's a great way to troubleshoot and check for missed IP addresses.

If everything turns out well, you can go ahead and set the DMARC policy to "quarantine," which puts the failed emails in a spam folder. The goal should be to eventually set DMARC policy to "reject" once the infrastructure is mature enough.

How Do Phishers Still Get By?
If you think you've set up DMARC and now phishers can't get by, know that malicious users always find a way of getting around security controls. DMARC can protect against others using your domain name. But it doesn't protect you from phishers creating new domains that can be mistaken for your domain.

For instance, emails wrongly claiming to be from microsoft.com will be rejected, but what if the attackers create another domain, such as microsoftusaemailchecking.com? To take the attack a notch further, attackers can even set up their own SPF, DKIM, and DMARC records for the fake domain. Receivers can now send a phishing email that's passed SPF and DKIM.

Or attackers can create a tricky email address like [email protected]. DMARC will let it through because the email is indeed from Hotmail's email servers. DMARC doesn't verify the email address; it just verifies the domain.

Why Bother if Phishers Can Get By?
DMARC does block a significant portion of phishing attempts. And it's not even that difficult to configure. So the better question is: Why not? At least you won't be dealing with phishers using your domain name to fool people.

Having said that, nothing substitutes phishing awareness training. You'll always have those carefully crafted emails that look legitimate and can trick security controls. For such attacks, your employees should know how to spot a rogue URL. Simulated phishing attacks, especially those using real-world phishing emails that have been "defanged," are an excellent way to test your employees' resiliency and susceptibility to phishing attempts.

Together, DMARC and security awareness exercises can help give people comprehensive protection against phishing attacks.