Our email communication system is almost as old as the Internet itself, with the original email protocols being some of the first proposed in the 1960s and finally agreed upon in the early 1980s – yep, that's correct – the basis of our Email system is some 40+ years old.
The Internet of the 1980s was a VERY different environment from today. Trust was implied. Everyone knew everyone or had a contact who did. Email was trusted as no one had any reason not to. Messages were transferred in plain text – essentially, anyone could read any message that passed through your server – whether you were the intended recipient or not – and this was an accepted state of affairs.
Times have moved on – the Internet is no longer primarily a domain of academia where trust and openness are implicit. Today, the commercial world relies on the Internet, where trust must be explicitly granted and accepted between parties. Unfortunately, despite some improvements, our 1980s email protocols have fundamentally not kept pace with these expectations. Messages (by default) are still primarily transmitted in plain text, and email servers are free to transmit using whatever account names (and domains) they choose. A situation that is not ideal and not aligned between business needs and technical offerings.
Bridging this gap is a raft of add-ons providing publicly accessible "governance statements." These define which servers are explicitly authorised to send email for a domain, whether such emails are to be encrypted (and by what method), and what should be done with any messages that don't have the published governance statements. Together, these are the horrible acronyms of SPF, DKIM, MTA-STS and DMARC.
Our reprobate acronyms each have a specific role in providing certainty about the source and identity of individual email messages. I.e., they attest to the reputation of an email message at the receiving server.
The most publicly accessible (read configurable, distributed, and hopefully secure) location that MUST exist for each email domain is DNS – without DNS, nothing on the Internet is easily accessible (a story for another day), or in most cases, doesn't work – so the majority of the add-ons to our ageing email system to improve its security and trust-ability rely on DNS.
SPF – Sender Policy Framework. This record defines WHO (which server/IP Address) is authorised to transmit email messages onto the Internet for the domain. The complication is that most organisations are likely using multiple SaaS platforms, each with its own suggested SPF configuration, and there is a HARD limit on how long an SPF string can be and how many entries it can contain. If you get this string wrong, the outbound email WILL stop! Optimising an SPF record for a mid-sized organisation is more of an art form than a tech challenge. It is often best left to specialist tools that can delve into many records and condense them based on DNS lookups, aliases and other magic.
DKIM – DomainKeys Identified Mail. Working hand in glove with SPF, DKIM provides a cryptographic signing service that allows a receiving server to positively validate that an authorised server sent the message and that the message content has not been altered in transit. Note that this service does NOT encrypt or otherwise protect the message; it simply validates that it arrived with the same content as was sent.
MTA-STS – Mail Transfer Agent – Strict Transport Security. The gap filler. The Man-In-The-Middle threat remover. This is the one that REALLY changes the game on the security risk around in-transit email. The original email protocols had an in-transit encryption option added in the late 1990s. Unfortunately, this was an OPTIONAL component that, whilst widely supported, could be easily disabled by a threat actor using a Man-In-the-Middle attack, as there was no way for the receiving server to know whether an incoming message should be protected by encryption. MTA-STS addresses this by publishing a policy statement governing the location and use of cryptographic certificates to encrypt and decrypt in-transit messages. Please note that this DOES NOT cover messages AT REST on a server – these are still likely to be in plain text and viewable by a server admin (you can fix this using client-side encryption such as PGP or s/MIME). Most major email providers (Microsoft, Google and Yahoo now support MTA-STS by default).
DMARC - Domain-based Message Authentication Reporting and Conformance. The BOSS. DMARC is the policy that governs the alignment of SPF and DKIM and provides instructions for receiving mail services on handling non-compliant emails. Sounds straightforward and simple – not quite! Getting a setting wrong in SPF or DKIM whilst DMARC is set to REJECT will result in the non-delivery of email and no way of recovering the messages. DMARC also specifies a reporting structure that gives a receiving email server a location to report statistics and exceptions. These reports provide a treasure trove of information about the legitimate email on a domain as well as early warnings for potential threat actions against your email reputation.
Often, the largest sender of correspondence from a business email domain will be the marketing team using an eDM management tool such as MailChimp or CRM such as Salesforce or HubSpot. Ensuring reliable delivery of email is paramount for this business function. As such, reputation management will often be left with the marketing team to manage – I am NOT a fan of this approach!
Knowing and controlling who is authorised to represent an Organisation should be an essential function of your IT Security team (and if you don't have an internal one, your MSP) – why? For starters, they will have a more holistic understanding of what platforms are in use, which teams are using them and the configuration requirements (it is quite likely that there are finance and operational systems also based on SaaS platforms). Additionally, the review of incoming reports, adjustment of settings, and investigation into potential email threats are NOT part of a marketing role.
Microsolve offers a fully managed email reputation service – from an initial review of your environment through to ongoing reporting and planning for new system deployments – we can simplify all of the above into a single shout-out - "please just fix it!"