11 Myths about SPF, DKIM, DMARC and the Reality – Marketers View

It is futile to expect customers to identify phishing emails and report about the same. It is, on the contrary, up to the brand to take required measures. About 97 percent of users fail to identify a phishing message because these messages are appropriately camouflaged to look sophisticated.

As a result, now brands are turning to SPF, DKIM, DMARC records. It is better to take technology’s help in blocking such emails from reaching the users’ inboxes. DMARC (Domain-based Message Authentication Reporting and Conformance) standard helps in doing this.

It is very easy to add proper SPF, DKIM, and DMARC records in few minutes. However, there are many misconceptions about the implementation of DMARC, which our implementation team keeps on listening. These fake concepts often act as a hindrance in your efforts to identify and lessen the impact of phishing attacks.

Adding SPF, DKIM, DMARC records will increase your email inbox placement.

Here are 11 such myths about SPF, DKIM, DMARC that must be discarded

1. DMARC “reject” policy can be deployed with the data that DMARC reporting mechanism contains

Nope! Rather you will need to provide additional data to the RUA and RUF context. Else you will have just guess works to help you out, and that can be dangerously stressful.

Related: DMARC is The Reason for your Increasing Email Delivery Failure Rate?

2. Listing all the possible header fields in DKIM signature is “secure”

But that is not your goal with DKIM. You want to validate all techniques to ensure that only you have the authority to send out the message in question. Hence, it only makes sense to pick few fields in the “h: array”.

3. “Include” Statements in your SPF records rather than individual IPs, or CIDR (Classless Inter-Domain Routing) range

But your SPF record should be clean and a flat list of IPs. Hence, “include” statements should be in minimum. This will help you in leveraging the speed and eliminate chances of having a failure.

4. 11th Include Statement should be added

You must add only 10 include statements as allowed by the SPF protocol. Adding the 11th one will cause a break in the record.

5. Emailing your DKIM private key to someone else is okay

This itself is an irony. The moment your DKIM key is sent out to another person, it ceases to be private! Your DKIM key shouldn’t be anywhere else other than the MTA which uses it.

6. All emails should be sent from the organizational/ top level domain

That is a bad idea. Some may be based on security and vendor management others may be of sound deliverability grounds. Why would you exactly want to mix all these!?! Check these resources from Google for more insights.

7. DMARC record in the top level domain is essential

It may be a good start, but having a DMARC record in the top level domain may not give the requisite control and reporting scopes.

All domains that your company owns must be protected with a DMARC policy.

8. Bad guys will follow your suit and send emails from that particular subdomain you use

The entire domain is at risk all the time. You need to lock the entire domain- the main organizational domain as well as the subdomain. Contrary to popular belief, the primary organization domain is made the target rather than the subdomain.

9. Copy the previous infrastructure decisions

That is lame! Believing that previous email infrastructure builders were right throughout, you will only go a step closer to your doom. Instead, you must use the new DMARC deployment as a chance to redesign and optimize the infrastructure and architecture.

10. All vendors can sign DKIM in 2016

There is a huge difference in “should” and “can”. Go for an expert who has the requisite knowledge on how to overcome the hurdles you will face in authenticating your infrastructure properly with DKIM; especially in regards to third party vendors.

11. The outgoing emails from your mailbox have proper SPF, DKIM, DMARC records

The emails which you are sending from your organisation mailbox may not have proper SPF, DKIM and DMRAC records implemented. You need to check and verify this with your IT team. If this is not in place, then, emails sent from your organisation mailbox may not land in the inbox of the recipient.

This blog post is the part of 11 Easy Ways to Identify Phishing Emails, which explains about the identification and impact of phishing emails on email marketers.