Wednesday, 7 June 2017

Outgoing Email Security in 2017: SPF, DKIM and DMARC

In the IT trade, you are regularly exposed to the misery of others that are somewhat less tech-savvy.

Of late, I've been exposed to far too many people falling prey to 3rd party compromised accounts and spoofed email attacks - with quite significant financial losses. It has also happened to other schools. It's something sysadmins can help with, so let's do that!

As you no doubt know, the Internet is not secure by design - and that includes Email. Read on for how you can take some steps to help secure your school's outgoing email communications...

First and foremost, all of this is somewhat moot without securing your end users, network and computing platforms, too.

This involves educating them about secure computing and use of things like 2FA - as well as all your "normal" sysadmin duties for the underlying tech. We're not going to cover that here - we're going to assume your computing platforms and your users are covered by your internal campaigns to educate everyone in the bare minimum IT security techniques - and of course your day-to-day "sysadmin-ing"!

If you've not yet embarked on education campaigns, start one, and first target those that are most likely to cause/carry a risk of organisational reputational harm (senior management, teachers) and, particularly, financial risk (financial administrative staff). Don't forget to cover social engineering attacks in person and over telephones! If you can, and your school allows it, look at enhancing what the kids understand about secure computing and online safety.

None of the techniques below are remotely new, so it is somewhat surprising that more organisations don't use them.

I'm going to assume you're using GSuite for Education as your email platform - in part, that's because we do, and I can therefore talk about it, but also because they make it really easy, to the point even SMMEs and personal vanity domains can do it. All of these can be done with any sane platform - if you're still running your own mailservers, often with some engineering work (an exercise I'm going to leave up to you if you're in that situation)!


SPF is the cornerstone for fighting spam and email spoofing. It tells compliant recipient mail servers what constitute valid outgoing mail servers. It's ridiculously easy to set up, and, so long as you understand your mail flow, has basically no downsides. All you need is a validly formatted TXT message in your DNS. I think it's pretty much an unforgivable sin to not already have SPF records published - as restrictively as possible for your domain.


DKIM is how you can effectively get your email cryptographic ally signed, in effect "proving" the email came from you. Depending on the settings, it may also prevent the contents of the email being tampered with, but don't rely on this. It is very hard (but not impossible, given determined attackers and time) to fake, which makes it an excellent way of making fake and spoofed email hard to achieve successfully, and very time-consuming/difficult to forge - in other words, unless you're a very tempting target, attackers will move along.

A step beyond this are things like PGP and S/MIME, but we won't cover them here, as they are not easy to implement and are usually (very) poorly supported - they are quite useful if you are trying to securely report a serious CSIRT-type incident, or disclosure of a critical bug to a vendor; in South Africa, you might use or depending on your organisation; you may have to do some digging to find appropriate PGP keys. Given time, S/MIME might grow in use (but it's still tricky), but I suspect PGP will remain a fairly "niche" tool. See also: S/MIME and E2E.


DMARC is the "policy instrument" that allows you to tell compliant mail recipients about what constitutes valid email from your domain. A fantastic part of it is that it includes a reporting channel for remote MXs to tell you about what they're doing with your email (or, more accurately, email claiming to be from your domain(s)) - this will help you understand if your mailflow is not as expected, and what your users might be doing wrong -and of course, see that there are indeed naughty people [or, more likely, their botnets] faking emails from your domain.

