Your Company’s Email is Getting Caught in Spam Filters… and it’s Your Fault.
Maybe.
But now that I have your attention…
Email is one of the most important – if not THE most important – form of communication in the business world. So much so, that any disruption leads to end users grabbing their proverbial pitchforks and torches. And as phishing campaigns continue to rise, we are increasingly adding security to our email platforms – so what could go wrong?
If you have ever migrated from one email security to another, you’re probably familiar with the process. With any project of this nature, we frequently see instances, as I’m sure many others do, where emails the end user is expecting/wants to receive are getting caught in spam – otherwise known as “false positives.” The reflex is to update the allow list and make the problem go away, but how often do you look at why the messages are getting caught?
Recently I was involved in migrating from one email security player (rhymes with LimePast) to Proofpoint. Everything seemed to go OK. However, as per usual our help desk got slammed with calls about false positives. I decided to have a look and found that in this deployment, every single “false positive” was due to the sender having misconfigured SPF, DKIM, and/or DMARC records.
SPF, DKIM, and DMARC are free and open standards that allow you to protect your email domain from being spoofed for the purpose of phishing – and it all runs through your DNS.
An SPF record is a TXT record that states all the addresses from where you will send email. It can include domain names and IP addresses. When you send emails, the receiving server will check the internet for your SPF record and compare the sending address to that record. If there is a match, it’s all good. If there is no match, it is flagged and potentially quarantined. In the below example, the sender uses Proofpoint:
However, if I check their SPF record, Proofpoint is NOT listed as a valid sender:
In this case, Mirazon’s Proofpoint deployment quarantined everything from the sending company.
Next on the list is DKIM. DKIM allows your sending servers to digitally sign emails using PKI. The way it works is you generate a certificate pair consisting of a private key and a public key. When it comes to email, the server signs the email with the private key, and the receiving server queries DNS for the public key. If there is a match, the email is viewed as authentic. If there is not a match, it is inauthentic.
Finally, there is DMARC. DMARC ties it all together and consists of a DNS record that provides instructions for what to do if SPF and/or DKIM fail validation. You have the option to log only, quarantine, or actively reject the message if SPF and/or DKIM validation fails. Additionally, you can provide an email address in the form of a URI to receive reports and feedback.
You will need to make sure you maintain your configuration. Anytime you add another email sender – like an SMTP relay or service that sends on your behalf (ex. Constant Contact) – you must update your DNS.
When used together, SPF, DKIM, and DMARC ensure the email you send is trusted and not blocked. But this is very much a case of if you aren’t going to do it right, don’t do it at all.
If you have any additional questions or concerns, please call 502-240-0404 or send us an email at info@mirazon.com.