Protecting your brand with atmail and DMARC

Despite claims that new technologies will soon replace email, email usage has consistently grown by 3 percent annually since 2017. The upside of this is that with email reaching over 4 billion users worldwide in 2020, it remains one of the largest (and often most successful) touch points in the marketing world. The downside of this is that all of these email users have become a potential target for email fraud.

Unfortunately, this is exacerbated by employees working from home, and the global reach of the COVID-19 pandemic has forever changed the work from home paradigm. While much of the workforce will return to the office once the world is through this crisis, many employees will continue to work from home, either all or part-time. This change means a shift in how people are receiving critical information. Fewer in-person meetings or conversations as someone is walking past your desk increases the amount of information relayed via email directly, increasing the amount of time each person spends in their inbox each day. Strictly from a numbers and statistical point of view, this means the chances of falling victim to fraud, specifically some email phishing variant, increases daily. This is where DMARC comes in.

 

What problem does DMARC solve?

DMARC (Domain-based Message Authentication Reporting and Conformance) increases awareness of who is sending emails out for any given domain, and helps a company reduce the potential of a threat actor using its domain for this kind of attack.

DMARC leverages the existing SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail) email authentication techniques and takes the process a step further by providing critical data points by reporting to the domain owner who is sending an email with their domain. The information gathered in these reports allows the domain owners to protect their domains against phishing and spoofing attacks that can damage a company’s reputation and significantly affect its bottom line.

 

Why is DMARC important to atmail?

As a white-labelled email platform, atmail strives to be the ‘brand behind the brand’, providing the platform that our customers rely on to maintain their reputation. Therefore, we consider it essential to provide the tools required for our customers to protect themselves against these bad actors who would seek out their end users, damage our customers’ reputation, and potentially harm their bottom line. (In addition to the premium antiabuse suite that atmail provides, we offer detailed documentation to our customers so that they can configure and protect their domains against these kinds of attacks.)

 

Enabling DMARC in the atmail cloud

We will detail the steps for setting up DMARC here. You can find more detailed information on setting up SPF, DKIM, and DMARC in the atmail help centre.

As stated earlier, DMARC augments and improves upon the existing SPF and DKIM records already existing in your DNS. The critical part of DMARC is reporting. Reporting allows domain users to better know how their domain (and brand) is being used.

This reporting, combined with the SPF and DKIM, offers a domain admin the opportunity to create policy and monitor the sending patterns of their domain’s email; however, it is not strictly required to have either or both of these records in place to enable DMARC.

As a new customer coming to atmail and wanting to enable all three checks, we’ll start from the beginning. We will be using the domain sechub.com for these tests.

atmail publishes the SPF records that need to be enabled, and we can enable this right away. Enabling DKIM will require contacting [email protected] and getting the correct details for our DNS from the atmail cloud admin team. We will enable DMARC with the SPF records in place but without the DKIM records in place to start, and we will go back once we’ve received the keys from atmail.

The following details are specific to the atmail US public cloud. The premise is the same for our EU public cloud or any private cloud offering we provide; the syntax will be different and is noted in the article in our help centre. It is also worth noting that the details and options specified in this article are a basic set of rules to include. We provide more of a full list of options available to suit your specific needs in our help centre.

 

Requesting DKIM keys

• Contact [email protected] (or our portal ticketing system) and request keys for any domains you wish to enable. You will need your ClientID and the main username you use for your instance of the atmail cloud.
• atmail will then create relevant keys for each domain.
• You will then need to publish these keys in your domain’s DNS records. Implementation of this will be dependent on how you manage your DNS records. Once this is done, please update the support ticket with these details.
• atmail will then confirm the records are correct and can begin signing outgoing mail.

 

Enabling SPF

SPF records are used to denote from which IP addresses (or hosts) that a domain can (or should) be allowed to send. The entry you need to include as a TXT record in your DNS is:

v=spf1 include:spf.us-east.atmailcloud.com -all

You can check the TXT record is updated from the command line using dig or nslookup or use one of the many available online utilities for this. We’ll use MxToolbox in these examples.

Using dig:

MxToolbox:

Once our SPF records are in place, we can enable DMARC for our domain. There are several different tags available for inclusion in our DMARC record. Some of these are optional, and some of them are mandatory.

DMARC_Table (Information sourced from RFC 7489)

Once you’ve determined the tags you want to include, it’s a matter of creating a TXT record in your DNS for the domain. The method of this will be dependent on your DNS provider. The syntax for this is critical and one of the reasons a third-party tool for checking the records is handy. Again, we’ll use dig to show us the record and verify it’s been populated, and then I like MxToolbox for further verification.

The check with dig:

And we’ll verify this with MxToolbox:

 

Here we can see that we have an error with the syntax of our TXT record. Third-party utilities such as MxToolbox are handy for finding these kinds of issues. A comma in the place of where a semicolon should be is oftentimes easy to overlook, and these utilities can save you a tremendous amount of time.

Now that we’ve corrected the issue, we’ll check again with dig:

And verify once more with MxToolbox:

Now that the DMARC record has been verified, you can begin checking the email specified for the reports generated for your domain(s).

If you need any help, please reach out to our atmail Support team via [email protected] or via your atmail account portal.

 

Need more help protecting your brand?

With 22 years of global, email expertise, you can trust us to deliver an email hosting platform that protects your brand, and is secure, stable and scalable. We power more than 170 million mailboxes worldwide and offer modern, white-labelled, cloud hosted email with your choice of US or (GDPR compliant) EU data centres. Talk to us today.