Marketing & Operations
Claudia Sterling
Your domain can be forged in a phishing email without a single system being hacked. DMARC exists to stop that, and after a major update to the standard this year, it's worth understanding properly.
What DMARC actually stands for, and why it exists
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Underneath the acronym is a much simpler idea: email was never built with a reliable way to prove who actually sent a message. Anyone can type any name and any domain into the “From” field of an email, and for most of the internet’s history, nothing stopped them.
That gap is exactly what phishing and business email compromise rely on. An attacker doesn’t need to breach your systems to send an email that looks like it came from your finance director or your own domain. DMARC exists to close that gap, by giving receiving mail servers a way to check whether a message genuinely came from where it claims to.
A brief history of DMARC
DMARC didn’t appear in isolation. Two earlier standards laid the groundwork. SPF, Sender Policy Framework, arrived in the early 2000s and let a domain publish a list of servers allowed to send mail on its behalf. DKIM, DomainKeys Identified Mail, followed shortly after, adding a cryptographic signature that proves a message wasn’t altered in transit. Both were useful, and both had the same weakness: neither told a receiving mail server what to actually do when a message failed the check, and neither reported back to the domain owner about what was happening.
DMARC was developed from around 2011 by a group of major email and technology providers, including PayPal, Google, Microsoft and Yahoo, who were dealing with large scale phishing campaigns spoofing their domains. It was formally published as RFC 7489 in 2015, an Informational standard that tied SPF and DKIM together, added a clear policy instruction (monitor, quarantine or reject) and introduced reporting so domain owners could see exactly who was sending mail as them.
Adoption was gradual for years, then accelerated sharply when Google and Yahoo introduced bulk sender requirements in 2024, effectively making DMARC compulsory for anyone sending meaningful volumes of email to Gmail or Yahoo addresses. What had been best practice for security teams became a practical requirement for getting email delivered at all.
In May 2026, DMARC went through its biggest revision since it was first published. The update, known as DMARCbis, was released as three separate standards, RFC 9989, 9990 and 9991, replacing the original RFC 7489 and promoting DMARC from an Informational standard to a full Proposed Standard, the IETF’s way of confirming a protocol has proven itself in over a decade of real world use. The changes include replacing the old Public Suffix List with a more accurate DNS based method for working out an organisation’s domain, retiring a handful of underused tags, and adding new ones to support more deployment scenarios. Existing DMARC records are unaffected. Anything already published with v=DMARC1 continues to work exactly as before.
Why DMARC matters more than ever
Domain spoofing is still one of the most effective tricks in a phisher’s playbook, precisely because it exploits trust rather than technology. An email that appears to come from your own domain, or from a supplier your team deals with every day, bypasses the natural scepticism people apply to obvious scams. Without DMARC, there’s very little stopping that impersonation from reaching an inbox looking entirely genuine.
It’s also increasingly a deliverability issue, not just a security one. Major mailbox providers now treat unauthenticated mail with growing suspicion, and a domain without a properly configured DMARC record can find its own legitimate emails landing in spam, or being rejected outright. A missing or misconfigured record doesn’t just leave you exposed. It can quietly damage how your genuine emails perform too.
SPF, DKIM and DMARC: how the three fit together
These three standards are often mentioned in the same breath, and each plays a distinct role.
SPF is a DNS record listing exactly which mail servers are allowed to send email on your domain’s behalf
DKIM adds a cryptographic signature to outgoing mail, proving it genuinely came from your domain and wasn’t altered in transit
DMARC sits on top of both, telling receiving mail servers what to do when a message fails SPF or DKIM alignment, and asking for reports so you can see exactly who is sending mail as you
None of the three works particularly well on its own. Together, they turn email authentication from a guessing game into something that can actually be verified.
How we set this up for every client we onboard
Getting DMARC right isn’t just about publishing a record and walking away. Done carelessly, an aggressive policy can silently block genuine invoices, newsletters, or systems your business depends on. As part of onboarding every new client, we follow the same careful sequence.
Audit existing DNS records to find any SPF, DKIM or DMARC configuration already in place, including legacy or forgotten entries left behind by old systems
Correct and consolidate SPF records, since a domain can only have one, and overlapping or duplicate SPF records are a common cause of authentication failures
Enable DKIM signing on every legitimate sending platform, from the primary mailbox provider through to marketing tools, finance systems and any third party service sending on the client’s behalf
Publish a DMARC record starting in monitoring mode, so we can see exactly what is sending mail as the domain before enforcing anything
Review the reporting data together with the client, identify anything genuine that is failing authentication, and fix it at the source
Move the policy forward in stages, from monitor to quarantine to reject, only once we are confident every legitimate sender is correctly authenticated
That staged approach is the part most often skipped, and it’s the part that matters most. Jumping straight to a reject policy without visibility into what’s actually sending mail on your domain is how legitimate email quietly starts disappearing.
Not sure where your own domain stands?
If you are not sure whether SPF, DKIM and DMARC are set up correctly on your domain, try our free email deliverability checker. It takes a minute to run and will pinpoint exactly where authentication is missing or misconfigured.
If it flags anything, that is exactly the kind of thing worth talking through with whoever manages your IT, before it becomes a phishing incident or a delivery problem rather than a quick fix.
