Skip to main content

Securing Google Apps for Education GMail

Over the past year or so there have been lots of posts on various G+ communities about issues with GMail delivery (particularly to groups) and accounts being exploited by email spoofing. So I thought it might be an idea to bring together the steps you need to take to knock these issues on the head into one place.

The steps:

  1. Configure your domain to use SPF (sender policy framework)
  2. Configure your domain to use DKIM (Domiankey identified mail)
  3. Configure your domain to use DMARC (prevents email spoofing)
  4. Force all incoming SPAM into admin quarantine 
Numbers one and two will improve your email flow and prevent your messages (particularly ones going to groups and certain outside agencies) being marked as SPAM.

DMARC relies on the SPF and DKIM being correctly configured first. All messages you send will be checked and ones that fail either SPF or DKIM will be actioned in accordance with a rule you set.

The final step prevents end users ever seeing anything in their SPAM folder. All SPAM ends up in admin quarantine, thus preventing end users ever having the opportunity to click on nasty messages.

In detail

1. SPF
To enable SPF you will need to enter a TXT record in the DNS editor of your web hosting company. The record should be v=spf1 include:_spf.google.com ~all  
Your hosting company may have a specific section for email authentication where this record can be pasted in in the SPF section. Once enabled messages should have a 'mailed by' section in the details:
2. DKIM
To enable DKIM you need to turn on email authentication in the Google Apps admin console. So navigate to Apps, Mail, and look for email authentication.
There you have an option to turn on authentication (DKIM). There will be a TXT record name and value (a long key). In your domain hosting DNS editor create a TXT record. The name is the name shown in the Google Apps admin console - google._domainkey , the value is the long key - just copy and paste it. TTL I normally set as 14400.
Once you have saved the record in the DNS editor, make a cup of tea and read the paper. When you have finished, click 'start authenticating' in the Google Apps management console. If all is well it should go green. If not wait a little longer and just double check your work. To test, send a message to another gmail account. You should see:
3. DMARC
Now before you start on this bit be absolutely sure steps 1&2 are working. I'd give it a few days and check both SPF/DKIM work reliably. If all is well, continue. DMARC checks all messages you send from your domain and acts on any that fail either SPF or DKIM. 
To enable, create a TXT record with the name: _dmarc.your_domain.com
The valve should be: v=DMARC1; p=whatyouwanttohappen; rua=mailto:emailladdressformessages

So p can be: 
none - nothing happens if a message fails either SPF or DKIM
quarantine - messages that fail go into SPAM
reject - messages get rejected

You can also add the variable pct=X where X is the % of messages that the rule applies to. Not a bad idea to use early on just to see what gets stopped.

emailladdressformessages - the email address  that will get the daily messages that tell you what messages has passed and which have failed and why. I skip the inbox with these and filter them into a label called DMARC.

All being well, you won't notice anything much other than the daily messages. Assuming you have either quarantine or reject selected you will now be immune to email spoofing.

4. Force SPAM into Admin Quarantine. See my blog post here on how to do this.

As a footnote, I'd also say that you should never whitelist any domains or email addresses - ever. If all of the above of correctly configured, you should never have an issue with things being picked up as SPAM and therefore the need to whitelist domains vanishes. Whitelisting domains sort of says, please SPAM me - so don't be tempted to do it!





Popular posts from this blog

Delete a specific email using GAM

If a user send an inappropriate email to a loads of people or get stung by some sort of email exploit you can quickly delete the email from all of the recipients using a GAM command.
Step 1 - get the email header Go into Google Vault and search for the offending user or someone known to have got the message.
Click show details and grab the email ID. This will be a long string of characters followed by @mail.gmail.com
Step 2 - find out who has the email Go into Google Vault and find the original message sent by the offending user. Look at the details to see who got it. Copy the list and dump it into a spreadsheet. Clean up to just a list of emails with a column header 'mail'. Save as a csv file.
Step 3 - delete messages with GAM Put your CSV file in your GAM folder - this e.g. assumes its called mail.csv
Run:
gam csv mail.csv gam user ~mail delete messages query rfc822msgid:MESSAGEIDHERE doit

The alternative nuke option is:
gam all users delete messages query rfc822msgid:MESSAGEI…

How to push bookmarks to users in Chrome via the management console

With the release of Chrome and ChomeOS 37 an update to the management console has arrived that allows you to push bookmarks to users.

Under Device Management > Chrome > User Settings > User Experience you will now find the option to add managed bookmarks.


In the example above, the bookmarks are applied to the sub-OU of 'students' - so all our students will get these bookmarks. Simply add your url and the bookmark name, click the + and save. These will appear in a folder called 'yourdomain bookmarks' - see below:



Be aware that to get these bookmarks applied on a Windows/OS-X device the user must be signed into Chrome. Update: if you install the latest group policy template you can push the bookmarks via policy on PCs - details are given here.
Video Guide:

Managed Android Apps on ChromeOS on an Edu G Suite Domain

Android Apps via the Play Store have been available on consumer accounts for some time on selected devices. We have 1:1 Acer R11's and have recently had the opportunity to trial them on G Suite Edu accounts.

From the point of view of the end user, they see the Play Store App appear on the shelf and have to agree to the terms and conditions. After that, force installed and pinned apps are immediately installed and they get access to the Google for Work Store. This only contains apps you have approved for that user.

For the administrator the steps are:

Enable Play Store Apps for the domainEnable access to the Play Store for specific Sub-OUs or usersAdd apps to Play for WorkSet permissions for each app - can install, force install or pin to shelf. This can be done differently for each app and each OU and is therefore very granular. 
Issues so far

Apps take a while to appear in the Play Store for users. Initially only force installed apps appear.You cannot set the permissions of multipl…