Move from explanation to action with the matching DomainCheck.co.uk tools for this topic.
Confirm the domain is resolving cleanly before troubleshooting email delivery.
Useful when auditing email-related domains across many records or assets.
Escalate when email setup touches DNS, registrar access, and live business mail.
DMARC is usually explained as the third part of email authentication, but it does a different job from SPF and DKIM. SPF says which servers may send mail. DKIM signs the message. DMARC tells receiving systems what to do when authentication fails and whether the domain owner wants enforcement. This article exists separately because beginners often need a clear explanation of DMARC’s role before they can make sense of the comparison article. It also deserves its own guide because DMARC has business implications: it affects spoofing protection, reporting, and how strictly mailbox providers can treat mail that fails authentication.
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. That name is longer than the idea itself. In plain English, DMARC is a set of instructions published in DNS that tells receiving mail systems how to handle messages claiming to come from your domain.
It sits on top of SPF and DKIM. On its own, DMARC does not replace them. Instead, it checks whether at least one of those authentication methods passes in a way that aligns with the visible From: address. If not, DMARC can ask the receiving system to do something stricter, such as quarantine the message or reject it.
One of the biggest email problems is spoofing. A bad actor can send a message that looks like it came from a real company or organisation. That message may appear to come from a trusted domain even if the sender has nothing to do with that business.
DMARC helps domain owners say, “If a message is claiming to be from us, here is how it should be authenticated, and here is what you should do if it is not.”
That does not make spoofing impossible. But it gives mailbox providers a clearer signal and gives businesses a practical way to reduce abuse of their domain names.
DMARC relies on two things:
If the message passes DMARC, the provider has one more reason to trust it. If it fails DMARC, the published policy tells the provider whether to do nothing, move the message to spam, or reject it outright.
The policy is usually set with a TXT record under dmarc.yourdomain.co.uk. The record includes a p= value that defines the action. Common policy values are:
| Policy | What it tells recipients | When it is useful |
|---|---|---|
| p=none | Do not block based on DMARC yet | Good for monitoring and rollout |
| p=quarantine | Treat failures as suspicious | Useful when you are ready to tighten controls |
| p=reject | Refuse mail that fails DMARC | Best once all legitimate senders are covered |
Some organisations start with p=none while they watch reports and make sure all legitimate mail sources are covered. That cautious approach is common because an aggressive policy can block valid mail if a service has been forgotten or misconfigured.
The safest DMARC rollout is usually monitor first, then tighten the policy only after you have confirmed every legitimate sender passes SPF or DKIM with alignment.
If a CRM, helpdesk, or billing platform is sending mail, it should be visible in DMARC reports.
Mail forwarded by another system can fail SPF, so DKIM often becomes the more reliable signal.
A strong DMARC policy helps reduce abuse of your domain name in spoofed messages.
DNS moves can break DMARC if SPF, DKIM, or the DMARC TXT record is not copied correctly.
DMARC does not only care whether SPF or DKIM passed. It also cares about alignment. That means the authenticated domain needs to match, or at least closely match according to the provider’s rules, the domain in the visible From: address.
This is one of the reasons DMARC can feel confusing at first. A message might pass SPF and still fail DMARC if SPF authenticated a different domain than the one shown to the recipient. The same is true for DKIM if the signing domain does not align.
Alignment rules vary slightly depending on the receiving system and the way your sender is configured, so it is wise to check the specific documentation for your email provider. The general idea is simple: DMARC wants the domain the recipient sees to be the same domain that actually authenticated the message.
If you own a business domain, DMARC gives you more control over how your brand is used in email. It can reduce the chance that someone else sends mail pretending to be your company. It also gives mailbox providers a policy to follow, which can improve trust when your setup is correct.
For customer-facing mail, that matters. Invoices, order confirmations, password resets, HR messages, and support replies all depend on the recipient believing the email is genuine. DMARC is one of the signals that helps build that trust.
It is also useful for visibility. DMARC aggregate reports can show which systems are sending mail using your domain, where authentication is failing, and whether a forgotten service is still sending mail on your behalf. That reporting can be noisy, but it is often useful once the volume is manageable.
DMARC is not just a policy switch. It is also a reporting system.
Domain owners can ask receiving systems to send summary reports about mail that claims to come from their domain. These reports can help identify legitimate services, misconfigurations, and possible abuse. They are usually sent as XML, so they are not especially friendly to read by hand, but they are valuable for monitoring.
Not every mailbox provider sends the same level of detail. Reporting behaviour varies, and some providers send more helpful summaries than others. You should treat reports as operational signals, not perfect ground truth.
The most common mistake is publishing a strict DMARC policy before SPF and DKIM are fully mapped. If a legitimate service is forgotten, it may start failing mail once DMARC enforcement kicks in.
Another issue is assuming a p=none policy provides strong protection. It does not. It is mainly for observation. It can be a sensible first step, but it is not the end state if you want real spoofing protection.
People also forget that forwarding services can complicate authentication. A forwarded message may pass through systems that change SPF results or alter the message in ways that affect DKIM. That does not mean DMARC is broken; it means the delivery path is more complex than a simple direct send.
Finally, some organisations set DMARC and then never review the reports. DMARC is most effective when you use it as an ongoing control, especially after adding new tools such as CRMs, ticketing systems, newsletters, or marketing platforms.
| Mistake | Result |
|---|---|
| Turning on reject too early | Legitimate mail can be blocked |
| Ignoring reports | New senders or failures go unnoticed |
| Forgetting alignment | SPF or DKIM may pass but DMARC still fails |
Because DMARC lives in DNS, any DNS migration can affect it. If you move name servers or switch providers, make sure the dmarc record comes across exactly as intended.
If the record disappears or is malformed, mailbox providers may fall back to their own delivery logic. That can make email behaviour look inconsistent. In other words, a DNS change can cause problems that look like “spam issues” even when the underlying problem is simply a missing DMARC record.
DMARC is the policy layer that turns SPF and DKIM into a usable decision. Without the policy, the other checks are less effective on their own.