DMARC is a standard that seeks to improve the security of delivered email across the world. Admins will find that once configured, DMARC can help increase the security and delivery of future emails as well as protect their brands from malicious impersonations.
DMARC builds upon already existing email frameworks DKIM & SPF. These have been around for decades now and serve a similar purpose - increasing the integrity of email.
SPF stands for Sender Policy Framework. This technical standard works by creating a DNS entry in your domain that specifies the hostnames and/or IP addresses that are allowed to send email on behalf of your domain. Receiving email servers will perform a lookup of your domain to check for the existence of this SPF record when an email reporting to be from your domain arrives. It will then compare the names & IPs in the SPF record with the sender’s return path address to check if the sender is allowed to send email from this domain. If the sender’s return path domain falls under the list of approved senders, the lookup will result in a pass. If the domain is explicitly denied in the SPF record, it will fail. If the domain falls under a catch all category such as ~all, the lookup will soft fail. This means the email will still most likely be accepted but SPF will be marked as an SPF failure. The last potential result of this lookup is if there is a ? entry in the domain’s SPF record that matches the sender’s return path domain, the lookup will be marked neutral and be considered neither a pass nor a fail. Based on the results of this lookup, the receiving mail server decides if the email should be delivered or not. SPF when used alone can protect from impersonation emails but is best used when combined with DKIM & DMARC to further enhance the security & reputation of your organization’s domain.
While SPF records help tell the receiving email server whether or not an email should be accepted based off of a list of approved senders, DKIM seeks to provide a mechanism to verify that an email has not been tampered with after being sent. DomainKeys Identified Mail aka DKIM is another technical standard that builds upon SPF & SMTP by adding a method of email authentication. It works by using public cryptography & digital signatures to provide the receiving mail server a way to validate that an email has been received from an authorized email server & hasn’t been tampered with along the way. When DKIM is enabled & configured, a digital signature is inserted into the headers of each outgoing email by the sending email server. An IT admin will create a TXT DNS record for the domain DKIM is to be configured on that contains a public cryptographic key. When an email is received that contains a DKIM signature, the receiving mail server queries the DKIM DNS record for the public encryption key. The key is then used to decrypt the signature in the email headers & compare the results to a newly calculated hash performed by the receiving email server. If the two values match, it can be validated that the message has not been altered and truly came from the sender’s domain.
Domain-based Message Authentication, Reporting, and Conformance or DMARC, is the final piece of the package that combines both SPF & DKIM to provide instructions to receiving mail servers on how to handle incoming emails as well as reporting insights to IT admins on how an org’s email is being handled. The setup is similar to SPF & DKIM. IT admins create a DMARC policy outlining how receiving servers should handle emails that may violate the policy. The policy is then published as a DNS record on the organization’s domain. This DMARC policy will tell receiving mail servers what action to perform on email that violates either SPF or DKIM checks.
An email is considered violating a DMARC policy if it fails what is called domain alignment. DMARC checks for SPF & DKIM alignment on a sender’s domain. If an email’s from domain and its return-path domain do not match, the SPF alignment is considered a fail. If the messages DKIM from domain and its DKIM d= domain do not match, DKIM alignment is considered a fail. IT admins can adjust the sensitivity of these alignment checks in the creation of the DMARC policy to allow a relaxed or strict alignment. In a relaxed alignment, the domains match but may have non matching subdomains. In a strict alignment, the entire domain must match.
A DMARC policy can instruct a mail server to perform one of several actions on messages that may not meet alignment including “none”, “quarantine”, and “reject”. None tells the receiving server to perform no action on SPF & DKIM alignment checks that may fail. This is useful in the beginning assessment stages of implementing DMARC as IT admins will want to see what services are currently sending email on behalf of an org’s domain before implementing tighter restrictions. Quarantine tells the receiving server to accept the email but place it in either an email quarantine or the user’s spam folder, the latter decided by the receiving mail server’s settings. Reject tells the server to drop the email message entirely. This means the end user or recipients of the message never receive the email.
A DMARC policy also tells receiving mail servers to send back a report of the validation process to specified email addresses configured in the policy. IT admins can choose whether or not to receive these emails and who should receive them. This provides valuable insight into what services may be sending email on the org’s behalf. There are legitimate reasons why a 3rd party service may be sending email purporting to be from an org’s domain. One of the most common reasons is marketing/sales software that sends through a 3rd party’s email servers like Mailchimp or Salesforce that spoof an org’s domain in order to provide a better branding experience for the recipient. Before implementing a quarantine or reject DMARC policy, IT admins should review these reports and implement SPF & DKIM records for all legitimate services that may be sending email on behalf of the org.
DMARC helps increase the security & integrity of your organization’s email but can also help protect your brand. Without DMARC, SPF, & DKIM, an attacker can easily send email pretending to be from your domain to potential clients/customers or even staff members. Industries dealing with large financial transactions are especially vulnerable to this. Even if the recipient of a spoofed email does not fall for the attacker’s tricks, the damage to your company name and brand has been done. They may consider future legitimate emails from your company to be potential spam or get the impression that your organization does not take email security seriously. Implement DMARC, DKIM, & SPF today to better protect your organization from emerging threats!