There are several steps that an organization should take to minimize their likelihood of being email “spoofed” by a hacker. Best Practices for SPF and DKIM are highlighted.
What does it mean to be spoofed? There are several methods, but the overall goal is to persuade email recipients to believe that an email received from someone else (a bad guy or hacker) actually came from you. One method leverages the fact that emails contain two different “sender” values, the one you see in email (perhaps their full name) and the reply address (which is often falsified, instead sending the response to the hacker). Modern mail servers can perform simple checks to see if the email they just received and sent along to your inbox was genuinely sent by a server recognized by the sending organization.
The simplest check is done using Sender Policy Framework (SPF). SPF works under the assumption that the person or organization that registered a domain is the only one who can change the information published via the Domain Name Service (DNS). DNS converts simple name requests like www.google.com into an IP address that ultimately defines a specific server on the internet. The concept is simple: list the addresses of the servers you own (or are responsible for sending email on your behalf) and have the recipient check to see if it is where the incoming email originated. If not, mark the email as “failing” the SPF check. Unfortunately, many organizations instruct the receiver (using the same DNS information) to “ignore” the validation error if the sending server is not on the list. Why?
Uncertainty… Many organizations that implemented SPF weren’t 100% sure if they set it up properly. Did they forget about a partner or online survey website (MailChimp, Salesforce, SurveyMonkey, etc.) that sends emails as if they originated from them? SPF records allow you to add a suffix, indicating how the receiver should treat mail that does not match the list provided, marking it as a soft-fail or a hard-fail. A hard-fail tells the receiver to drop the email. A soft-fail suggests marking it as probable spam and is the most common choice we see. This lets an awful lot of sketchy email get through.
Along came DKIM (Domain Keys Identified Mail). DKIM also uses DNS to publish records that can be queried by receiving email servers. The difference is that the record presents the “public key” associated with a private/public key pair. Sound confusing? It’s really not. Just remember this: this key pair is very secure. The private key is known only to the sender. It’s used to generate a “check code” or “hash” for each email sent. This hash is sent along with the email to the receiver. The receiver queries DNS for the associated “public key” and uses it to calculate its own hash of the same email. If the one sent matches the one calculated, the email was sent by the approved sender. It’s nearly impossible to calculate the private key from the public key, so the likelihood of a hacker generating the proper hash value is very low.
All of this protection must somehow be measured for its effectiveness. This is achieved using Domain Message Authentication Reporting & Conformance (DMARC). DMARC is another published DNS record, which in this case, provides instructions that the receiver should follow when there’s a failure of the DKIM hash. It also has something of a hard/soft-fail option, but instead uses the options of -none, -quarantine, and -reject. “None” is comparable to a soft-fail, while “quarantine” suggests marking it as spam or sending it on to a “review team” to further investigate the validity of the email. “Reject” instructs the server to deny delivery. In addition to describing how receivers should handle failures, the DMARC record also provides email addresses to which failure information can be sent. Organizations will initially set the failure instruction to “-none,” allowing them to collect these failure notices while allowing the mail to still flow through. After the unplanned failures have been addressed, the disposition flag can be changed to “-reject.”
Is your business email protected by any of these measures? Likely not. While the implementation itself is fairly simple, it’s essential to identify all of the sources of email that send on behalf of your organization. Businesses often employ third-party billing partners who send invoices on their behalf, or they use many of the services referenced earlier. All of these sources have to be identified before configuring the appropriate protections. Once that research is complete, the proper records will be published via DNS (along with a number of email server changes). Finally, the failure rate will be monitored and the appropriate adjustments made.
In the end, utilizing these measures will make it much harder to spoof your email address. There are many examples of spoofed emails leading to fraudulent wire transfers or as the basis for other social engineering attacks. Contact Exigent Technologies and let us help you to strengthen your cybersecurity posture, including implementing best practices for SPF. And for specific expertise in the Ubuiqiti line of products, contact our expert Ubiquiti consultants in Denver, CO at (303) 222-0772.
Daniel Haurey Jr. is the president and founder of managed IT services provider Exigent Technologies, which he founded in 1997. Under his leadership, the MSP has earned accolades ranging from Channel Futures MSP 501 to being named SonicWall’s 2024 MSP Growth Partner of the Year. Dan is a true entrepreneur, dedicated to growing, investing in, and mentoring small businesses. You can find him on LinkedIn, where he regularly posts about technology, business, leadership, and community.