If you use a 3rd party "spam engine" (aka mailing list services) that uses its own mailservers but under your domain name, you may wish to know how to protect that operation from failing to deliver mail, but that's an exercise left up to the reader - this may give you some hints. Usually, it's only your marketing department that does this; fundraisers and alumni newsletters can generate some impressive mail volumes. Separating "Critical Production" from "Generic Marketing" mail can be useful, and is recommended by most (at minimum, use separate email accounts for mass mail vs. mail-as-a-person - i.e. your marketing people should have at least 2 email addresses; this can also help with mail volume limits - which we have hit in the past for some users). Subdomains are a useful tool if you like to keep things under one single domain for branding/recognition, and provide useful separation of marketing emails and non-marketing "production" use of email - which can help to avoid some messages being marked as spam preventing less annoying (and more important) email from making it through. i.e. if you use the same system for marketing email, and recipients keep marking it as spam with large providers (like Gmail) your entire domain - and everything from it - are more likely to be considered "spammy". Whilst Gmail purposely don't give out much information about how their spam filtering works, I suspect separating out marketing mail onto a subdomain (or better yet, a different domain entirely) will help preserve the "deliverability" of important mail.

Google Suite makes it easy 

As usual, GSuite for Education (once called Google Apps for Education) is the busy school sysadmin's friend. They do all of this stuff "out of the box" - all you have to do is turn things on, publish DNS records, and test! If you've not already looked into it, set up a free dmarcian account (see below) to help you monitor your deployment. 



NB: Remember, if you have any other valid outgoing mailservers (like an onsite SMTP relay server), you'll need to include them in the SPF record, or mail from them will ultimately get denied.

Whilst there is a specific SPF RR in DNS, it seems to be mainly frowned upon, and you should use TXT records to implement SPF. Be as strict as you can with your SPF records.

Publish SPF records for registered domains that don't send email - this will help cut down on legitimate-seeming sources of spam/spoof mail.
v=spf1 -all 
does an elegant job of this.

If you're using Gmail, and the attacker does a convincing spoof of mail apparently from your domain through a compromised Gmail account (not necessarily within your domain), SPF alone will not help you, as what's valid for Gmail is also valid for GSuite as a whole. But if you've implemented all of the steps, emails should be appropriately flagged, or not even delivered (depending on your DMARC settings, and/or the recipient's mail filtering policies). 


You will of course also have to enter the corresponding keys into TXT records on the DNS servers for your domain. 

You should prefer the longest key length supported (2048 bits at the time of writing). 

You should note that best practices suggest you should periodically rotate keys (the justifications for this are similar to regularly changing SSL certs). A frequency of at least twice a year is recommended - more frequently if you're particularly worried, or suspect compromise to be likely. It may be operationally easier, however, to have a "key exchange week" once a year, where all possible compromisable keys across your organisation get replaced (e.g. SSL, WiFi, DKIM, etc).

Here's a brief post on how best to do that. Sadly, Google appears to make this quite challenging - I'm submitting a support request about this (and a Google Cloud Connect Feature Request). At the moment, you'd have to turn of DMARC, create a new key, wait for DNS to propagate, and turn it on again... Not ideal! For once, Microsoft makes it easier than Google - there is a feature suggestion in Google CloudConnect for something similar - i.e. automatic key rotation with no change of DNS records on your end. Clever!

You should be (well) aware that Moore's law, botnets, cloud services and similar reduce the time to crack keys each year - so if 512 bit was easily crackable in 2012 - with $75 worth of AWS time, 1024 is probably doable today, leaving 2048 as the bare minimum, unless you have a reason not to. As computing power increases, you have two choices - change a weaker key more often, or increase (typically, double) key length - and, usually, both.

Once this is all done, Google will start signing your outgoing emails. 

Make sure ALL of your outgoing emails go through Google's mail servers - very easy if your clients stick to Gmail web interface. Random devices that don't understand webmail can often be persuaded to use authenticated (and encrypted) mail submission via Gmail's mail submission servers - or you can create an onsite mail relay "gateway" server that does so on behalf of less well programmed devices.  You may have to wait a while for DNS to propagate the information; Gmail will only sign once it can see the requisite DNS information (for perhaps obvious reasons!). Nobody should be sending "naked" email over plain SMTP on port 25 - except mail servers between each other (you should block this outgoing on your border firewall to protect the internet against spammy malware inside your network, with an exemption for any mail servers that validly do so). 


