Email protocols and the system that allows us to communicate with electronic messaging have been around for decades. The original system built in the 1970s wasn’t created with spoofing and phishing in mind. Weak communication protocols between sender and receiver have led to numerous critical data breaches from email-based attacks. The success of attacks stems from the way email protocols work, but businesses can protect themselves using DMARC policies set up as DNS entries.
Communication using email mainly relies on Simple Mail Transfer Protocol (SMTP). Servers hosting email protocols like SMTP receive instructions from an email client that include the sender, recipient, subject, and body of a message. The user’s email client software automatically fills in the sender address to avoid typos, but SMTP allows you to manually set any sender address you want. To stop spam, many SMTP servers require authentication now, which stops anyone on the internet from using email servers to send out spam. Email administrators may intentionally or unintentionally misconfigure SMTP, allowing unauthenticated access. Malicious SMTP servers enable anyone to use them for spamming, phishing, and malware injection.
SMTP and the email system works in a way that allows malicious users to spoof anyone’s identity. A malicious user can send a message to your accounting department as invoices@microsoft.com or send messages to your database administrator as ceo@yourcompany.com. This problem encourages monetary theft, business email compromise (BEC), phishing, social engineering, malware injection, ransomware, and many other attacks originating from email messages.
You might wonder how a spoofed sender such as ceo@yourcompany.com gets a reply from the user since your email client often adds the sender address to the recipient field when replying. Another configuration set during email communications is the “reply-to” address. For example, a malicious user might set the sender address as ceo@yourcompany.com but configure the reply-to address as attacker@gmail.com. When users click “Reply” in their email client, the recipient address is automatically sent to the attacker’s email address (in this example attacker@gmail.com) so that the reply is received. Note that when no reply-to address is configured, the sender’s address is used as a default in the email client application. Users don’t usually check the recipient address, because they assume the message will go to the original sender.
Administrators fight a constant battle with email-based attacks, which is ameliorated but not eliminated by employee security awareness training.. To combat email-based threats, administrators can turn to DMARC (Domain-based Message Authentication, Reporting and Conformance). DMARC has two components, and both the sending and the recipient email servers must be configured to support DMARC. The sending email server uses configured security components when sending messages, and the recipient email server must check for spoofed messages and act accordingly, which means that the recipient server could quarantine flagged messages, send them to an alternative address (e.g., to an administrator), or drop them entirely. Whatever action you configure the email server to take is much better than leaving the detection of email-based threats to employees, who are your weakest link in your security posture.
The first and easiest DMARC component for administrators to configure is a Sender Policy Framework (SPF) record set on a DNS server. Whether you host your own DNS server or use one in the cloud, you should have the ability to edit DNS records. When you set up a domain to point to your web server, you create a DNS A record. An SPF record is a TXT record. It’s important that you set the right type for your DNS records to avoid any interruptions with web or email traffic.
As discussed, an email sender can use any address, including sender addresses for other people. When a sender connects to an SMTP server, the SMTP server logs the IP address of the sender and includes it in the email’s header. This IP address is important when tracking the originator for a message. The recipient can view email message headers to determine the original IP address of the sender, but recipient email servers use IP addresses stored in email headers to validate authenticity.
An SPF record tells the recipient server that valid email messages for a domain are sent from only specified IP addresses. All other sender IP addresses should be flagged as possible spoofing. Adding an SPF record to your DNS server lets the recipient server identify possible phishing and other email-based threats.
SPF records are TXT DNS entries, so an example looks like:
v=spf1 ip4:192.168.0.22 include:marketingmail.com ~all
To break down the SPF record, here is what each component means:
You might have multiple sender IP addresses, so you can use the following format:
v=spf1 ip4:192.168.0.22 ip4:192.168.0.50 include:marketingmail.com ~all
You must follow the right format for an SPF record, or messages sent from your domain could be flagged as spam. Some servers might drop your messages altogether, so test your SPF records after configuring them. For more information about proper format of an SPF record, check out Microsoft’s DMARC documentation.
DomainKeys Identified Mail (DKIM) is another email security component that validates message authenticity. Administrators configure DKIM on a DNS server, but it’s more complicated than an SPF record. Note that you can use only SPF for basic email security, but businesses should take the time to configure DKIM to protect customers from phishing attacks. Using DKIM, the recipient server can validate that messages weren't changed.
When email messages travel over the internet, it’s possible for malicious users to intercept messages, alter them, and then send them along to the recipient. With DKIM, the altered message would be detected using validation of the digital signature. The digital signature is built from components in an email, so any tampered messages would result in an altered signature and failed validation.
DKIM uses asymmetric encryption, or what’s also called private-public key cryptography. A valid sender uses a private key to create the digital signature, and the public key stored on the sender’s DNS server validates the signature. The original message contains information indicating the text used to create the signature, including a hashed version of the email body. Recipient servers use the DNS-hosted public key to recreate the encrypted signature and compare output with the original message signature. If the signature matches the one stored in the original message, then the email passes. If not, the message fails DKIM validation.
A DKIM record looks like the following example:
(Name) myselector._domainkey.yourdomain.com
(String Value) v=DKIM1; p=15T514G15W830EF276853253EEC3F5ADE69A2362BECE40658267AB2FC3CB6CBE
The DNS entry for DKIM has two parts: the name and the value. Like the SPF entry, the DNS DKIM entry is a TXT record. Information about the DKIM record is stored in the message header when the originating email server relays it to the recipient. Recipient servers use the stored information to validate the digital signature along with the public key stored on the DNS server.
DKIM records have a name, and the name follows a specific template. The myselector component in this example is a value assigned by the sender’s email server. The server’s administrator sets this value, and it’s included in the message headers. In this example, the sender selector value is myselector. The _domainkey.yourdomain.com value is always appended to the selector.
The string value indicates that the TXT record is a DKIM entry, and the alphanumeric value for the p variable is the public key used for signature validation. The public key is used to encrypt and validate information stored in a message’s header section allocated for DKIM information. If the result matches the signature created from the sender’s private key, then the recipient server knows that the message wasn’t tampered with. If even a single character changes in a message, validation from the public key will fail.
With the SPF and DKIM records set up, you now need to specify what email servers must do when a message fails either SPF or DKIM validation. Should a message fail, the DMARC policy tells the recipient to quarantine or drop a message. You can also instruct the server to do nothing, but this option leaves recipients open to phishing and other email-based threats using your domain address.
A DMARC policy’s instructions usually depend on the business. For example, if you manage email servers for a bank, it might be best to drop failed messages to stop phishing attempts. Sites that don’t deal with financial information or sensitive customer data might allow a soft fail where the message goes to a spambox instead of being dropped entirely. Most policies tell email servers to quarantine suspicious messages so that administrators can later review them. Quarantined messages can also be shared with cybersecurity researchers for companies contributing to threat intelligence.
Like the SPF and DKIM entries, a DMARC policy is also a TXT DNS entry. Here is an example of a DMARC entry:
v=DMARC1; p=quarantine; adkim=s; aspf=s;
Note that the adkim and aspf parameters are optional. The important sections are the v parameter, telling the system that this entry is the DMARC policy, and the p parameter, which tells the system what to do with failed messages.
In this example, the DMARC policy instructs the recipient server to quarantine messages. Quarantining messages has several benefits. It contributes to catching zero-day threats, and it gives administrators the ability to review messages. Email security systems with cloud quarantines share their findings with cybersecurity threat intelligence agencies to find zero-day threats. Administrators can review quarantined messages for common threat techniques to alert employees of ongoing attacks, and they have the opportunity to flag messages as false positives to pass along legitimate messages to the recipient instead of losing them.
The p parameter can be set to none, quarantine, or reject. Using none, lets anything pass, and reject tells the server to drop suspicious messages. You might think that the reject option is the best one, but false positives are possible. Any false positives would be dropped with no chance for administrators to troubleshoot and review their email server settings. Administrators would need to manually add any senders that should bypass DMARC policies to their Allow list, which can be tedious and unnecessary overhead.
In this example, the adkim parameter is set to “s” or strict. A strict setting tells the recipient server to fail any messages where DKIM fails. Failed messages in the above DMARC policy will be quarantined, but you can also set a relaxed (“r” value) action. With a relaxed DKIM failure, messages can be sent to specific email recipients. For example, if you have a DKIM domain set to mail.yourcompany.com and mail is sent from yourcompany.com, the root will fail DKIM validation. To send failed messages to specific email addresses with a relaxed DKIM policy, use the following example:
v=DMARC1; p=quarantine; adkim=r; aspf=s; rua=mailto:report@yourcompany.com; ruf:mailto:dmarcfailed@yourcompany.com
The same configuration can be done with the aspf parameter. You can also set this to “r” for relaxed. The same parameters can be set for optional email addresses to send failed messages.
DMARC has several other optional parameters, but the only two required parameters are v (version) and p, which tells the recipient server what to do with messages. All other parameters can be excluded, and you still have a valid DMARC policy. Several RFCs explain optional parameters for DMARC, so you can specialize a policy for your unique scenarios.
Most threats start with an email message. Spoofed messages, phishing, and messages with malware attachments require only one employee to fall for the attack to threaten the security of your systems and data. It’s common for businesses to train employees to detect malicious messages, but human error is a huge contributor to data breaches.
Using DMARC, you can add effective security measures to incoming and outgoing messages. Adding email security to your infrastructure protects your employees, your customers, and adds to the security of the overall internet.
Last month, NIST published its first set of post-quantum cryptography (PQC) standards, setting a new benchmark for enterprises, government agencies, and vendors to withstand future cyberattacks from quantum computers. The time to start transitioning is now. Discover what’s at stake with CyberWatch.
Hospitals and healthcare providers have increasingly become targets of cyberattacks, which pose significant risks to patient care and safety. This document examines the various ways in which cyberattacks can disrupt hospital operations, compromise patient data security, and ultimately affect the quality of patient care. It also explores strategies and best practices that hospitals can implement to mitigate these risks and enhance their cybersecurity posture.
Ethical hacking has become an essential response to an IT industry kept on its toes by a spectrum of bad actors with malicious intent. This article introduces two prominent methodologies that help the good guys fight back: penetration testing (pen-testing) and red teaming. Learn more here.
Host Geoff Hancock was joined by guests Mike Rush, Director of Threat Intelligence at Access Point Consulting; and Evie Manning, Senior Director of Threat Hunting and Intelligence at Access Point Consulting. Together, they talked about cyber threat intelligence and the applications that can make it work for small and medium-sized businesses.
