fTLD on Twitter

June 11, 2019

Email-Borne Fraud and Abuse: To See or Not to See

By Andrew Kennedy, BITS-BPI Cybersecurity Advisor to fTLD

fTLD Registry Services, the administrator for .BANK and .INSURANCE, was formed to establish a new base of trust and security for eligible banks and insurers on the internet.  In part this is accomplished by the rigorous verification standards for domain applicants who must prove their bona fides.  For those organizations that qualify, they also must adhere to fTLD’s stringent cybersecurity requirements.

Since its inception, fTLD has always required email authentication technologies to be deployed to help protect bank and insurance customers, employees, and vendors from email spoofing (phishing). These technologies included both Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).  In the 2014 security requirements update, fTLD required DMARC (Domain-based Message Authentication, Reporting and Conformance) which added additional functionality to SPF and DKIM.

fTLD mandates the implementation of opportunistic TLS, DMARC and at least one of SPF or DKIM across the email channel.  fTLD recommends layering both SPF and DKIM together for the most effective and resilient anti-phishing and authorized email delivery outcomes.

SPF – An IP whitelist for authorized email sending servers hosted in DNS.

DKIM – Adds a cryptographic signature to every sent email that receiving email servers can use to validate email authenticity using a public key hosted in DNS.

DMARC – Extends DKIM and SPF by establishing domain specific policies, hosted in DNS, that instructs email receivers on how handle unauthenticated emails (e.g., from IPs not whitelisted in the SPF record).  Further, DMARC offers aggregate (RUA) and forensic (RUF) reports from participating receiving domains to the sending domain owner that can be used to validate SPF and DKIM are working as anticipated (blocking spoofed email and delivering authorized emails).

While many organizations simplify their DMARC implementation to focus on a “reject” policy (blocking spoofed email), some overlook a feature to request reports on traffic receiving domains “see” from emails purported to originate from the sending domain.  These reports come in two formats:  Aggregate Reports (RUA) and Forensic Reports (RUF).

To receive these reports an email address with the corresponding RUA and RUF tags must be added to your DMARC recorded hosted in DNS.

Aggregate Reports (RUA) are XML formatted files sent daily and provide an overview of email purporting to originate from your domain as seen by a receiving domain like or (as examples).  Aggregate reports provide visibility of receiving server seen email and identify whether those emails successfully authenticated or not.  This otherwise unprecedented visibility can help determine:

  • Whether lines of business and authorized third parties are following enterprise email policies
  • The extent to which your domain is being actively spoofed or phished
  • Whether your DKIM or SPF records are being honored so that authorized mail is being delivered and unauthorized email is being rejected as expected

Forensic Reports (RUF) return redacted versions of rejected emails that are often suspicious in nature.  These reports contain message level data such as the “From” address, IP address, and links in the body of the email which may lead to a phishing website that may be of interest to your threat intelligence team.  The intent is to provide information that may be immediately actionable to protect your employees, platforms, customers and brand.  Not all receiving domains that honor DMARC reject policies provide RUA reports but some do which may still be enough to get out in front of a phishing campaign.

Whether you decide to request DMARC RUA or RUF reports, or both, registrants (i.e., domain owners) should consider a few things.  First, you might receive a lot of data, some of it may be sensitive (like with the RUF reports), and should be prepared to manage it.  Second, the data will be raw and to be useful needs to be analyzed.  Third, you will need a policy and process in place to act on the analyzed data.

Many organizations who want analyzed DMARC reports find themselves in a “buy versus build” situation.  Either solution can work depending on the organizational goals however it is worth noting there is a mature ecosystem of vendors that are focused on email authentication and brand protection.

Do you know fTLD maintains a list of approved third-party providers who can help registrants manage DMARC reports and comply with fTLD’s Security Requirements including email authentication?

The main takeaway is that if you are using DMARC and not receiving or analyzing RUA and/or RUF records, you do not have maximum visibility into what is going on with your domain from both a deliverability and brand protection perspective.  In an industry where the email channel is a key connecting point with your customers and criminal attacks can quickly erode that trust, knowledge is power.