DMARC Email Authentication Explained in Plain English

Posted by Trevagh Stankard on Thu, Mar 10th, 2022

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.

SPF and DKIM Integration

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.

DMARC Rules

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:

v=DMARC1\;p=none\;rua=mailto:admin@yourdomain.com\;ruf=mailto:admin@yourdomain.com\;pct=100

• The first part of a DMARC record indicates that DMARC should be applied. This is the “v=DMARC1” section of the record. This section should always be the first part of the rules because it triggers the email system to look further into the record to find DMARC rules.
• The “p=none” section tells the server what to do if DMARC records fail. In this example, the system does nothing with the email, but the administrator gets a report on messages that fail DMARC.  You can also set this value to “reject” to outright reject the email or “quarantine” to set it aside until an administrator can review it.
• The “rua=mailto:admin@yourdomain.com” rule tells the server where to send reports. Reports should go to an administrator to review any failures, especially if you have “p=none” configured. It will help administrators determine if malicious emails could be reaching user inboxes.

DMARC servers aggregate reports for forensics, and “ruf=mailto:admin@yourdomain.com” 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 incorporates DMARC authentication to provide even greater protection against email spoofing attacks. Take a look at the full SpamTitan feature set and discover how it works to protect your business from email threats. Book Free Demo

See SpamTitan, email security solution, in action - book a free instant demo