I highly recommend using dmarcian - see below - to receive, process and understand the "back channel" communications from large providers receiving email supposedly from your domain. 

You should also be aware of the growing trend to spoof sub-domains. If you don't use sub-domains, use a catch-all DMARC record to reject any email from a subdomain (if you do, still have this as a catch all for fake sub-domains, but also publish sane policies for legitimate ones!). 

Our record is currently along the lines of:
v=DMARC1; p=quarantine; sp=reject; rua=mailto:<dmarcian@email.tld>
This tells recipient mailservers that yes, we use DMARC (version 1); that email that doesn't meet DMARC requirements should be quarantined (marked as spam) and that email from subdomains should be rejected (not even delivered - usually dropped at the SMTP layer) - because we don't currently use any subdomains - and even if we did, they don't send email.

This also submits the aggregate (rua = aggregate daily summary; ruf  = individual message level "forensic" reports) DMARC reports from 3rd party recipients of mail that claims to come from our domain to dmarcian for analysis - the XML reports are not exactly that useful on their own (unless you process them somehow- and it can be a LOT of messages), so using a 3rd party service like dmarcian to analyse them is an invaluable shortcut.

NB: you should start on p=none until you're sure legitimate email is unlikely to suffer - then escalate to quarantine, then reject (possibly at different percentages (pct=) in a "ramp up"; Google cover this in their step-by-step setup guide), and dmarcian will help you figure this out.

Consider stricter usage of adkim and aspf tags (default is quite relaxed) - but first understand what they do, and monitor effects!

While you're at it, read through the whole list of possible tags, and see if they might be valuable to you; not all are necessarily supported by all systems; find out if there are any limits before trying to implement one. 

Once you're sure that no legitimate email is going to be affected, strongly consider p=reject as that provides the most stringent protection.

Remain cautious, though, as mistakes here can kill your email dead. Short TTLs may be quite helpful until you're sure you've got things right..! 


dmarcian have a mission to help people deploy DMARC and encourage its adoption. They provide some wonderful basic services for free - and will really help you set DMARC up, and monitor its impact. You should probably follow Google's suggested "deployment ramp" (deploy slowly) which gives you time to pick up problems before you get crucified by irate users when "you broke email!!!!". Go register right now before you start implementing all of this. 

If you find their services really useful, you may want to throw them a subscription to thank them for their services (and perhaps to use more advanced features). 

Shout (kindly) at people who don't check this stuff. 

If you know of organisations that don't leverage these technologies (when checking incoming mail) to protect their users, ask them nicely to fix it, and point them at resources that will help them to do so. If you're such an organisation, think about how you can get "compliant".
It may be a simple matter of tweaking some settings in MTAs and/or spam filters, or it may require some plugins - it's usually quite easy.
Often, spam filters are not paranoid enough, and all too many forget to do basic sanity checks on incoming emails (and often don't implement basic spam mitigation techniques like insisting on valid (and matching) HELO, and PTR records for MX hosts, greylisting, and the like, let alone checking SPF, DKIM and DMARC. Make sure your outgoing mail meets these basic standards (it probably does if your email isn't mostly rejected as spam!). And if you process incoming email, have a look through your configs and make sure you're "up to date" on what decent mail filtering looks like in this day and age!

Encourage them, in turn, to also adopt the outgoing protections we've covered here. 

If you can think of ways that large vendors/service providers can help users stay safe, try to engage with them through suitable platforms. (Like why is the Gmail "golden key" labs widget or some similar thing not more widespread and attainable - and turned on by default?). 

Unfortunately, email is a behemoth upon which to undertake significant changes - people get really grumpy when email breaks, but they often don't quite understand that email *is* broken (at least in terms of the way most people want to be able to use it). The Internet standards bodies have agreed pretty much not to change SMTP itself, so it's up to the mail servers to implement additional checks and balances on top of SMTP - and it often falls to we sysadmins to implement them. Tell your friends to get with the programme!

