DMARC p=none Is Not Protection

DMARC p=none and enforcement stages showing no record, quarantine and reject domain protection

A DMARC record is not the same as protection. If your domain is set to DMARC p=none, you are monitoring email activity, nothing more. Receiving mail servers are not being told to block anything.

That gap matters more than most businesses realise. Phishing, domain spoofing, and business email compromise are not abstract threats for South African organisations. They cause operational disruption and reputational damage, and they routinely exploit exactly this kind of misplaced confidence.

Having a DMARC record and having meaningful domain protection are two very different things.

What does DMARC p=none mean?

DMARC is an email authentication standard that works alongside SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Together, they help receiving mail servers verify whether an email is actually authorised to use your domain, and what to do when it is not.

That “what to do” is the policy. It has three settings: p=none, p=quarantine, or p=reject.

At p=none, the domain owner is asking for visibility, not action. In plain terms: tell me what is happening, but do not block anything yet.

Used correctly, p=none is a legitimate starting point. It becomes risky when a temporary monitoring policy turns into the final destination.

Why p=none is useful, but risky if left there

p=none exists for a reason. Before locking down a domain, a business first needs to understand who is actually sending email in its name, and the answer is often more complicated than expected. Marketing platforms, accounting software, external suppliers, and internal teams may all be using the same domain, sometimes without anyone having a full picture of it.

DMARC reports help build that picture. Think of them as a log of every email sent using your domain — who sent it, where it came from, and whether it passed authentication. The catch is that these reports are not easy reading. Without a platform to interpret them, most businesses never act on the data.

Jumping straight to enforcement before that picture is clear is a genuine risk. Legitimate emails — invoices, statements, notifications — can be blocked if the right senders have not been identified and properly configured first.

The monitoring phase is where the work should begin. But if p=none is left in place, reports pile up unread and the domain remains open to abuse while appearing, on paper, to have DMARC in place.

The difference between p=none, p=quarantine and p=reject

The three policy levels are not just technical labels — they produce meaningfully different outcomes.

DMARC p=none: no action is taken. The domain owner receives reports but receiving mail servers do nothing to stop unauthorised emails. The domain is being watched, not protected.

DMARC p=quarantine: suspicious emails that fail authentication are treated with caution. In practice, this usually means they land in spam or junk rather than the inbox.

DMARC p=reject: the strongest setting. Unauthorised emails that fail DMARC checks are blocked outright and do not reach the recipient at all.

This is where enforcement starts to mean something. The domain is no longer just watching what happens. It is telling mail systems what to do about it.

Why DMARC enforcement matters for email impersonation protection

Not all email impersonation works the same way. Some attackers register lookalike domains — swapping a letter, adding a word — and send from there. Others manipulate the display name so an email appears to come from someone familiar, even though the actual address is something else entirely.

DMARC enforcement tackles a specific and serious variant: direct domain spoofing. This is where an attacker sends email using your actual domain — not an imitation of it, but the real thing.

That makes it especially damaging. Your domain carries trust your business has spent years building. A fraudulent email that appears to come from your finance director, your accounts team, or your company address borrows that trust directly. Recipients have no obvious reason to doubt it.

With enforcement in place, receiving mail servers have a clear instruction: if an email using this domain fails authentication, reject it.

DMARC will not stop every phishing attempt. Lookalike domains, compromised accounts, and social engineering sit outside its scope. But it closes one well-used route. For business leaders, it also sends a signal that domain trust is being actively managed, not just assumed.

Why South African businesses should not treat DMARC as a once-off DNS setting

DMARC is not a one-time configuration. It reflects how your organisation sends email, and that changes. New software gets added, suppliers change, campaigns launch, internal teams start using tools that nobody thought to check. Any of these can quietly break authentication for legitimate senders.

This is why ongoing monitoring matters, not just at the start. A domain that passes everything today may have gaps in six months. Without visibility into what is happening, those gaps go unnoticed until something goes wrong.

There is also a governance dimension that South African businesses should not overlook. POPIA does not specify a required DMARC policy, but it does expect organisations to put reasonable security measures in place. A domain sitting permanently at p=none is difficult to defend as a reasonable measure.

DMARC enforcement is not a DNS record you publish and move on from. It is an ongoing control — one that needs to be monitored, reviewed, and progressed deliberately.

Frequently asked questions about DMARC enforcement

Yes, but not by as much as most people assume. A domain with no DMARC record gives you nothing — no visibility, no reporting, no signal to receiving mail servers at all. p=none at least opens the door to understanding what is happening with your domain.

The important qualifier is that visibility is not protection. p=none should be a starting point, not a destination.

Some businesses can, but most should not attempt it without first understanding their sender landscape. If SPF, DKIM, and sender alignment have not been properly configured across every system using your domain, jumping straight to p=reject can block legitimate email — invoices, client communications, automated notifications — before anyone realises what has happened.

The safer approach is to monitor first, identify and fix any issues, confirm that legitimate email is passing cleanly, and then move through p=quarantine before reaching p=reject. It takes longer, but it avoids the kind of disruption that is difficult to explain to a client waiting on a proposal.

No, and it is worth being clear about what it does and does not cover. DMARC enforcement is specifically designed to stop attackers from sending email using your actual domain without authorisation. That is a meaningful protection, but it is one layer, not a complete defence.

Attackers who use lookalike domains, compromised mailboxes, or carefully crafted social engineering operate outside DMARC’s scope. Those threats require awareness training, mailbox security, and broader risk controls. DMARC does its job well — the mistake is expecting it to do every job.

For most businesses, the goal is p=reject. It gives receiving mail servers the clearest possible instruction and provides the strongest protection against direct domain spoofing.

That said, the best policy at any given moment depends on where a business actually is in its configuration. A domain that is not yet ready for p=reject will cause more problems than it solves if enforcement is rushed. The right question is not just where you want to end up, but whether your current setup can support getting there without disrupting legitimate email along the way.

There is no single answer, but for most businesses the journey from p=none to p=reject takes between 30 and 90 days. The variable is not the technical setup — it is how long it takes to identify every legitimate sender using your domain and confirm that their email is passing authentication correctly.

Organisations with a simple email setup and a clear picture of their senders can move quickly. Those with multiple systems, third-party platforms, or legacy configurations typically need more time. Rushing the process to hit an arbitrary deadline is how legitimate email gets blocked. The goal is to get there confidently, not just quickly.

When a domain is at p=reject, receiving mail servers are instructed to block any email that fails DMARC authentication outright. The email does not reach the inbox, the junk folder, or anywhere else — it is rejected at the server level before delivery is attempted.

For legitimate email, this is why correct configuration matters before moving to enforcement. For attackers trying to spoof your domain, it means their emails hit a hard stop. That is the point of enforcement — not to filter suspicious email into a folder, but to prevent unauthorised email from being delivered at all.

How ARMD.digital helps businesses move safely towards enforcement

The path to full DMARC enforcement is not complicated, but it does require the right skill set and needs to be done in the right order. Visibility first, then correction, then enforcement.

In practice that means identifying every sender using your domain, fixing SPF and DKIM alignment where needed, and confirming that legitimate email continues to deliver correctly at each stage. Rushing the process is how organisations end up blocking their own email.

ARMD.digital supports this process through a managed implementation service, helping businesses implement, monitor, and progress their domains safely towards full DMARC enforcement at p=reject within 90 days.

A domain sitting at p=none has made a start, but a start is not protection. If the policy has not moved in months, the monitoring is not being acted on and the domain remains exposed in ways that are entirely straightforward to address.