blog

From SPF to DKIM to DMARC: Building a Robust Email Defense

Written by Nick Wages | 5/17/24 7:47 PM

Building on the foundation of SPF and DKIM, DMARC (Domain-based Message Authentication, Reporting, and Conformance) provides the final piece of the puzzle for a robust email authentication strategy. DMARC not only validates emails through SPF and DKIM but also gives domain owners the power to instruct receiving servers on how to handle emails that fail these checks. This article will delve into what DMARC is, how it works, and the critical role it plays in safeguarding your email communications.

What is DMARC?

DMARC acts as a policy layer over SPF and DKIM, ensuring that emails passing through your domain are properly authenticated. By setting up a DMARC record, you can specify what actions should be taken when an email fails SPF and DKIM checks, such as quarantining, rejecting, or accepting the email. Additionally, DMARC provides reporting features that help you understand who is sending emails on behalf of your domain and how often they pass or fail authentication.

DMARC Steps

DMARC builds on SPF and DKIM by adding a policy layer and providing reports. Here is a simplified breakdown of how it works:

  1. Define policy: You set up a DMARC record in your public DNS, specifying how failed message should be handled, and where to send reports of sent messages.
  2. Align SPF and DKIM: For DMARC to pass, both the SPF and DKIM checks must align with the domain in the "From" address.
  3. Receive Reports: DMARC generates aggregate and forensic reports that provide insights into email traffic and authentication results.

Understanding the DMARC Record

Like SPF and DKIM, DMARC is configured using a public DNS TXT record. Let's break down the components. Trouble sleeping? Check out the definitions here.

Common Components

Example record: v=DMARC1; p=reject; rua=dmarc@example.com; ruf=dmarc@example.com

  1. v=DMARC1 – Specifies the DMARC version
  2. p= – Policy for handling emails that fail DMARC checks (none, quarantine, reject)
  3. pct= – Percentage of messages subjected to filtering (100% if omitted)
  4. rua= – Email address to send the aggregate reports
  5. ruf= – Email address to send forensic reports

Uncommon Components

  1. sp= – Policy for subdomains (none, quarantine, reject)
  2. adkim= – DKIM alignment mode (strict 's', relaxed 'r')
  3. aspf= – SPF alignment mode (strict 's', relaxed 'r')
  4. fo= – Forensic options for reporting failures
  5. rf= – Reporting format for forensic reports
  6. ri= - Interval for aggregate report generation

Setting up DMARC

Now that we have defined the components of DMARC we need to create a TXT record in our public DNS with the components we want to use. Below is an example of the most simple record.

Name: _dmarc
Value: v=DMARC1; p=reject

  1. Create Your DMARC Record
    • Select the components you want to use and create your DMARC value.
    • If you are able, create a shared mailbox or distribution list called "dmarc@YourDomain.com" to receive and investigate DMARC reports.
    • We recommend at least the following when getting started:
      v=DMARC1; p=none; rua=YourEmail@YourDomain.com; ruf=YourEmail@YourDomain.com
  1. Publish and Test Your DMARC Record
    • Publish your record with your public DNS provider (Network Solutions, GoDaddy, etc.).
    • Validate your record using MXToolbox's DMARC check tool. It may take 5-10 minutes for new records to become available.
  2. Monitor and Adjust
    • This is a great way to understand if there are other systems spoofing your domain or discover other systems you may not be aware of sending email on your behalf.
    • Start with the policy "none" and ensure you set your rua and ruf components so that you receive reports.
    • Analyze the aggregate reports (sent daily) and forensic reports (sent immediately) to understand your email traffic and make adjustments.
  3. Gradually Enforce Policies
    • Try to move off of the policy of "none" as soon as you are comfortable with your results.
    • Based on information from the reports, move to a more strict policy such as "quarantine" or "reject".
    • A policy of "reject" is the most secure option, any incoming spoofed email that fails the DMARC check will be rejected by the receiving email system.

 

Setting the DMARC policy (p=) is critical for email security. Setting it to "none" will cause modern email systems to flag your emails as spam or junk. It is essential to use "quarantine" or "reject" to ensure your emails are properly handled and trusted.

 

Failure Scenarios

Scenario: The Phishing Attempt

  • Alice, a security-conscious business owner, has configured DMARC for her company with the "reject" policy.
  • A malicious actor tries to send one of Alice's customers a phishing email by spoofing Alice's domain.
  • The customer's email system rejects the malicious message because it fails the DMARC check for Alice's domain.

Scenario: Discovery of Unauthorized Email Sources

  • Jane sends an email from a new Point of Sale system, but it isn't listed in the company's SPF record.
  • The email fails SPF check and is quarantined by the receiving email system due to the DMARC policy.
  • John receives a DMARC report and discovers the unauthorized email source.
  • John and Jane work together to update the SPF record to include the new email service.
  • Future emails from Jane are successfully authenticated and delivered.

Scenario: DKIM Failure and Resolution

  • Tom sends a marketing email using a third-party service that applies its own DKIM signature.
  • The email's DKIM signature does not match the public key of the company's domain.
  • The email fails the DKIM check and, based on the DMARC policy is rejected by the receiving email system.
  • Emma receives a DMARC report indicating the DKIM failure.
  • They identify the misconfiguration and update the DNS records with the correct public key for the third-party service.
  • Future emails from the marketing email system are successfully delivered, ensuring the integrity of the company's emails.

Troubleshooting DMARC

Implementing DMARC can sometimes lead to issues that need troubleshooting. These issues can be disruptive to your organization, depending on the DMARC policy you initially selected. Here are some common problems with DMARC.

  1. Misconfigured DNS Records – Incorrectly configured or formatted DMARC, SPF, or DKIM records. Ensure that the syntax for these records are correct with free external tools like MXToolbox.
  2. Email Failing Authentication – Legitimate emails failing SPF or DKIM checks. Ensure all sending sources are included in your SPF record and that DKIM signatures are being properly applied. Send yourself a  test email and check the email headers using MXToolbox or Microsoft's header analyzer.
  3. DMARC Reports Not Received – Not receiving the aggregate or forensic reports from DMARC. Ensure that the "rua" and "ruf" components are set to a valid email address and capable of receiving a large volume of reports.
  4. High Rate of Rejected Emails – A significant number of emails are being rejected. Try starting with a DMARC policy of "none" and monitor reports before moving to "quarantine" or "reject".

Depending on the complexity of your email environment the troubleshooting process can by very simple or very complex. We've included a graphic below to assist in the troubleshooting process. Remember, you can always reach out to us for a free consultation to talk through issues. 

Still Stuck?

 

 

 

 
View full post