Federal agencies that send and receive email using .gov domains must use DMARC for email security to meet the Department of Homeland Security’s Binding Operational Directive (BOD) 18-01. This Getting Started with DMARC: A Guide for Federal Agencies ebook gives you an overview that includes:

  • What DMARC is, how it works, and why federal agencies need to implement it;
  • The benefits of DMARC for your agency and its stakeholders; and
  • A step-by-step approach to correct DMARC implementation.

The Believers
Early Adopters Pave the Path

2.5 Billion Mailboxes Worldwide are DMARC-Enabled

The Benefit
Why You Should Care

[DMARC] provides the strongest protection against spoofed email, ensuring that unauthenticated messages are rejected at the mail server, even before delivery.

Binding Operational Directive 18-01 
Department of Homeland Security 

  • Public Protection: It is only a matter of time before a criminal will use your domain for their own benefit. Whether the criminal activity is phishing, malware distribution, or nuisance spam, implementing a DMARC enforcement policy will better protect users who might otherwise fall victim to a phishing email that appears to come from a government-owned system.
  • Increased Email Deliverability: Even legitimate messages may wind up in the spam folder if the receiver can’t tell the good from the bad. By deploying DMARC, you can improve deliverability of your legitimate messages while eliminating the fraudulent.
  • Fewer Constituent Complaints: Constituents or members of the public don’t call or send email to ask about phishing messages if they never receive those messages in the first place! One Agari customer was able to redeploy 60 staff members after publishing a reject policy on a highly phished domain.
  • Visibility: Federal agency domain owners will gain visibility into how their domains are being used across the Internet. In particular, they will gain knowledge about every 3rd party that sends email on behalf of their domains.

The Standards
A Closer Look 

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
example.net. IN TXT “v=spf1 a mx-all”

Weakness
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
selector._domainkey.example.net IN TXT
“v=DKIM1; k=rsa; p=public key data” 

Weakness
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 (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
dmarc.domain.com. IN TXT “v=DMARC1; p=reject;
rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;” 

For more information, please visit www.dmarc.org

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 “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:

  • 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.

12345
Close button
12345
Mail Letter

Would you like the confidence to trust your inbox?