Try not to BOFH end users (or contacts of your organisation) who fail, but spend some time showing them how next time, they can not loose their hard-earned cash (or reputations) to simple (or advanced!) scams. You may have to pound your head against the desk after they leave, but it's your duty to try

Further Reading

As always, it's worth reading up a bit about these technologies so you understand enough about them to be able to explain to management why you need them - and to chose the right settings for your organisation(s).
On balance, they're really vital to helping your recipient community receive trustworthy email from you, despite a few possible complications. 
It's interesting to note that some people rail against the fact that these break some "internet standards" - mainly people who use mailing lists, and usually those who were online before the mid 1990s. In my opinion, sometimes Internet Standards are broken (the evolution of RFCs somewhat proves this), and the move from the Internet from something that only people with Clue use to a commodity public service mean we may need to occasionally re-architect some parts of it - even if that breaks some stuff, there are usually work-arounds, which may include hiding legacy systems behind something a bit more... modern. The alternative to the general internet community is (arguably, and certainly in my opinion) worse. This has a brief discussion of the main salient points - and points towards fixes. For the most part, because some of the biggest email senders have adopted this stuff, most modern mailing software has already implemented this. It's nice that SMTP is super-open, particularly if you run a massive spam or scam operation... What hasn't often yet caught up is alerting in the email client - that typically requires some training to get people to check (and confirm) things manually - which usually means it doesn't get done... :/

Email forwarding may also break. Again, as a school, you should take a pretty dim view of people forwarding their official correspondence to a private inbox and corresponding from there. To me, this is therefore a non-problem, but YMMV, depending on what your users do, and your management/school governing body's stance on security vs allowing people to do what they want.

The other thing that vexes some people is that you can't just use any old SMTP server to send out your email once you're using these techniques - but security connecting back to your home MSA (usually Gmail SMTP servers when you've "gone Google") is a reasonable and justifiable compromise. No client software should be talking to MTAs on port 25 in 2017. They should also not be doing that un-encrypted and without logins, either. An in-house mail gateway will connect any ancient machines/software into Google; this is pretty easy to set up - we did it because of a few multi-function printer machines that refused to do modern email.

A few further thoughts

Show users and recipients what to expect and how to check validity; clicking on the down arrow next to the sender is one option, but I prefer the "show original" option, which is more explicit. 
Make sure mailed-by and signed-by match what you expect!
Get people used to looking for PASS and the expected (and precise!) domain under DKIM.
You may even want to teach advanced users how to understand mail headers. Your users should also know about these Gmail features.

Once you up your DMARC p= record to "quarantine", you can expect people to start getting things in the spam boxes that say this:
Quarantined mail notification banner from a message that failed DMARC
Consider telling people what they should do (typically, delete or report them to someone - preferably with full headers!). This will mean non-compliant mail should land up in spam folders. Monitor your own, ask power users to report theirs (particularly during roll out / ramp up), and of course, monitor any reports you may be getting through the rua= DMARC tag.

Note that p=reject fails silently - apart from any reports that you may have set up in your DMARC record; you do not typically want to go straight for that setting while "ramping up" DMARC.

You may want to alert people to "typosquatting" and related attacks, too! They can result in very effective spear-phishing attacks.  In fact, if you know of likely typosquats for your domain(s), you may want to register them and park them, perhaps with a suggestion of the site they're actually looking for. You may also want to register other available TLDs of your domain that your users might consider legitimate (com, org, edu, net, and relevant ccTLDs, etc - it may be cheaper to get people to understand that legitimate email only ever comes from @domain.tld - check the spelling, and don't use fonts (where you have a choice) that obscure differences between i/1/l or 0/O and so on - and there are also the joys of this attack!).
If you keep records of DNS lookups, you may even find what common typos your own users make for your domain name (missing and duplicated letters are popular) - which is a potentially rich source of things you might want to register! Of course, if you have a copy of Kali floating around, there's urlcrazy to make suggestions...

