The reality of email is that cybercriminals can use almost any brand or email domain to send spam, phishing emails, and malware installs, inflicting direct losses to customers and eroding the brand equity companies have spent years building up. The solution is DMARC, which allows companies to understand all the different mail streams being sent under their name, and prevent the malicious ones from getting to consumer inboxes.

Read “Getting Started with DMARC” now for:

  • An overview of what DMARC does and how it works
  • A closer look at security standards including SPF, DKIM, and DMARC
  • DMARC implementation steps, best practices, and common challenges
  • Real-world data on phishing attacks before and after DMARC adoption

The Standards
A Closer Look at SPF, DKIM and DMARC 

SPF (Sender Policy Framework)

SPF is an email authentication standard that allows domain owners to specify which servers are authorized to send email with their domain in the Mail From: email address. SPF allows receivers to query DNS to retrieve the list of authorized servers for a given domain. If an email message arrives via an authorized server, the receiver can consider the email authentic.

Example DNS Record IN TXT “v=spf1 a mx-all”

SPF is not ideal for all email use cases and can fail if a message is forwarded. The Mail From domain authenticated by SPF is not easily visible by an email recipient.

DKIM (DomainKeys Identified Mail)

DKIM is an email authentication standard that cryptographically associates a domain name with an email message. Senders insert cryptographic signatures into email messages that receivers can verify by using DNS-hosted public keys. When verification is successful, DKIM provides a reliable domain-level identifier that can survive forwarding, unlike SPF.

Example DNS Record IN TXT
“v=DKIM1; k=rsa; p=public key data” 

DKIM is generally more complex to set up than SPF, requiring a cryptographic signature on each message sent. DKIM will fail when content is modified in transit, like messages sent through a mailing list.

For more information, please visit

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC is an email authentication standard that works in conjunction with SPF and DKIM. It brings long-missing features to email, enables senders to gain visibility into how their email domains are used and abused, describes how to combine existing authentication technologies to create secure email channels, and provides receivers with clear directives on how to safely dispose of unauthorized email—all at Internet scale.

Example DNS Record IN TXT “v=DMARC1; p=reject;;;” 

For more information, please visit

The Mechanics
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 “” publishes a DMARC record, issuing a DNS query for the TXT record at “_” 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:

  • p=none: No policy should be applied, also often referred to as “monitor.” This option is used when senders simply want to collect feedback from receivers.
  • p=quarantine: Email that fails authentication checks should be treated with suspicion. Most receiving mail systems will deliver these messages to an end user’s spam folder. It could mean increased anti-spam scrutiny or flagging as “suspicious” to end-users in some other way.
  • p=reject: Email that fails authentication checks should be rejected at the receiving mail server. These messages should never reach the end user’s mailbox and feedback will be sent to the party specified in the policy.

Subdomain-Specific Policies: DMARC records can specify different policies for top-level domains vs. subdomains using the p= and sp= tags.

Phased Rollout of Policies: DMARC records can include a “percentage” tag (“pct=”) to specify how much of an email stream should be affected by the 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 subdomains 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.

The Process
Putting DMARC Into Practice

Domain owners that wish to become DMARC compliant need to perform three activities:

1. Publish a DMARC record. To begin collecting feedback from receivers, publish a DMARC record as a TXT record with a domain name of “_dmarc.”:

“v=DMARC1; p=none; rua=mailto:dmarc-feedback@<>;

Doing so will cause DMARC-compliant receivers to generate and send aggregate feedback to “dmarc-feedback@”. The “p=none” tag lets receivers know that the domain owner is only interested in collecting feedback. Use the DMARC record creator on the Agari website to easily create the required text.

2. Deploy email authetication for SPF and DKIM

  • Deployment of SPF involves creating and publishing a SPF record that describes all of the servers authorized to send on behalf of an email domain. Small organizations usually have simple SPF records, whereas complex organizations often maintain SPF records that authorize a variety of data centers, partners, and third-party senders. DMARC-supplied aggregate feedback can help identify legitimate servers while bootstrapping a SPF record.
  • Deployment of DKIM requires domain owners to configure email servers to insert DKIM signatures into email and to publish public keys in the DNS. DKIM is widely available and supported by all major email vendors. DMARC-supplied aggregate feedback can help identify servers that emit email without DKIM signatures.

3. Ensure that Identifier Alignment is met. DMARC-supplied aggregate feedback can be used to identify where underlying authentication technologies are generating authenticated domain identifiers that do not align with the email domain. Correction can be rapidly made once misalignment is identified.

By taking these steps, domain owners can effectively monitor email and make informed seurity decisions.

Get Started By Creating Records for Your Domain

The Big Picture
It’s Worth a Thousand Words

Email Before DMARC: Without DMARC, brands have limited visibility into how domains are being used to send email.

Email After DMARC: DMARC provides visibility into all email traffic and instructs receivers how to handle unauthenticated emails, all outside of the mail flow.

The Results of Implementing DMARC
A Real World Example

Before and After DMARC Enforcement:
The accompanying chart, showing anonymized views of a customer dashboard, highlights the dramatic impact of implementing DMARC. DMARC is so effective at preventing these malicious email campaigns that the bad guys literally give up trying to send malicious email.

The Best Practice: Gradually Moving to Enforcement
This next chart depicts another campaign targeting new domains. Here, the customer employed a gradual adoption of tighter DMARC policies, just as DMARC was designed to be deployed. Initially, unauthenticated mail volume surpassed 100,000 to 150,000 messages per day. After a Quarantine policy was implemented, this was cut to 50,000 or less. The policy was tightened further to a Reject policy, which practically eliminated the volume of unauthenticated email.

Close button
Mail Letter

Would you like the confidence to trust your inbox?