How to run a DMARC Project DMARC Project Tools

Implementing a compliant DMARC DNS entry that protects your domain from SPOOF attack and therefore reduces organisational risk will adversely effect your email reputation if not implemented correctly. Being the first email service provider to have mandated DMARC in 2017 we have had more experience than most so we wanted to share this guide to help you on your journey.

DMARC Project Guide

We often get asked how to implement DMARC so that your email reputation benefits from the protocol and your organization’s staff and brand are protected from Phishing and SPOOF attacks.

The purpose of DMARC and the reason why it is mandatory to implement the authentication, is that your email domain will be protected from being used in a SPOOF attack using your domain. It is important to note that only when the DMARC record is set to reject or quarantine, which must cover 100% of the host domain and subdomains, there is no exception. Using the subdomain options that the DMARC configuration allows for is primarily during the first and second phases of the project and is really for enterprise level organisations that have subdomains for different countries or purposes.

DMARC Project Overview

For most organisations, reaching a compliant and protected position will take longer than expected due to the number of applications that send emails. Each application that sends email, for example any desktop application, server or mobile app must authenticate the email. If authentication fails the emails will not be reach the recipient once you issue a p=quarantine or p=reject record. It is therefore vital to approach a DMARC project in a logical manner progressing each phase using a step-by-step approach.

The DMARC record that you should aim to have is:

v=DMARC1; p=reject; rua=mailto:zuluedm@au.zuluedm.com; ruf=mailto:zululabs@au.zuluedm.com; fo=1;

There are variations however most organisations we assist and route email for end up with a result similar to the record above. Forensic reporting is turned off to reduce waste and capacity issues when things settle. You may turn on the reports back on if you are debugging or require more information than provided in the summary reports.

When an email from your domain is sent, the record above is the set of instructions for the receiving mail server to abide by. Therefore if set to reject then no SPOOF email will reach recipients.

The email addresses listed in the example is for the the DMARC reporting tool included in our Zulu Trusted Sender program and our Zulu eDM campaign management platform. To access the tool visit https://trustedsenderscore.com/tools

The two email addresses in the DMARC record are the instructions to mail servers as to where to forward DMARC reports. DMARC reports are critical for achieving compliance.

Once the DMARC record is set we recommend waiting a week and then begin the project phases, with 1 being the start and the last task in Phase 4 being the completed implementation. Phase 1 and 2 are interchangeable in terms of tasks being undertaken. once reports are flowing. Phases 3 and 4 can be as well:

1.) Report analysis and planning

The first step before configuring your DMARC record is to answer the following questions:

1.) Where will the DMARC reports be sent to and how will they be rendered?

2.)Is our mail server inbound compliant? If not then you will not be able to protect your users (staff for example) from SPOOF and Phishing attacks. You then have decisions to make. We recommend putting in the DMARC record and having your main alternative email gateway configured and ready to route mail before you consider changing.

The Zulu eDM SMTP Email Gateway has traditional SMTP settings and our more advanced API. Having both options is essential for this project.

If not then you will not be able to protect your users (staff for example) from SPOOF and Phishing attacks. You then have decisions to make. We recommend putting in the DMARC record and having your main alternative email gateway configured and ready to route mail before you consider changing.

The Zulu eDM SMTP Email Gateway has traditional SMTP settings and our more advanced API. Having both options is essential for this project.

Once you have those questions answered you need to then have access to the following:

  • MX, SPF, DNS & DKIM checking tools
  • DKIM (domain key) Key Generator
  • Access to your domain’s DNS
  • Access to your email server platform

Now you are all set and ready to add your first DNS entry. Log into your DNS and add the following.

 _dmarc.yourdomain.com in TXT
v=DMARC1; p=none; rua=mailto:zuluedm@au.zuluedm.com; ruf=mailto:zululabs@au.zuluedm.com; fo=1;

You should experience no interruptions and have your reports pointing to the Zulu Trusted Sender DMARC Reporting application. Forensics is simply the original mail headers with no analysis. The report contains the pass/fail data.

Sit tight, we recommend for about 1 week until your DMARC reports start to be received. In the meantime it’s time to get your servers ready. If you are using GSuite or Outlook you must install DKIM. This is because for all apps like Calendar etc the email is routed via MTA’s and not the MX, so DKIM and SPF records are vital.

Next is the vital email gateway that will handle your reputation management, delivery of campaign and burst mail, notifications, invoices and any application email you need to route. There are only 2 providers that we know of that provide reputation management with email delivery, DYN DNS (Oracle) and Zulu eDM Campaigner.

We understand the Oracle pricing starts at $5,000 USD per month. The Zulu Professional Campaigner starts at $165 USD per month.

Your DNS settings are available from your Zulu eDM account and you can use the Zulu DNS Checker to verify your set-up.

Zulu Trusted Sender provides a free DMARC reporting tool for all Trusted Sender Email clients and Zulu eDM campaign manager users.

2.) Configure applications to send authenticated email

Now you have your 2 email gateways configured it’s time to work your way through each application that you know sends email and configure them to use the compliant gateways.

It is important to note that single check DMARC can be spoofed and therefore domains that use email routes that are configured for single check only authentication can be SPOOF’ed and are untrustworthy. You can read the findings by our CEO, David Barnes on SourceForge.

There will be a lot of headaches if you have invested in API development for email routing. Google and Amazon will not permit any SMTP ports and this is a huge hindrance for implementing DMARC. Thankfully we permit both styles of emails sending, API based and SMTP settings.

3.) Organization Ready

There are 5 key aspects to preparing an organization for DMARC Anti-SPOOF compliance which include:

Internal awareness: making staff and key stakeholders aware of business email compromise attacks, what to look out for and what steps you are taking to protect the organisation internally. Also awarenss of external factors are critical as well as the the steps being taken to prevent external misuse of your email domain.

External communication: split into project and post project tasks.

Contracts, terms of trade, conditions of use, commercial agreements, franchise agreements and any other process that email is attached to must be thought through and then formalised. For example, contract termination in writing (via email).If the third party is not compliant and therefore their email fails to reach your email servers, who is responsible and what will the outcome be?

Tools for staff to be able to understand which domains that regular business is conducted with, are protected or not. What are the procedures and actions that must take place if a client or member of the public is attacked with your domain during the DMARC Compliance Project. Indeed what and how do you communicate to people that claim they have been attacked after you become compliant.

Inbound protection (checking for DMARC). Google’s GSuite and Microsoft’s Outlook have Anti-SPOOF settings which allows you to configure your inbound email protection against SPOOF and Phishing email. This is referred to as inbound protection