How DMARC Works
The DMARC model uses DNS as the mechanism for policy publication. DMARC records are hosted as TXT DNS records in a DMARC specific namespace. The DMARC namespace is created by prepending “_dmarc.” to the email domain that is to become DMARC compliant. For example, if the email domain “example.com” publishes a DMARC record, issuing a DNS query for the TXT record at “_ dmarc.example.com” will retrieve the DMARC record.
The DMARC specification allows senders to publish policy records containing parameters that receivers use to inform the processing of emails that purport to come from the sender’s email domain. The features that DMARC enables are:
- Flexible policies. The DMARC model allows email senders to specify one of three policies to be applied against email that fails underlying authentication checks:
DMARC Policy Options DMARC Policy Setting Syntax Action taken by Receivers None (“Monitor”) p=none “p=none” policy means no policy should be applied; that is, the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy is also often referred to as “monitor” policy. This option is used when senders simply want to collect feedback from receivers. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused. There would be no change in how their messages are treated; however domain owners would now gain some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, start by publishing a DMARC policy first because of its reporting capabilities. Quarantine p=quarantine In a quarantine policy, email that fails authentication checks should be treated with suspicion. Quarantine instructs receivers to “set messages failing DMARC aside for additional processing.” Most receiving mail systems will deliver these messages to an end user’s spam-folder. It could mean increased anti-spam scrutiny or tagging as “suspicious” to end-users in some other way. Reject p=reject Do not accept messages that fail the DMARC checks. - Sub-domain-specific policies. DMARC records can specify different policies for top-level domains vs. sub-domains (using the “p=” and “sp=” tags).
- Phased rollout of policy. DMARC records can include a “percentage” tag (“pct=”) to specify how much of an email stream should be affected by DMARC policy. Using this feature, senders can experiment with progressively stronger policies until enough operational experience is gained to move to “100% coverage.”
- Identifier Alignment flexibility. The DMARC specification allows domain owners to control the semantics of Identifier Alignment. For both SPF and DKIM generated authenticated domain identifiers, domain owners can specify if strict domain matching is required or if parent and/or sub- domains can be considered to match.
- Feedback controls. DMARC records include parameters that specify where, how-often, and in which format feedback should be sent to the email domain owner.
What DMARC and Agari DMARC Protection Add
DMARC adds important functionality to that available through SPF and DKIM:
- Flexible policy options for acting upon SPF and DKIM authentication failures — this is the “missing piece” in the SPF and DKIM specifications that is necessary for elimination of malicious emails.
- The ability to gather data on all email senders using your domain name. DMARC sends data in XML format to the address of your choosing.
The XML data that DMARC generates can be difficult to handle, in part because the email data is usually extremely voluminous. In handling and analyzing the data, keep in mind the following needs:
- Data needs to be analyzed in aggregate to visualize trends.
- Individual emails must be available to analyze sender details.
- Historical data should be housed for the insights it can provide on both threats and legitimate senders.
Agari’s data analysis gives you the benefit of its experience working with the world’s highest volume email senders to help you interpret and understand the data that comes in from DMARC. In addition, for all related tasks that must be performed outside of any user interface, Agari assists you in creating the properly formatted files.
DMARC Protection fills in the missing pieces between the protocols by:
- Reporting its interpretation based on industry understanding of email ecosystems.
- Providing visibility of actual sample email messages.
- Guiding you through key steps in implementation.
Hosted DNS Records
Agari can host your DMARC, SPF, and DKIM records. Agari-hosted DMARC, SPF, and DKIM records mean that changes that you make in DMARC Protection get updated in DNS quickly, securely, and automatically.
Normally, when anything changes in your DMARC, SPF, and DKIM, you would have to update your own host records manually, one-by-one for each domain that has its records changed. This can be a lot of make-work, especially if you have a lot of domains. For example, with DMARC, the goal is to start with p=none (monitor), then move to quarantine, and finally get to reject. Imagine if you have a thousand domains that you manage (which you can do in DMARC Protection; you are limited to 5 domains in Business Fraud Protection) and you have to change a thousand DNS records for each DMARC move.
Now imagine Agari hosting your DMARC (and SPF and DKIM) records. You have that same thousand domains and you want to move them all from monitor to quarantine. In DMARC Protection, you can make that change to the DMARC records of all those domains at once. And if Agari is hosting your DMARC records, the change will be made to all thousand domains automatically (and quickly and securely).
Inbound DMARC Visibility
This feature provides DMARC visibility to inbound email for domains owned by your company by using an CEP email Sensor.
For example, imagine that your company, Acme, has multiple domains registered within the Agari DMARC Protection product. One of those domains is hr.acme.com, which the HR department at your company is using as a sending domain to deliver HR emails to employees, either directly or via a third party service. When people in acme.com receive an email from hr.acme.com, the sensor will process this email and provide DMARC results for this domain within the DMARC Protection product to give you confidence that your employees are receiving these emails as DMARC is enforced.
Using Inbound DMARC Visibility requires setting up a sensor in Fortra Cloud Email Protection. See Monitor Your Inbound Messages.
See Also