6 July 2026

What DMARC is and why your business needs it

Email was born without verifying the sender. SPF, DKIM and DMARC in plain terms, CEO fraud, and operated DMARC reaching 95–100% on managed domains.

With a paper letter, anyone can write your name on the envelope. Exactly the same thing happens with email: SMTP, the protocol that has been moving email across the internet for four decades, was born without any strong mechanism for checking that the sender is who they claim to be. Any server in the world can send a message today claiming to come from your domain. And if nobody checks it, the recipient will see it as yours.

SPF, DKIM and DMARC exist to close that hole. They are three checks that the server receiving an email applies before delivering it, and each one answers a very specific question:

  • SPF asks: is this server authorised to send email on behalf of this domain? The domain’s owner publishes in DNS — the internet’s public directory — the list of servers that may send for it.
  • DKIM asks: does the message come signed, and has it arrived unaltered? The sending server adds a cryptographic signature: a seal that breaks if anyone modifies the content along the way.
  • DMARC asks the decisive question: does what was validated match the domain the user sees in the “From:” field? Because a message can pass technical checks and still show a fake sender. And if there’s no match, DMARC defines what to do with it — accept it, quarantine it or reject it — and who to notify of every attempt.

The diagram below shows that whole journey: three checks, three possible outcomes and a report that goes back to the domain’s owner.

Why should this matter to a company director? Because of CEO fraudBusiness Email Compromise: an email that looks like it comes from the managing director asks for an urgent transfer, or a long-standing supplier “lets you know” it has changed bank account. And there’s a detail almost nobody knows: in many cases, neither your company nor your supplier’s has been attacked. It’s enough for a third party who took part in the conversation — another company, another person on the thread — to have their mailbox compromised. With that, the attacker knows names, subject lines, invoices and real threads, and builds a convincing deception.

This is where the difference lies between having DMARC and operating DMARC. Publishing three DNS records is only the starting point: a record nobody analyses offers little protection. Every day, the servers that receive email in your domain’s name — Microsoft, Google and thousands more — generate technical reports and send them to the domain’s owner. We receive them and analyse them, with the support of automation and artificial intelligence to classify the volume: we detect spoofing attempts, we find legitimate services that aren’t properly declared — that invoicing or marketing platform sending on your behalf without being authorised — we tighten the policy progressively without blocking legitimate email, and we tell you about it in regular reports you can understand. The result is measurable: on the domains we manage, DMARC protection reaches 95–100% of email.

This applies equally whether your email lives in Microsoft 365 or in our private email. In the second case we go a step further: we cross-check the DMARC reports against the server’s real logs, contrasting what the world’s servers say they saw with what our systems actually sent, received or blocked.

What do you gain? Three concrete things. Your domain stops being usable to deceive your customers and suppliers. Your legitimate email gets delivered better, because correct authentication improves deliverability. And visibility: knowing who sends in your name, from where and with what result.

One final piece of honesty: DMARC doesn’t stop everything. If a legitimate account has been compromised, its messages will authenticate correctly; that’s what other layers are for. Which is why DMARC is one piece — essential, but one piece — of the email security we operate, alongside the defence against CEO fraud, two-factor authentication and forensic analysis.

AN EMAIL ARRIVES 1 · SPF Can this server send on behalf of your domain? 2 · DKIM Is it signed and unaltered? 3 · DMARC Does it match the sender you see in the From:? DELIVERY QUARANTINE REJECTION A REPORT GOES BACK TO THE DOMAIN OWNER
Three questions before the inbox and a return channel: every sending attempt, legitimate or not, is counted in the reports we analyse for the domains we manage.

DMARC operated, not just published: the difference between a DNS record and protection.

The service behind this piece

Email security →
← Back to the blog

Shall we talk about your infrastructure?

An initial audit with no obligation. Tailored solutions, with a single point of contact who knows your business.