Consider a "secure" email subdomain or domain

This is an advanced topic that I'm not going to cover in much detail, but if the limitations of these technologies force you into adopting less strict SPF and DMARC records ("~all" in SPF and "none" or "quarantine" policies in DMARC), might you be able to use a "secure" subdomain for more sensitive information (or, vice versa, for less/insecure communication)?

That subdomain would use the strictest possible settings, whilst still allowing "general purpose" email accounts (like myemail@yourdomain.tld) to use forwarding and mailing lists, which are often the biggest casualties of these technologies. You might for example set up accounts@billing.yourdomain.tld, with appropriate records.

Or perhaps from a policy standpoint, your school's management team might consider that security (for once?) trumps convenience, and un-compliant mailing lists and email forwarding have no place in your school and you can deploy the strictest records possible (which is usually a good thing). 

Here's a crazy thought - abandon email entirely for sensitive information (and perhaps even general correspondence with parents). Instead, use a well secured, web-based school management information system to conduct all correspondence. If you've got lots of money, Engage might help you with this, but there are plenty of competitors, and you should take some considerable time investigating them and their "fit" with your budget and school. You may even consider EV SSL certs (but SSL certificates from a reasonable CA are vital; Digicert seems to offer a good balance between reputation and cost (and I've had good experiences with them), but SSL Shopper is handy for comparisons). Some schools have done this, particularly where privacy laws are particularly strong. Of course, you can also consider Let's Encrypt, but think carefully about the trust profile and if that's adequate for your purposes. SSL certificates can help with two things - end-to-end privacy, and some level of proof of identity (aka non-repudiation, if you think back to theory of AAA models). The latter is quite important. 

A bright, secure, shiny future...? 

Make sure your recipient community understands what is - and is not - likely to be a valid email from your organisation. This is a helpful start. Likewise, that your internal user community knows what is - and is not - likely to be trustworthy. 

"Complicated" families can break everything. Make sure the person - or persons - who actually pay the bill(s) receive the invoices directly from your accounts department, and they are not forwarded between parties out of your control - this makes it easy for nefarious people to intercept a genuine billing message (and/or compromise the intermediary user(s)), alter it, and send it on. Unless the end recipient is very canny, they may well accept the fact that the bank account has suddenly changed and pay the scammer. 

Try to have steps to prove that the email (or other contact details) you're sending to is valid - you may need to be a little difficult about accepting changes in email address, phone number and physical/postal address - and make sure you "vaccinate" those who enter and change such data as a regular part of their job. Think: How can I protect against social engineering in your database maintenance team and accounts people? 

Try to get your accounts department to track payments more "aggressively" (require proof of payments; set preferred payment dates to assist them in chasing down possible issues) - but without assuming legal/financial responsibility for 3rd party mistakes. Tell people if they don't toe the line, they stand to lose out. Consider a small discount for playing ball (which might be more of a "tax" on those who refuse to)!

Make it a formal policy that is well understood that your organisation will never just change business bank accounts - it will be widely publicised in long advance (>6 mo), through multiple channels. Another key defense is that whenever someone has concerns, they should contact the organisation concerned "out of band" - telephonically - for assistance/verification on a well known number if they have any doubts - they should also typically (for in-house users) not be scared to ask for your opinion/advice!

Now that your school's email is more secure, get a well earned treat of some kind. And then wait until the next vulnerability or work-around in email is announced, and some other "band aid" protocol is slapped on top of email. Apply the band aid!

Think about the limitations and possible compromises to these tools. 

What is the keystone of all these services? 

Is it secure? 

(A small hint to the latter: DNS, and the answer is usually "No" - unless you're using DNSSEC - which very few do. I'm hoping to pilot this soon (here's my post on securing recursion) and will relate our experiences when we get there). 

It's not paranoia if they're out to get you... and they are!

No comments:

Post a Comment