Understanding DMARC

Email marketing is hardly new, but more and more organisations are using it actively, and the volume shows it: around 300 billion emails are sent and received worldwide every day.

With that volume comes a growing need for security. One of the measures available is DMARC, which reduces the risk of your organisation being abused in a spoofing attack.

When we talk to customers about the benefits of setting DMARC up, people generally see the point straight away. Getting it done is where organisations stall, because it looks complex and difficult.

This post is an attempt to take the mystery out of it: what DMARC is, why it matters, and how to put it in place on your domain.

What DMARC is, and why it matters

Most of us have had the email from a parcel carrier saying a delivery is waiting and all we need to do is click a link. It is a spoofing attempt, where criminals pose as an established company and use its credibility to get you to react.

Several measures exist to keep your organisation from being used in an attack on trusting people.

First there is your Sender Policy Framework (SPF), which tells receiving systems that your email platform is allowed to send on your behalf — that is, on behalf of your domain. If you use Ubivox to send newsletters, the receiving server sees Ubivox attempting to send using your domain, and your SPF record is what says you approved it. There is more in our post on why SPF matters and how to set it up.

Then there is DomainKeys Identified Mail (DKIM), which adds a digital signature to every message. The signature shows the receiving server that the message is authentic. In 2024 both Gmail and Yahoo made SPF and DKIM a requirement for bulk senders who would rather not land in spam. Most email platforms, including ours, had required them long before that.

But what happens when a receiving server sees mail from you, or appearing to be from your domain, that does not line up with your SPF or DKIM?

That is where Domain-based Message Authentication, Reporting and Conformance (DMARC) comes in.

First, your DMARC record tells the receiving server what to do when someone — another organisation, or a criminal — tries to push messages that look like yours past the SPF and DKIM checks. There are three options:

  1. Let the message through anyway (none)
  2. Put it in the spam folder (quarantine)
  3. Reject it outright (reject)

Second, you can set DMARC up so you are told when unauthorised mail has been sent that appears to come from your domain — in other words, when your brand is being used in a spoofing attack. Those notifications usually arrive as daily reports.

Setting DMARC up

In practice, DMARC is a record in your DNS. How you reach and change your DNS varies a good deal depending on your provider. If you are unsure where to find it, ask your provider’s support; they can tell you exactly how it works in your case.

The record you add depends on which policy you want. Once DMARC is in place, several tools help you monitor and report on the activity, so you keep an overview and the reports do not get lost in your inbox. EasyDMARC is one we are happy to recommend.

Policy: none

The first policy tells the receiving server to take no action — to let the message pass. It is reasonable to wonder what the point is if it does nothing.

The answer is that you still receive your DMARC reports and can react when something irregular shows up. From there you can consider tightening. The advantage is that you run no risk of legitimate mail being filtered or blocked by mistake. For a smaller organisation not obviously in the firing line for spoofing, this is a sensible place to be. Larger and better-known brands tend to be hit harder by these attacks.

The record looks like this:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

The last part sends the reports to your email address. If you want several people in your organisation to receive them, separate the addresses with a comma.

Policy: quarantine

If you need something stricter, quarantine sends unauthorised mail to the recipient’s spam folder. The advantage is that if legitimate mail of yours is caught by mistake, the recipient can still dig it out of spam.

v=DMARC1; p=quarantine; rua=mailto:you@yourdomain.com

Policy: reject

The last and strictest policy is reject. Mail caught by DMARC is blocked outright. The advantage is that the recipient cannot reach it at all — unlike quarantine, where they might find a spoofed message in the spam folder and act on it anyway.

The disadvantage is that legitimate mail of yours can end up blocked, which puts real weight on monitoring the activity so you can act when your own mail is being stopped.

v=DMARC1; p=reject; rua=mailto:you@yourdomain.com

Before you set your policy

Tighten gradually rather than starting at the strictest setting. Going straight to quarantine or reject risks blocking legitimate mail. Monitor the DMARC activity for a period first, then tighten once you have established that everything behaves as it should.

If some of your mail does end up in spam or rejected, you will be told — but it also creates clean-up work. Where it matters that the recipient sees the message, you first have to identify who did not get it and then resend, and that can mean a fair amount of manual digging.

If you send through Ubivox

Once DMARC is set up on your domain, reaching DMARC alignment takes one more step in the Ubivox platform. Write to support and we will go through it with you.