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
example.net. 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 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
selector._domainkey.example.net 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 www.dkim.org
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
dmarc.domain.com. IN TXT “v=DMARC1; p=reject;
For more information, please visit www.dmarc.org
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:
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.
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@<your-domain.com>;
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
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.
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.
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.