Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a critical component of email cybersecurity that greatly reduces an attacker’s ability to get phishing and spoofed email to an end user’s inbox. It’s used by free platforms such as Gmail, and it’s also available in some corporate email filtering cybersecurity solutions. It’s important to understand the way DMARC is set up so that it can be properly implemented. With DMARC an organization can protect from phishing emails, which are increasingly used to add malware to a network or access security credentials.
DMARC isn’t just one cybersecurity component. It’s a collaboration of several rules that together determine if an email message reaches a user’s inbox. The email administrator determines these sets of rules, but the two main components for inbox filtering is Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). DNS records are also used to determine if an email server is registered and authorized to send email for the organization.
SPF is a DNS TXT record that indicates the authorized email servers that can send an email on your domain’s behalf. When a recipient email server receives a message with DMARC rules enabled, it looks for the SPF record first. This DNS TXT record should have IP addresses or hostnames registered to send mail. This could be only on-premise email servers or third-party servers such as those used with Google Suite for businesses.
DKIM is a little more involved than SPF. DKIM also requires a TXT record, but this record is the domain’s public key. DKIM implements asymmetric public-private key encryption. With public-private key encryption, a domain’s public key is used to encrypt a message. In the case of DMARC, a signature is encrypted with the public key published on DNS servers and verified at the recipient’s email server using the domain’s private key. Private keys should be protected because an attacker with your private key can decrypt any messages sent using your public key.
When an inbound server receives a message with DKIM, it compares the signature using the published public key with the message decrypted using a newly generated key. If the string result is the same, then the recipient’s email server can confirm that the message was not altered in any way. This also ensures that the sender is truly from the listed domain and not spoofed using a fraudulent sender address.
With SPF and DKIM integrated, the administrator can now set up DMARC rules. DMARC rules are also set in DNS. It tells recipient servers to implement DMARC. If no DMARC record is found, then it’s skipped entirely leaving your domain open to spoofing.
The following is an example DMARC TXT record:
DMARC servers aggregate reports for forensics, and “ruf=mailto:firstname.lastname@example.org” is the rule that tells the server where to send these reports. These reports are real-time, so they are always available for administrator review.
Most administrators don’t realize the amount of email that gets sent on behalf of the domain, so the “pct=100” rule sets a percentage of emails that will have DMARC rules applied. In this example, 100% of emails will be verified against DMARC rules. This is the typical value, but you might want to lower the percentage if you are testing your new rules especially with the “p=none” value.
DMARC seems complex, but with the right setup, it’s a valuable cybersecurity tool that defends against phishing and malicious email content. With phishing on the rise as one of the most common ways attackers can steal data, it’s important for organizations to implement the right application and rules that stop these messages before they can reach a user’s inbox.
While SPF provides a certain degree of protection against email spoofing, DMARC is far more dependable. SpamTitan email security now incorporates DMARC authentication to provide even greater protection against email spoofing attacks. Both of these new features have been added in the latest update to SpamTitan and are available to users at no extra cost.
Sign-up for email updates...