FraudWatch International Blog

You are here: Home » Blog » DMARC: Protecting Your Domains

DMARC: Protecting Your Domains

The effortlessness in the capability to generate fake emails has long been exploited by cyber-criminals as a mechanism to deploy spam, phishing attacks or malware, and has been so since the invention of email. DMARC is a simple way to give the receivers of an email the ability to validate the authenticity of an email, an added protection to make it easier to identify.

What is it?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a validation system for email, which allows email spoofing to be detected and prevented. Its goal is to wage war on phishing and email scams, where the sender's address has been forged to appear as though it came from a legitimate business.

Our Experts Explain

DMARC is built on top of two existing email standards: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail):

  • SPF – allows domain owners to authorise hosts who can use their domain name in the "MAIL FROM" or "HELO" identifier. A list of which sending hosts are allowed to use a particular domain name is published in the Domain Name System (DNS) records for that domain, as a specially formatte TXT record. Mail receivers can use these records to check the authorisation of the sending Mail Transfer Agents (MTAs). An added benefit is that the receiver can then use the sender's domain, rather than the host's IP address to determine email acceptance or rejection. This is useful because a domain name's reputation is likely to be more accurate than that of the host IP address.
  • DKIM – allows a domain owner tag and email message with a digital signature. Verification of the email is done using the signer's public key, which is published in the DNS. A valid signature guarantees that at least some sections of the email have not been modified since the signature was attached.

Even though SPF and DKIM were helping to identify fake emails, neither of these protocols provided a way to get a report on what messages were being rejected and why. DMARC solves this problem by: allowing domain owners to tag sent messages with certain domain identifiers to prove legitimacy; giving receiving email servers instructions on how to deal with messages that fail SPF and DKIM authentication checks; and also providing a reporting mechanism to communicate what actions were performed under the policies.

As email has evolved, many tools have been used to try and identify if mail is truly coming from (for instance) "irs.gov" or if it is an imitation. Unfortunately, these tools work in silos with each receiving mail server making unique decisions on how to respond to the results and the legitimate domain owner (e.g. the IRS) is left in the dark, with no feedback. DMARC removes the guesswork from how the receivers handle failed messages, thereby reducing the potential for users to be exposed to possible fraudulent & harmful messages. DMARC also provides the ability for the email receiver to give feedback to the sender about messages that pass and/or fail DMARC validation.

How does it work?

DMARC prevents spoofing of the “header from” address by:

  • Cross-checking the “header from” domain name against the “envelope from” domain name used during the SPF check
  • Matching the “header from” domain name with the “d= domain name” from the DKIM signature.

Benefits of DMARC

  • Before DMARC, receiving mail servers did their best to work out if email was real or not. This was never perfect and users had to look in spam folders for missing email.
  • DMARC creates consistency for dealing with messages that fail to authenticate.
  • Publishing a DMARC record protects your brand by stopping unauthorised hosts from sending mail on behalf of your domain.
  • After setting up your DMARC Record, so legitimate emails are easily identified, you can instruct all recipients to reject emails from anyone imitating your company. This was the original purpose of DMARC - to prevent domain abuse.
  • DMARC reports give you visibility of who is sending mail from your domain.

An example of a DMARC Record

Enclosed below is a sample DMARC record to illustrate how the DMARC record is put together and what each component means:

Domain being protected (Organisational Domain): samplecompanydomain.com

Secondary domain covered (Sub-Domain): example.samplecompanydomain.com

The following record would be added to the DNS zone file for samplecompanydomain.com"v=DMARC1;p=reject;pct=100;rua=mailto:email@dmarcreportingdomain.com"

Tag: v

Purpose: Defines the DMARC protocol version

Example record: v=DMARC1

Tag: pct

Purpose: Defines the percentage of messages to be filtered

Example record: pct=20

Explanation: This example indicated that 20% of the records will be filtered

Tag: ruf

Purpose: Specifies the URI (Universal Reporting Indicator) or email address where forensic reports should be sent

Example record: ruf=forensic@dmarcreportingdomain.com

Explanation: This parameter indicates that all forensic reports (where generated by the policy being enforced by a receiving mail server) will be sent to forensic@dmarcreportingdomain.com

Tag: rua

Purpose: Specifies the URI (Universal Reporting Indicator) or email address where aggregate reports should be sent

Example record: ruf=aggregate@dmarcreportingdomain.com

Explanation: This parameter indicates that all aggregate reports (where generated by the policy being enforced by a receiving mail server) will be sent to aggregate@dmarcreportingdomain.com

Tag: p

Purpose: Policy for the primary or Organisation domain

Example: p=quarantine

Explanation: This policy instructs the recipient or their delegated admin with options about what to do with the mail that will still be received but tagged as a quarantined item. Typically receiving servers and their admins will see mail marked as quarantine as spam and treat it accordingly. This option is often used when first implementing DMARC to see what legitimate servers are sending emails that you don’t know about.

Tag: sp

Purpose: Policy for the secondary or sub-domains of the Primary or Organisational domain

Example: sp=reject

Explanation: This policy instructs the receiving server to reject mail from the sub-domain if they enforce DMARC compliance for their recipients. How mail rejection is implemented will differ between mail providers.

Tag: admkim

Purpose: Specifies the alignment mode for DKIM signatures

Example: adkim=s

Explanation: DMARC is tied to other protocols that exist to protect against spam and malicious email. This tag is used to determine how DKIM should be referenced when a receiving servers assesses the DMARC record where s is Strict and r is Relaxed. In our example, Strict mode is defined which means it requires an exact match between the DKIM domain and the email’s header.

Tag: aspf

Purpose: Specifies the alignment mode for SPF signatures

Example: aspf=r

Explanation: DMARC is tied to other protocols that exist to protect against spam and malicious email. This tag is used to determine how SPF should be referenced when a receiving servers assesses the DMARC record where s is Strict and r is Relaxed. In our example, Relaxed mode is defined which means it does not require an exact match between the SPF domain and the email’s FROM domain.

IMPORTANT: Not all receiving email servers will perform a DMARC check before accepting a message, but most of the big ISPs have already implemented this tool, and the list of adopters is growing at a steady rate.

 

Here at FraudWatch International, we recommend having a well implemented DMARC strategy to stop emails reaching end users that are spoofing your domain. This is a highly effective method to stop both general phishing emails being sent to your customers, and spear phishing emails being sent to your employees.

FraudWatch International recently launched our DMARC services. Tune in next week to find out about how our DMARC services can help protect your domain and by extension, your company.

Receive Blog updates to your Inbox! Subscribe Now

Sales Enquiry