Long before there was Google Workspace, there was Gmail. And whether it is used for notifying staff about important events, receiving Classroom update notifications, or students communicating among themselves, Gmail is one of the most used features of Google Workspace.
At the beginning of the internet, developers were just happy that things worked and that messages went from server A to server B. There was little in the way of security in mind when developing the protocols that the modern systems are built on today. Soon after email became a means of communication, those who would abuse the openness of the system started to make alterations. Hackers, spoofers, phishers – all of these bad actors, each with their own agenda, all trying to access something that the default Simple Mail Transport Protocol (SMTP) permits, if not protected against.
SPF
We start with SPF records. SPF, or Sender Policy Framework is entered as a DNS TXT record. This record is used by receiving mail servers to know whether the message they received came from a source that is permitted to send it. This works as an authentication check, but where any message sent from a server in your SPF would pass this authentication, it’s a far cry from being the only measure that should be taken.
To configure SPF, you will need to enter the external IPs that you’re wanting to permit to send emails as your organization. If your SIS sends out emails to parents or staff, you will need to include them in the SPF record as well. The same goes for any bulk mail systems or other services.
Ideally, your SPF record will end in ` -all` which will cause all emails that do not come from one of the authoritative sources to be rejected by the receiving server as not authenticated. Alternatively, you can end in `~all` which would result in a “soft fail” allowing messages to be delivered, but not authenticating and increasing the possibility of any unauthenticated messages to be flagged as SPAM. An Example SPF record can be found below:
“v=spf1 include:_spf.google.com include:mail.zendesk.com include:spf.protection.outlook.com -all”
It’s important to note that SPF records are only checked by the receiving mail platform, which could completely ignore it altogether.
DKIM
With the first level of defense in place, mail servers that are not within our defined authenticated servers DNS entry should not be able to send messages as our users. However, many email servers are used by multiple organizations. In the above example, any email sent from the servers associated with mail.zekdesk.com, _spf.google.com, or spf.protection.outlook.com would be authenticated as your users given a valid mail header. While this will protect from non-authorized servers from sending emails, it does not prevent all Spoofing attempts. This is where our next level of protection comes in.
DomainKey Identified Mail (DKIM) is designed to provide a second method of authentication for your user’s messages. This method uses a private and public key which are used to validate that the message came from the sender. Again, DKIM uses a DNS TXT record to publish the public key. Each entry in your SPF would need to have a separate DKIM host. The default value for Google’s DKIM host is `google._domainkey`.
Configuring DKIM starts in the Admin Console in Apps > Google Workspace > Gmail > Authenticate Email. For each of your domains, you will have a dropdown next to the Authentication Status:
Clicking “Generate new record” will populate the TXT record value with the new host and Public Key that you publish on your DNS records. If we were publishing this one for secondary.gafetest.com, the TXT record would be published for the host google._domainkey.secondary.gafetest.com.
DMARC
Now that SPF and DKIM are configured, an optional step would be to publish what authentication mechanisms your organization is using. This is where Domain-based Message Authentication, Reporting, and Conformance (DMARC) comes in. Configuring a DMARC tells individuals who are outside of your organization how you are authenticating, and how to handle failed authentication measures.
A general first step with DMARC is setting it up as a listener only. This way, messages are delivered as normal but a report of any failures is delivered to a specified email address. If large number of authentication failures are being delivered to users, configuring the additional measures can be taken. DMARC is also used to determine how to handle suspicious messages that your users receive. Google’s done an excellent job documenting setting up DMARC which can be found here.
Reading the DMARC reports can be somewhat confusing, so using a service like dmarcian can provide you with more readable reports, for those wanting something a bit easier on the eyes.
MTA-STS
The newest of the mail security options, Message Transfer Agent – Strict Transport Security (MTA-STS ) ensures that messages are delivered with end to end encryption. Configuring MTA-STS prevents “man-in-the-middle” type attacks by adding a flag notifying that all messages from your organization will be encrypted using TLS, and that the messages will be signed using a valid public certificate.
MTA-STS is designed to mitigate against active attacks against user’s messages. When enabled, it ensures the message which was received matches the one which was sent. It also makes sure that the content is not sent between mail servers in plain text. Enabling MTA-STS within Google means that if a sending server has the capability of using MTA-STS, it will be authenticated and encrypted, and when your users send emails, they will be authenticated and encrypted so long as the receiving server supports it.
As with all other items in this post, MTA-STS is configured with DNS TXT records. Like DMARC, MTA-STS can be configured in a “testing” or “reporting” only mode. This can be used to ensure that your policy is configured properly before enforcing it, as well as get reports about encrypted and unencrypted messages that your users are sending and receiving.
Although at times it might feel like alphabet soup, understanding these security measures helps us to protect one of the most important and most attacked applications used by users within Google Workspace. With properly configured SPF, DKIM, DMARC, and MTA-STS we can be assured that our users are protected with best practices when communicating through email.
If you would like assistance or training your team, book some time in with our Technical Services team by reaching out to support@amplifiedit.com. Learn more about the various ways we can help your team.
-
Stephen Gale
Technical Support Analyst -
About the Author:
Stephen lives in Utah and enjoys the puzzle of investigating users’ problems and finding potential solutions. A recovering/reformed gamer, Stephen throws himself into his passion for staying on top of all things Chrome OS and Chromebook related. Prior to joining Amplified IT, Stephen served as a network admin in a therapeutic boarding school and an IT director, where he implemented Google Workspace for Education. Stephen has studied computer science and security at Weber State University, Western Governors University. A self-anointed honor, Stephen likes Chromebooks more than almost anyone else in the world.