What Is DMARC, and Why Did Someone Just Tell Me I Need One?
Someone told you your domain needs DMARC and did not explain why. Here is what it actually does, what happens without it, and how to check yours free in a minute.
DMARC usually arrives in your life sideways. An insurer asks for it on a form. A customer's IT department says your mail is failing their checks. Your own email starts landing in spam and someone mentions it in passing. Nobody explains what it is, and the explanations you find online are written for people who already know.
So here is the plain version, and a way to see where your domain stands without installing anything.
The problem DMARC exists to solve
Anyone can send an email that says it is from you.
Not hack your account — just write your address in the "from" line. Email was designed in a more trusting era and never had a built-in way to prove the sender is who they claim. That is why invoice fraud works: a message that appears to come from your company, to your customer, with different bank details on it.
Two earlier fixes took a run at this. SPF publishes a list of the servers allowed to send mail for your domain. DKIM adds a cryptographic signature that proves a message really came from you and was not altered on the way.
Both are useful, and both have the same hole: they tell a receiving mail server whether a message passed or failed, and then say nothing about what to do next. A failed message might be a forgery. It might be your own newsletter tool that nobody added to the list. The receiving server has to guess.
DMARC is the instruction that closes the gap. It is a record on your domain that says: when a message claiming to be from us fails those checks, here is what I want you to do about it — and please tell me it happened.
What it actually does, in three parts
It sets a policy. You choose one of three: none (do nothing, just tell me), quarantine (put it in spam), or reject (refuse it outright). That single word is the whole enforcement mechanism.
It sends you reports. This is the part almost nobody expects and the part with the most immediate value. With DMARC in place you start receiving summaries of who is sending mail using your domain. Most businesses discover two or three legitimate systems they had forgotten about — and occasionally something they very much did not authorise.
It requires the from address to match. DMARC checks that the address your recipient sees lines up with the domain that passed the underlying checks, which closes a loophole where a message could technically pass while still displaying somebody else's name.
What happens if you do not have one
Three things, in rough order of how quickly they will bite.
Your legitimate mail is trusted less. The large inbox providers increasingly expect domains that send any real volume to have this in place, so the absence itself is a small negative signal.
Anyone can forge your domain with no consequence, and you will not know until a customer forwards you something alarming.
And you will start failing other people's requirements. Insurers, larger customers and procurement processes ask about it now. This is the reason most people arrive at the subject.
How to check yours
You do not need anyone's permission to look — these records are public by design.
Run the DMARC Checker on your domain. It reads your DMARC record along with SPF and DKIM, tells you whether they exist, whether they agree with each other, and what your policy is currently set to. Complimentary, about a minute, no signup.
For the wider picture — whether your mail is likely to reach the inbox at all — the Email Deliverability Test grades the whole setup end to end. If you only run one, run that one.
Setting it up without breaking your own email
Here is where enthusiasm does real damage, so it is worth being blunt.
Do not start at reject. A DMARC policy set to reject before SPF and DKIM are complete will stop your own legitimate mail — the invoices from your accounting software, the confirmations from your booking system, anything sending on your behalf that nobody remembered to authorise. This failure mode is common, it is immediate, and it is entirely avoidable.
The sequence that works:
- Get SPF right first. List every system that sends mail as you. Walk through your software and write them down before touching anything.
- Turn DKIM on. Most providers support it and plenty of accounts simply have it switched off.
- Publish DMARC at none. It changes nothing about delivery and starts the reports flowing.
- Read the reports for a few weeks. You are looking for legitimate senders you missed. This is the entire point of the exercise.
- Move to quarantine, then reject. Only once the reports are clean.
Weeks, not an afternoon. The waiting is not padding — it is how you find the system you forgot.
The version where somebody else holds this
None of the above is difficult, exactly. It is fiddly, it is unforgiving of small mistakes, and the consequence of getting it wrong is that your own mail stops arriving, which you may not notice for days.
On managed Microsoft 365, these records are configured when your mail is set up and kept current as your software changes, because we are the ones making the changes. The reports are watched rather than delivered to a mailbox nobody opens. When something new starts sending as you, that is a case with a person on it, not a mystery you solve at the weekend.
Email starts at $6 per user per month with migration included, which for most small teams is less than the afternoon this would otherwise cost.
Start with the check. Run the DMARC Checker and see what your domain currently says. If the answer is "no record found," you now know exactly what that means and roughly what to do about it — and, importantly, what not to do first.