It’s interesting to see how technology adoption cycles are repeating themselves for different technologies. One of such observations is how regular phone calls get through a security hardening similar to what email already got through. And the reason is exactly the same – spam. These days a lot of people employ some kind of calls blocker fundamentally similar to email spam filter. There’s a bunch of modern email essentials which is a must-have to avoid being marked as spam.
Security was an afterthought for many technologies which are now foundational – email included. I’d say it’s a clear sign of an organic growth, right between “make it work” and “make it right” stages. The last stage is “make it fast” and the whole saying is attributed to Kent Beck. And context is they key of course – those IT innovations grown in academic context. Building military or commercial stuff is unlikely to miss security from its non-functional requirements (NFR).
Anyways modern email has a few essentials under the hood which aim at reducing spam in your inbox greatly. It’s still pretty easy to miss these out on the sender side if you’re unaware. That was the case for a project which I got involved into. Despite using GSuite and SendGrid key email sender identification techniques weren’t employed. How so?
DomainKeys Identified Mail aka DKIM
DomainKeys Identified Mail (DKIM) is a technique of digitally signing outgoing email leveraging asymmetric cryptography. Since a picture is worth a thousand words here you go.
The public key is provided via TXT DNS record, usually the name looks like %KeySelector%._domainkey.%DomainName%. Recipient email server fetches the public key and validates the signature, provided in DKIM-Signature email header.
By leveraging digital signatures DKIM ensures that the message is from the intended source and that its content wasn’t tampered en route.
As DKIM requires changes to the sender’s domain DNS it’s not automatically enabled neither in GSuite, nor in SendGrid.
SPF from the List of Modern Email Essentials
Sender Policy Framework (SPF) is a method of specifying legit sender servers for a domain. Policy is set up as another TXT DNS record and provides pretty flexible syntax to specify which sender IP addresses should be considered valid and what to do if validation fails. The latter is typically either “soft” or “hard” fail meaning “more attention to this message, plz” and “ditch this message altogether” respectively.
For GSuite a typical SPF record looks like v=spf1 include:_spf.google.com ~all and that means:
- Version of the SPF is 1
- Use data from
_spf.google.comfor valid senders - Use soft fails
Querying _spf.google.com leads to _netblocksN.google.com records each of which resolves to a set of CIDR specifiers.
Again SPF requires DNS changes, so you won’t get it out of the box.
DMARC as the cherry on top of the cake
Domain-based Message Authentication, Reporting and Conformance (DMARC) is a policy you can specify for your domain. The policy instructs receivers on how to deal with non-legit messages from your domain. DMARC is based on DKIM and SPF but it hardens the check even further by requiring “From” domain to match the domain used in both. Again a picture here speaks for itself.
The point of DMARC is to enforce alignment between DKIM / SPF and “From” domain. “From” domain is what people actually look into. If it’s forged people may get hurt from fishing attacks. At the same time neither DKIM nor SPF on its own has nothing to do directly with “From” domain. DMARC requires that at least one of the checks to match “From” domain ensuring it’s legit.
Again DMARC is set up as TXT DNS record with name _dmarc.%DomainName%. The most basic DMARC policy looks like v=DMARC1;p=none; what specifies the version (v tag) and empty policy (p tag). Empty policy means “just do relaxed alignment checks but don’t reject or quarantine”. To get reports from receivers you’d like to add rua or ruf tags but at first you may just do some manual checks by sending a few messages across.
It’s a prudent move to roll out DMARC gradually: gather info via reporting first then start quarantine some failures. And only after a while if delivery seems to be fine start rejecting messages failing checks.
That’s it for Today on Modern Email Essentials!
Overall I think services like GMail or SendGrid should be more aggressive with aforementioned technologies. It’s up to integrations with DNS hosting services and more intensive communication to users.
As there’s some degree of sender identification built-in (just not exactly for your domain) you may be happily unaware. And from time to time you’d shake your head wondering why your messages ended up in spam/junk.
GLHF with modern email essentials!