We all use email every day, but have you ever considered how it really works? Some kind of software is needed to create, and transfer the messages, for both parties.. This takes the form of dedicated mail servers, along with local client applications such as Outlook, or web-based client applications such as Gmail or Outlook for the web. Each of these applications “constructs” data packets in a specific format and puts them out on the network for delivery. As with a website request, a DNS lookup is needed to find out which system handles mail for the intended destination.. Once these details are found out by the mail program, it can connect to those machines and transmit the packets. Once a mail transfer program has received the message, there are a number of things it can do before delivering the message to the user’s mailbox.
What happens when the message is constructed? Just like a real letter, certain information is required for processing and delivery.. And, just like real paper and ink, literally anything can be put on the envelope.
This is where things get interesting.. Someone can construct a message that says it’s from someone, simply by using that information.. This is how spam is created, by forging various parts of the message.
As the problem has evolved, various mechanisms have been developed for mail transfer servers to check whether or not a message is valid. Since the internet is a vast and widely distributed system, it was decided to use DNS as a public database for these records. Domain owners can implement the features with the expectation that ‘conformant’ mail servers will use this information to validate messages, preventing ‘abuse’ in many forms.
The first solution to be developed was the ‘Sender Policy Framework’ (SPF) — this allows a domain owner to specify which IP addresses are allowed to send on behalf of the domain. A mail server can check the incoming message against these addresses and take action depending on the actual origins of the packets. This helps eliminate spam injection from ‘everywhere else’ on the internet.. But, because many IP addresses are shared within large service providers.. More granularity became necessary.
Second to be developed was “Domain Keys Identified Mail” (DKIM) — this method entails publishing a public key generated from the private key of the mail service. Mail servers can lookup this information to see if the message is signed by the server, informing its delivery decisions.
Even with the two mechanisms of SPF and DKIM, implementation gaps were present in the vast complexity of the internet.. A third mechanism was developed, called “Domain-based Message Authentication” (DMARC), which utilizes both SPF and DKIM, along with more features to validate that messages are actually from the specific sender and domain. DMARC also provides mechanisms for generating pass/fail delivery reports which can be used to see who or what might be trying to impersonate your domain.
With spam and phishing email listed as the number one threat vector these days, it’s critical to have all these security features in place and working.
Without properly configured MX, SPF, DKIM and DMARC records for your domain, any threat actor anywhere on the internet can ‘construct’ a message claiming it’s from you and your domain. (they call it “spoofing”) — If these DNS records are missing, mail servers have no way of validating any part of the message, and will simply deliver the spam or malware to the user’s inbox..
We always love to chat with people about these topics from cyber security, website hosting, app development, etc.. If you are interested lets have a coffee and discuss it together!
Check us out here
Photo Credits: Dan Nelson