UPDATED ON AUGUST 18, 2020
One question that has come up often during discussions of DMARC is “We have SPF and DKIM implemented, so do we really need DMARC?”
The answer is YES! You still need DMARC!
Why? The main reason is that SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) on their own (or even together) contain various weaknesses. However, when both are combined with DMARC, both protocols are enhanced and more secure. DMARC is not a silver bullet, but utilizing it will make an organization’s email domain much more secure.
What is SPF?
SPF is a policy that defines which mail servers are authorized to send email on behalf of an organization. These typically are an organization’s mail server, but can include third party email services as well.
There may be cases in which the IT staff are not aware of what other departments might be doing when it comes to email. For example, the marketing team could be using a cloud PR tool or a cloud survey to send mail using the organization’s email domain. SPF should prevent any of those systems from sending messages, as well as spammers and phishers.
However does it actually work? That depends.
One way to determine if SPF is working is to send mail from authorized and unauthorized mail servers. The result will show that mail is being sent by unauthorized mail servers as well as authorized systems. Why? Well, SPF Verification must be enable on the receiving end. By doing so, the receiving end now must decide how to handle the failed messages marked by SPF. However, this is tricky for them. How does the recipient side know which servers are authorized or unauthorized?
Another issue is when you are using cloud email service providers. They all provide the same systems for business to use to send mail. Office 365 has you add spf.protection.outlook.com. G-Suites has you add _spf.google.com. So if all these businesses are using the same email cloud service and the same servers, then what is to prevent one business from using the domain of another business?
What is DKIM?
DKIM is designed to add a digital signature to every message that is sent by an organization’s mail server. The purpose of this signature to allow for the recipient systems to confirm that the message is coming from an authenticated domain. This digital signature is not visible to the sender or recipient.
The only way to confirm the DKIM signature is present is by looking at the message headers (something which more end users are not familiar with) or to have technical mechanism to check.
If the DKIM signature is not visible, then how does an organization check for it? It’s not reasonable for a user or IT staff to check each message header to the digital signature. Some mail gateways do have a feature to check incoming messages for DKIM signatures. However, the DKIM checker option is typically to either accept or reject the messages. If enabled, there is a possibility that any messages without DKIM signatures are rejected, and it is up to the recipient to make that determination, not the sender.
“I can use both, right?”
Ok, now the question should be “I can use both, right?” Yes, you could use both, but the flaws mentioned above still exist. Additionally, there is nothing indicating that SPF should work with DKIM, or that DKIM should work with SPF.
This is where DMARC comes into play. DMARC is the policy that will define SPF and DKIM (the A or Authentication in DMARC) and must work together using the policy level defined by your organization (which is the C or Conformance in DMARC), as well as add a reporting feature (the R or Reporting in DMARC).
The author, Shehzad Mirza, is the Director of Operations (NYC Office) at the Global Cyber Alliance. You can connect with Shehzad on LinkedIn.