Such a scam often begins with a spoofed email message, which at first glance appears to be a legitimate email from a coworker. Most of the time, these emails include a request from the superintendent, assistant superintendent or other business official. Here's an example:
On Wed, May 4, 2016 at 10:26 AM, (YourSuperintendent) wrote: Hi Lori, Do you have a moment? I am tied up in a meeting and there is urgent matter i need you to take care of. We have a pending invoice from our new Vendor. I have asked them to send a copy of the invoice. hopefully i should received it later today or tomorrow and i will appreciate if you can process a wire before the cut off time. What details do you need to process this to hit the vendor account today. NOTE: I can't take calls, email will be fine. Thanks, YourSuperintendent Sent from my iPhone
But staff should take note of a number of key indicators that signal potential problems with this message. First, a superintendent would not use such poor grammar, even from a phone. The superintendent also doesn’t have an iPhone. Finally, if superintendents wanted this information, they would typically call the staff member, even though not all staff members know that.
What can you do to prevent these types of messages? Starting an awareness campaign can help staff understand why they should review these messages more closely. This awareness campaign can include an email or newsletter to staff. Here are some of the things you may want to consider as you start the awareness campaign:
- Explain to staff how to identify poor grammar. In the example, there are many capitalization errors: "I" is lowercase while the word "vendor" is capitalized. And the message includes many other grammatical errors.
- Hovering over the email name will typically expose the underlying email address where the email really came from. In the case of the email above, it was from (YourSuperintendent) Superintendentoffice@aol.com.
- Even though the message indicates not to call, make a call to the superintendent or business office official to confirm the information being requested.
- Don’t click on suspicious Web links such as ones requesting to verify your email account and password information. Hovering over the Web link will expose the URL the perpetrator is trying to send you to.
- Set up an email address where staff members can send reports of suspicious emails to the technology department. Once the technology department has the information, it can block phishing attempts. If the email is widespread, the department may want to send an email blast out to staff identifying that the email is a scam and should be ignored. It’s equally important to have staff report if they complied with an illegitimate request.
These principles apply to any email system, but for the purpose of this article, we’ll use examples from Google because many school districts are using Google Apps for Education.
The first record to create is a Sender Policy Framework (SPF) record. An SPF record is a type of DNS TXT record that identifies which mail servers are permitted to send email on behalf of your domain. The purpose of a SPF record is to prevent spammers from sending messages with forged “From” addresses at your domain.
When an email comes into a Google email account, it will be marked as SPAM and put in the SPAM folder. The email below was sent from a domain in the Czech Republic using my email address. You will notice the violation warning from Google.
A link to Google support on the setup of the Google SPF record provides guidance on how to set it up. Finally, to verify that your SPF record is live and working, just send a blank email message to checkauth@verifier.port25.com from your Gmail address. You’ll receive an instant reply with the results of the SPF check. If you see a “pass” against the SPF check, it means the SPF record is working and should prevent your Gmail messages from getting rejected as SPAM.
The second DNS record to set up is called a Domain Keys Internet Mail (DKIM) record. DKIM uses DNS TXT records to define Domain Keys policy and public encryption keys for a domain name. Once the DKIM record is setup, it will take time to propagate. Once this has taken place, authentication can be turned on in the Google administration panel.
A link to Google support for the setup of the DKIM record provides guidance on how to set it up. The typical DKIM record is 2048 bits. The DKIM record setup will depend on whether you host your own DNS servers or use a hosting company because of the way the long authentication string is formatted in DNS. A Google search on “DKIM DNS record character limit” yields many articles on this topic.
The last and final step is to create a Domain-Based Message Authentication Reporting and Conformance (DMARC) DNS record. At a high level, DMARC is designed to satisfy the following requirements:
- Minimize false positives
- Provide robust authentication reporting
- Assert sender policy at receivers
- Reduce successful phishing delivery
- Work at Internet scale
- Minimize complexity
The three options available for Google domains are:
- None: Take no action. Log affected messages on the daily report only.
- Quarantine: Mark affected messages as SPAM.
- Reject: Cancel the message at the SMTP layer. The message will not be delivered to the intended recipient.
Once the mail flow is verified, you can move onto the “quarantine” or “reject” options. I always recommend using the “quarantine” option first and then setting the “reject” option after email flow is working as expected. This Google support article will walk through how to start slowly and then increase the percentages until 100 percent is achieved.
It's also equally important to have a separate email account identified in the DMARC DNS record to receive the DMARC reports from companies that also use DMARC records. For example, don’t use your personal email address, since DNS records can be publicly queried and expose your email address. Using an email address such as dmarcrep@yourdomain.org or dmarcabuse@yourdomain.org allows you to review the reports without exposing your email address and filling up your inbox.
These recommendations from DMARC.org will walk you through the successful deployment of the DMARC record:
- Deploy DKIM and SPF. You must first cover the basics.
- Ensure that your mailers are correctly aligning the appropriate identifiers.
- Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
- Analyze the data and modify your mail streams as appropriate.
- Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.
A version of this post originally appeared on CoSN's blog. Republished with the author's permission.