Alphabet Soup – The ABCs of Secure Email
I mentioned DKIM, DMARC, and SPF email settings in “Securing Google,” but only tiptoed into how to set it up. In particular, I referenced a presentation given by Jim Wagner (and most of what I’m typing out here I’m pulling from that presentation). If you are an email system administrator using Google, this is for you. Side Note: If you don’t use Google, you can still hang out, these tools will work for you too.
Right out of the gate, if you haven’t implemented DKIM, DMARC, and SPF at your school district, then, uh, YOU SHOULD. Email left unsecured comes with many risks and problems. For example, a legitimate email could get misclassified as spam. Or maybe your organization uses Google Groups and does the thing where an email gets held as spam until admin approval. Or maybe sometimes a user gets an email that is probably malicious, but it appears to be legitimately from an email address in your domain, but that user didn’t actually send it. Or maybe a user gets an email saying their email could not be delivered, and that user didn’t actually send that email. Spoofing, forgery, spam, viruses, worms, ransomware, malware, and phishing, oh my! Lots of problems with email that is left unsecured, but these are all easily addressed by implementing DKIM, DMARC, and SPF.
Google clearly explains these three standards utilized to prevent spoofing and phishing within your organizations’ email. Below is an excerpt from Google’s help articles on preventing spoofing, phishing, and spam.
“Google Workspace uses 3 email standards to help prevent spoofing and phishing of your organization’s Gmail. These standards also help ensure your outgoing messages aren’t marked as spam. We recommend Workspace administrators always set up these email standards for Gmail:
- SPF: Specifies the servers and domains that are authorized to send email on behalf of your organization.
- DKIM: Adds a digital signature to every outgoing message, which lets receiving servers verify the message actually came from your organization.
- DMARC: Lets you tell receiving servers what to do with outgoing messages from your organization that don’t pass SPF or DKIM.”
So for you non-Google people, DKIM, DMARC, and SPF… are IETF RFCs and aren’t Google-specific. They operate with DNS TXT records. They don’t require the end user to do anything. Google and the other big players use these tools, but it’s up to each domain (AKA you) to configure them and take on the benefits. These tools are technical measures so that you can tell the difference between a legit message and a not-so-legit message.
Where to Start
Before you dig in and start changing stuff, if you want to see how your Google domain is configured today, you can check out https://toolbox.googleapps.com/apps/checkmx/ Type in your domain name and run the check. The report will tell you current (and pretty basic) information, and might remind you that you already have some of this stuff going. Once you’ve done that, start digging into setting up the three frameworks for your organization.
SPF
For right now, let’s knock out SPF. SPF stands for Sender Policy Framework. We start here because SPF allows us to specify which third-party organizations (systems/networks) are permitted to send email on your domain’s behalf. Think about ALL the third party organizations that do that for you: Google, SIS, HR, school notification systems, etc.. Make a list of all these organizations. You’ll need this list to specify all systems in your SPF record. If you don’t include the important ones, you might break some things.
When creating an SPF record, it will/can contain IP addresses or ranges in CIDR format, “A” records from DNS, and “includes” that reference domains you’d like to permit. An SPF record must end with an action to take for senders that aren’t approved. A soft fail (~all) is recommended for unapproved senders. Most of the time, your third party organizations can assist you with what information you’ll need from them to get going for them to work properly. So reach out to the ones on your list or consult their help documentation.
If you have a Google Domain (Gmail), Google, OF COURSE, recommends that your organization has a SPF record in place. Google also recommends doing the soft fail (~all) on anything not approved. Here’s a great Google link that is a “how to” with their recommendations… https://support.google.com/a/answer/33786?amp;visit_id=637866679759178170-1255581314&rd=1&product_name=UnuFlow&hl=en&visit_id=637866679759178170-1255581314&rd=2&src=supportwidget0&hl=en I’d recommend you use this guidance (and this article) to build your record.
Below are a few examples of SPF records that are fully constructed in a TXT record for a domain.
Basic example only allowing Google servers:
v=spf1 include:_spf.google.com ~all
An example allowing Google and other sources:
v=spf1 ip4:1.2.3.4 ip4:192.168.0.1/16 a:server.Arecord.org include:_spf.google.com ~all
An example if you use Google, Tyler SIS hosted (as of 4/27/22)
v=spf1 ip4:1.2.3.4 ip4:192.168.0.1/16 a:server.Arecord.org include:_spf.google.com include:amazonses.com ~all
An example of my Google and SIS hosted school district:
v=spf1 include:_spf.google.com include:spf.sisk12.com include:amazonses.com ~all
Additionally, please note that any server name in an SPF record requires a DNS lookup. This includes any “include” options and any name that is contained within another include record. You get a max of 10 DNS lookups. You can use this SPF record check tool to make sure you are under the limit… https://dmarcian.com/spf-survey/
Spend time and build your record. Then, it needs to be published to DNS as a TXT record. The third party you use, whoever manages your DNS, or you, will do this. You don’t do anything in the Google Admin Console for SPF.
Well, what are you waiting for? Do it, publish it, and feel good about it. Next up, we’ll talk DKIM and DMARC.