Our cyber security products span from our next gen SIEM used in the most secure government and critical infrastructure environments, to automated cyber risk reporting applications for commercial and government organisations of all sizes.
DMARC is an email message validation system that helps stop phishing fraud that is fast gaining traction around the world. We will step through what it is, how to apply it and the threats it will help you avoid.
DMARC is a protocol that enables domains to trust each other by providing identity and proof of who they really are. Your “domain” is essentially the totality of IT within your organisation that forms your network and connects to the Internet.
The domain includes the organisation’s identity that is presented to the outside world such as website addresses. DMARC is concerned with inbound and outbound email traffic and the technology that sits behind it such as the Domain Name System (DNS) and email infrastructure like Microsoft Exchange Server.
This video briefing gives an idea as to the likelihood of attacks that DMARC can help avoid:
DMARC enables authentication between different domains as part of the exchange and transfer of email messages into and out of an organisation. It is supported by the likes of Google, Paypal and even LinkedIn, organisations who rely on the internet to be trusted and secure without security getting in the way of people getting work done.
In the UK, DMARC has been adopted by the Department for Work and Pensions (DWP) and HM revenue and Customs (HMRC) as their domains were a favourite for spoofing activity, with attackers attempting to phish details from unsuspecting members of the public. Attackers posed as these legitimate organisations claiming that there was a problem with benefit payments, an extra payment was due or a tax rebate awaited the submission of the recipient’s sensitive information or bank details.
As adoption grows further, it is inevitable that DMARC will become a “cyber essential” and a sign of best practice within the UK government and commercial sectors and around the rest of the world. It is definitely a cost effective control to consider as you design, build and maintain you ISMS.
Organisations have a Domain Name System (DNS) that is handled by a DNS server and produces DNS records. DNS records include information about how messages are handled and can include information about any DMARC policy that has been set.
The objective of DMARC is to validate the email sender. When an email is sent, the recipient email system is able to call back to the sender to automatically check and authenticate that they are who they claim to be. It is able to do this because a Sender Policy Framework (SPF) tells other domains where email messages from the sender organisation can originate from by way of IP address inclusion. The SPF is just a different type of DNS record.
The SPF works in combination with Domain Keys Identification Mail (DKIM), another common IT standard that DMARC uses. Think of DKIM as a signature that goes with every message and means that the recipient system is able to check that the signature [data] is as it should be and has not been forged or interfered with.
If the email is correct (i.e. it conforms and fully authenticates) then it arrives in the inbox of the intended recipient. If the email is incorrect (i.e. authentication fails DKIM or SPF) then, depending on the recipient policy that has been set, the message is rejected (junked as spam) or quarantined for review.
The primary benefit of DMARC is as a technical control to prevent somebody from forging and spoofing your organisation’s identity, where a threat actor masquerades as your organisation and abuses the trust, authority and any implied consent that your brand and mission carries.
You might already have email filtering and content checking capabilities but these tend to protect you within the network or at the network boundary. Those people out on the internet who receive emails that come from you, or appear to come from you, are not in scope. DMARC is not designed to replace these gateway email solutions but will enhance them by adding message authentication to your security defences.
Imagine that your organisation is a bank and an attacker has created a replica or illusion of your wider email and web site identity. This makes phishing attacks far more likely to be successful because they will look legitimate to the message reader who will be more likely to surrender personal details and credentials.
Other benefits of DMARC include a reduction in spam emails generally, and a view as to where emails that come from your organisation are actually sent from – hence improved visibility of your inbound and outbound email use.
While direct domain spoofing can be prevented by DMARC, sometime attackers will create fake domains that look very similar to yours but are not exactly the same:
e.g. “firstname.lastname@example.org” is not the same as…
Unless the reader is particularly sharp-eyed they are unlikely to spot there is something wrong.
Similarly, if yours is a “.com” domain and the attacker creates a “.net” or other similar looking address, DMARC will not stop or prevent this from happening.
Configuration will be carried out by your network/email admin team, and often in conjunction with your ISP if they have a role in maintaining your DNS records and network domain settings. There should not be a financial cost implication in DMARC adoption but you should consider the time of the administrator, the time taken to receive and understand DMARC reports, as well as the involvement of any IT change control processes to formally accept the change.
First you need to enable “monitoring mode” in the DNS record and your domain admin will do this by adding TXT files that provide the relevant instruction by way of “tags”. Only 2 tag values are required to get started, the rest are optional. This table is a compilation of tags from common sources across the Internet:
With the policy value set to “none” it means that there will be no impact or change to the way that emails flow. What we will start to get (it may take a day or 2) are DMARC reports back to the address that has been set up. You should be able to receive statistical reports even when SPF and DKIM are not yet in use on your domain.
When you eventually adopt SPF and DKIM, these reports will become enriched with information including the sources and identities of other domains and the messages that pass or fail authentication.
DMARC reports can give you visibility of any other domains that send emails on your behalf including those that are legitimate. This might sound odd but if you outsource marketing, telesales, public engagement or business functions like HR, they may well need to legitimately send emails that are “from” your organisation but not necessarily posted by your organisation’s core IT domain.
The team responsible for domain admin needs to add these acceptable domains to your records. If you don’t, then you risk messages being quarantined or rejected as spam when the policy value is modified to something other than “none”.
Don’t forget that your organisation might also use Gmail, Office 365 or other cloud hosted services to send email, they too can be added into your DMARC approach and you will see these sources within received DMARC reports.
Most third-party services that support DMARC provide guidance on how to add their domains to your SPF records and DMARC configuration. This is a link to Google, a strong advocate of the DMARC standard, which is vitally important if your organisation uses Gmail.
You can even add IP addresses of any applications that might also be used to send email. This too may sound a little strange but there are plenty of operational information applications that have a messaging interface and could send emails (perhaps as notifications to application users).
Ultimately all that happens within such apps and databases, is that whilst messages are constructed within a bespoke interface, the messages are sent via your standard server and gateways just like any other email, perhaps with attached records and metadata regarding content, any classification marking and structure.
On a darker and more critical security note, these reports will tell you if your domain identity is being spoofed by attackers and being used to pose as your organisation for phishing or other fraudulent purposes. These are the notifications that you really want to receive to head off fraud attempts and avoid disgruntled members of the public.
You can now see the activity when it occurs and formulate a plan with your information security and data protection stakeholders to deal with it.
Even on the occasions where you cannot set a DKIM signature to go with your email (some older mail servers and applications simply cannot handle DKIM), you will still benefit from seeing the DMARC reports.
Even the best ISMS professionals have to handle rejection at some point in their career. Thankfully with DMARC rejection is a positive thing. The “p” value is mandatory as it tells others how to handle messages that fail DMARC authorisation processes. There are only 3 options to consider:
The general advice, is to start with “none” until you begin to receive and understand DMARC reports. Only when reports have been analysed and understood should the policy be set to “quarantine”.
When a message claims to be from your “domain.com” and fails the DMARC checks, then it will be quarantined to the percentage value that you set. The example below instructs quarantining 20% of the time (or any value you choose) so that messages can be reviewed by the recipient.
“v=DMARC1; p=quarantine; pct=20; rua=mailto:email@example.com”
The quarantined report messages are posted to the mailbox of the sender in the “rua” value in our example. In the real world of the email recipient, the message is likely to end up in their “junk” folder.
You should only set the policy to “reject” once you are confident that you have identified all of your domains that legitimately send email on your behalf. Be aware that these may be infrequent, such as a Christmas email message marketing campaign that goes out each year. DMARC caters for the gravity of this policy by allowing you to set a percentage, so that the rule is only applied to a subset of messages initially.
Setting the policy to “reject” is something to consider carefully as you are effectively telling a recipient to not even accept a message that fails the DMARC authentication checks. If you move to “reject” too early, you risk turning off the next payroll run notifications, the latest customer update messages, or the efforts by the marketing department, just as much as you will counter the activities of any attackers that happen to spoof your identity.
For Sandfordshire Police, a “reject” rule will look like this:
“v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org”
DMARC has a set of frequently asked questions including the incremental adoption of DMARC rejection.
Whilst you can manually review DMARC reports as they come in, this involves opening extensible Markup Language (XML) files and reading lines of laborious text. Because the XML data is received in a standard DMARC format, for those with a protective monitoring or SIEM solution it should be easy to collect and analyse DMARC reporting as another valuable source of security information.
DMARC information should be used for correlation and alerting against other systems within your network (a phishing campaign might be followed by an increase in unusual logins or account takeover activity). When DMARC reporting is received, you could consider using your SIEM to visualise and alert on spoofing and authentication failures that are being reported back to you.
This will be useful for monitoring the wider risk profile and convincing stakeholders of the value to get all of your legitimate domains into your DMARC approach, eventually getting to a correct “reject” policy and protecting your identity.
Good practice is to start DMARC adoption slowly and incrementally. If your domain admin has not heard about DMARC yet then give them this link: https://dmarc.org
This is the DMARC community site that goes into deeper configuration, filtering detail and scenarios.
The process to deploy DMARC is summarised as follows:
Here is a summary of the ISMS benefits and considerations that DMARC supports:
A recent KPMG Report suggests that protecting against and dealing with cyber risks will be the major challenge for senior executives in 2024. It is clear that despite high levels of security investment, organisations continue to suffer from cyber attacks.Read more
The Australian Signals Directorate’s (ASD) recent publication of their Cyber Threat Report 2022-2023 unearthed a range of areas for concern for government departments and critical infrastructure entities at local, State and Federal level.Read more
As cyber risks increase, organisations are encountering the longer life cycle of insurance renewals and the need to demonstrate better management of security controls and their effectiveness.Read more
Highlights and insights from the recent Managed Services Summit in London & the ISACA Central Chapter Conference on Digital Trust, in Birmingham, UK. With two recent conferences in the space of three days, some interesting challenges were very evident in the topics discussed. Being very different events, the challenges were quite different, but interestingly they […]Read more
In early August 2023, the latest joint advisory on persistent vulnerabilities was issued by the intelligence and security agencies of the “Five-eyes” community. These joint advisories are becoming more common. Perhaps recognising the growing importance of shared security information and the common nature of many of the threats faced – the weight they carry makes […]Read more
The quality of your risk assessment and the security information it provides is important; if you plan to use it to actively manage your operational and cyber resilience activities. Organisations are constantly exposed to a rapidly changing threat environment, so you really need a similarly rapid evidence-based feedback system that informs you of the ongoing […]Read more
The UK market has its own regulators, security standards and challenges. And while rulings from SEC in the US or the Australian Prudential Regulation Authority (APRA) in Australia don’t apply to UK companies, for the most part, the observations are undoubtedly relevant and the resulting advice instructive. It would be wrong to think UK financial […]Read more
<<< Part 2a: Australia’s Essential Eight: Beyond Endpoint Control <<< Part 2b: Activating UK NCSC & US NIST Guidelines: Beyond Endpoint Control Part 4: Systematic Measurement of Cyber Controls >>> As much as we invest into cyber security controls, external threats are inevitable. In a recent Notifiable Data Breaches Report from the Office of the […]Read more
Keen campers, scouts and even the Swiss Army know – that a good penknife is indispensable. This simple device has mitigated many a disaster at one point in time or another. Whether it’s to cut through a bit of string, tighten a screw or simply to solve the problem of no bottle opener in the […]Read more
Supply chain risk is an area of cyber security that demands the ongoing attention of every enterprise; because it can make the difference between being resilient or not. It’s no surprise that insurers warn that the vulnerability of supply chains is potentially a systemic risk that can quickly propagate across supply chain dominated industries. Organisations […]Read more
Read by directors, executives, and security professionals globally, operating in the most complex of security environments.