DMARC Deployment Guide

Understanding DMARC

What is DMARC?

DMARC is an email authentication protocol. It builds on the SPF and DKIM protocols. DMARC adds a reporting function that allows senders and receivers to improve as well as monitor protection from fraudulent email for a particular domain.

Domains that participate in DMARC, publish a DMARC policy using DNS records. In doing so, the policy becomes public and allows everyone on the Internet to apply the policy when receiving an email from that domain.

DMARC was designed to be rolled out in gradual steps by starting with a simple monitoring policy and ramping up to rejecting messages. Organizations are also able to request that any given DMARC policy be applied only to a percentage of the messages arriving at the receiving system. Together these two capabilities allow organizations of any size to quickly make steady progress on deploying DMARC, while remaining in control.

Since DMARC builds on top of SPF and DKIM, failing to roll out one of the underlying protocols, reduces the effectiveness of email protection overall. It’s therefore recommended that all three be rolled out, allowing for full coverage.

What DMARC does??

DMARC is built on top of SPF and DKIM. DMARC compliant implementations should complete SPF and DKIM checks prior to performing the final DMARC evaluation. It’s therefore important to understand what SPF and DKIM do before looking at DMARC itself.

What DMARC doesn't do?

DMARC is designed to significantly impact the ability of attackers to spoof the actual domains used by an organization. By removing this opportunity, attackers are forced to seek alternatives. In doing so attackers, expose themselves to a far higher risk of being filtered by receiving systems.

Details of DMARC

For reference we can use a simplified set of sample email headers as the example in the following sections:

• Sender Policy Framework (SPF)

• DomainKeys Identified Mail (DKIM)

• Domain-based Message Authentication, Reporting & Conformance (DMARC)

Sender Policy Framework

SPF is a mechanism that allows an organization to publish DNS records detailing which IP’s are authorized for a domain to send an email. During the SPF checks on a receiving system, the domain originally used by the sender in the MAILFROM or EHLO commands is used to lookup SPF policies. These domains are recorded by the first SMTP server in the Return-Path: or Received: headers, making them available to all servers.

When a malicious actor is involved, the actor has control over the set of SPF policies which are checked. This is done by choosing to use a MAILFROM and/or EHLO domain that they control.

With a published DMARC record in place, additional checks are completed on top of SPF, to detect such practices. So this actually works to the advantage of the domain owner rather than the attacker.

DomainKeys Identified Mail

DKIM is a mechanism that allows an organization to cryptographically sign a message. During DKIM checks on a receiving system, the domain used to sign the message, is used to lookup the public key of the domain via DNS and verify that the signature is still valid.

While an invalid DKIM signature can be used as a signal for spam detection, DKIM itself is unable to instruct receivers how to respond, if a message fails DKIM checks. Messages may become invalid for a number of reasons, some of them legitimate:

• Re-encoding is necessary for delivery

• National code page to/from UTF-8

• Base64 to/from Quoted-Printable

• MIME normalization/manipulation

• Signed headers or content must be changed

• appending a compliance footer upstream from delivery

• antivirus gateway

• DLP policies resulting in content quarantine

As with SPF, a malicious actor can also influence the DKIM checks by choosing the domain they use to sign the message.

Just like with SPF, DMARC also implements additional checks on top of DKIM to detect such activity.

Domain-based Message Authentication, Reporting & Conformance

DMARC is a mechanism that allows an organization to request that all participants in DMARC process all messages for their domain according to DMARC rules. These rules allow the domain owner to select which policy to apply and to what percentage of arriving email. It also permits requesting DMARC reports to be sent to the domain owner so that DMARC conformance for all mail flows, can be monitored.

When completing DMARC checks, the domain used in From: header is used to lookup DMARC policies for that domain from DNS. Once the results from the earlier SPF and DKIM evaluations are available, the receiver then performs the final DMARC checks.

These checks verify if the message passed SPF or DKIM. If the message passed one or two of those checks, the successful checks will then be verified to see if the domains used in those checks match the DMARC domain present in the From: header.

It’s this final check that effectively prevents SPF and DKIM abuse by attackers, and stops them from using a From: domain that matches a DMARC protected domain.

DMARC policies

Compliant DMARC implementations can choose from three policies:

• None (p=none) - the domain owner asks that receivers take no action regarding delivery of messages based on DMARC evaluation. This policy facilitates discovery of mail flows without having DMARC decisions applied to the messages.

• Quarantine (p=quarantine) - the domain owner asks that messages that fail DMARC checks be treated as suspicious. Depending on capabilities of the email receiver, this could mean delivering the message to the spam folder, subjecting the message to stringent spam checks, or alternate methods of flagging the message as suspicious to the end user.

• Reject (p=reject) - the domain owner requests that messages that do not pass DMARC be rejected during the SMTP transaction.

Rollout Plan

Prerequisites

Partner assistance

Get DNS access for your domains

Determine a DMARC processing tool

Determine scope of the domains

DMARC Discovery

Intro

Enabled DMARC in monitoring mode

Updated DMARC DNS Record for Monitoring mode

Send to Analysis tool

Configure SPF Record

Existing SPF records should include

            Google IPS

            Outbound Gateways

If you don’t have have SPF records, start with neutral SPF disposition

Move to softfail once initial wave of reporting stabilizes

Configure DKIM

Create DKIM

Configured outbound gateways to send through G Suite

DMARC Quarantine

Intro (meaning of quarantine)

Enable DMARC Quarantine

Do a gradual rollout

Rollout ramp of 1,5,10,25,50,100

Continue monitoring and fixing SPF/DKIM as per DMARC reporting

Deployment Timelines

Under ideal business conditions DMARC deployments take approximately thirty days to complete.

Thirty days is a tradeoff between the need to move cautiously and the need to deploy quickly so the project can transition to business as usual, as quickly as possible.

Google does not recommend rollout projects longer than 45 days.

Fast track deployment

If under pressure to take immediate action following or during a breach, it is possible to deploy in 15 days or less.

Doing so requires that executive sponsors and business leaders accept that where DKIM is not applied to messages, SPF records may not provide sufficient coverage of all email servers sending email on behalf of a domain. If this occurs emails may be quarantined or rejected depending on the DMARC policy in place at the time.

If IT Team has not yet had the chance to skill up on DMARC, it’s important that they work with a partner who has the necessary knowledge and experience to expedite initial onboarding.

The more aggressively you wish to move during deployment, the more important it is that your partner is experienced.

Select a DMARC analytics tool

Google’s recommended best practice is to always enable aggregate reports for all domain implementing DMARC. We also recommend requesting forensic reports during the initial monitoring phase.

NOTE: Gmail currently accepts requests for aggregate reports.

Once configured, reports will start arriving within 24 hours. While these XML reports are mostly readable by a technical audience, they are best processed using dedicated analytics tools. These tools will be able to aggregate the data and add insights from other sources like WHOIS data, blackhole list providers, and others.

There’s a number of tools available in the marketplace and DMARC.org offers a list of known vendors.

The vendors in this space offer services across almost the entire spectrum, from the self-provisioned DMARC reporting, to near real time processing, and even fully managed offerings.

G Suite partners can help bridge the gap between these tools and your G Suite configuration.

List of DMARC tools