I have recently been reminded that our CSA domains are not fully DMARC-enabled. So, I started my very first DMARC journey ever. Let me take you on this journey about theory vs. reality!

Your benefits of implementing DMARC

• Protecting your email users from receiving phishing campaigns in your brand’s name.
• Your DMARC-protected domains are less attractive for spammers to impersonate you.
• Support the mailbox providers to differentiate between good and bad emails coming from your domains, based on your decision for the inbound traffic handling.
• DMARC reduces your support effort (costs) on spam and email fraud complaints.
• Free access to a data source about your email traffic.
• You are qualified for BIMI (p=reject or quarantine) and can thus further strengthen the trust in your brand domains.
• The ability to monitor and check the technical settings that your service providers have made on your behalf and detect accidental setting errors more quickly.
• You are seen as a best-in-class sender, supporting the collaborative effort of the industry to fight email fraud.

Setting up DMARC seems easy

DMARC doesn’t require any deep technical knowledge for the implementation. It is a simple TXT record in your domain’s DNS. There are plenty of wizards, guides, and free support on the web to help you set it up.

DMARC itself is free, as are SPF and DKIM. There are no setup costs for DMARC because of the simplicity of using TXT records. Protecting your domains and preventing abuse is also free of charge, even after implementation. And you receive free of charge data from the mailbox providers about your domains.

However, the data reports for DMARC are provided in XML data format and are not easily understood without technical tools. There may be a one-time or recurring cost for these tools or for any services or managed support that may be required during set-up.

Emerging doubts

So… I started setting up my DMARC records with all the above in mind. But it wasn’t long before I found myself in a difficult situation with questions I couldn’t quite answer directly:

• How many domains and sub-domains are set up in total and which ones are in use for email?
• Which different services or tools use my sub-domains for email?
• DMARC inherits the settings to the sub-domains of my main domain – do I need to be more specific about the settings for each of the sub-domains?
• May I consider a different setup for each sub-domain based on the service and purpose?
• P=none doesn’t make sense to me, what does it take to start with p=quarantine?
• Relaxed or strict alignment? The stricter I am, the less gaps are left for misuse.
• What to do with the reports I’m going to receive from the mailbox providers?
• Am I able to oversee all impact on my DMARC setup?
• What can I do with domains that are not used for email at all but could still be misused?

I’m sure there are loads of people out there who have the same challenges, thoughts, and struggles, but give up because, while they see the benefits of implementing DMARC, they never had any business impact of phishing etc. on their domains and the list of questions may even be longer than mine.

You might be thinking the same as me here: „High valued commercial brands, financial services, insurances, social networks and public authorities should care, they have the responsibility to protect the email eco system, because they have an impact, and they make the difference.”

It is not as easy as that! If you were the last possible entry point for an adversary to penetrate email security, you would be used for that purpose, undermining everyone else’s efforts.

No matter what – get it done

The last point was my final motivation to work on a complete setup for the CSA. I want the CSA to have an impact and to share the responsibility for fighting spam and email fraud. We only have a small volume share in the overall email ecosystem, but senders are looking at us and following us to start supporting global cooperation in this area.

DMARC is no longer an early adopter phenomenon, but a mass movement that started with the big players, as I mentioned earlier, but we are all seeing these gaps being closed and the entire cybersecurity industry watching as criminals use the invisible, innocent, and often unsuspecting small players in the email ecosystem to gain access.

Preparation: SPF and DKIM are in sole control of the CSA tech team and correctly set up.

The CSA is currently using three different domains (and sub-domains) for sending emails:

• certified-senders.org
• certified-senders.org
• system-certified-senders.org

Step 1: <xyz>.certified-senders.org.   IN   TXT   "v=spf1 -all"

No other domains are used by us to send emails and I don’t want anyone else doing this unseen on behalf of the CSA.

This prevents emails being accepted by the mailbox providers that come from one of my domains that I’m not currently using to send emails. The authentication will fail at the first step.

Step 2: certified-senders.org.   IN   TXT    "v=DMARC1; p=none; pct=100; rua=mailto:abuse@certified-senders.org"

The inheritance feature in DMARC protects all underlying subdomains globally and then I receive a report about the email traffic.

Step 3: info.certified-senders.org IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:abuse@certified-senders.org; adkim=s; aspf=s"

This sub-domain is used by our email service provider for CSA marketing emails such as newsletters or event emails. I want the mailbox provider to move any email that is not correctly authenticated to the spam folder and receive the report. No one else is allowed to use the CSA reputation for their purposes.

Step 4: system.certified-senders.org IN TXT “v=DMARC1; p=reject; pct=100; rua=mailto:abuse@certified-senders.org; adkim=s; aspf=s"

This sub-domain is used by our internal and external systems for monitoring, reporting and maintenance emails. No one other than us is allowed to send email using this subdomain. Any email that fails authentication on this subdomain should be rejected by the mailbox providers.

The journey continues

I’m not done at this point; while working on the DMARC topic, I observed additional tasks that I’ll do very soon as part of a follow-up to this initial DMARC setup.

• Not every domain is fully documented in its use and purpose. This needs to be done quickly.
• There is also CSA-branded email traffic sent from other domains within our global organisation that needs to be analysed and may require a different setup and management.
• Once we receive the DMARC reports, we need to manage the data analysis to gain insights for further adjustments or changes, whatever they will mean to us.

The data analysis will be my next challenge. Once I receive the aggregated reports for our domains, I need to find an effective way to analyse and learn from the data. This already raises a lot more questions, but I have already decided to take the pragmatic approach and find a solution when its needed.