POPIA and Email Security: Where DMARC Fits (and Where It Does Not)

POPIA does not mention DMARC, but section 19 requires appropriate, reasonable technical and organisational measures to protect personal information, and email impersonation is a foreseeable route to exposing it. An enforced DMARC policy is a credible, evidence-producing control against spoofing of your exact domain. It is one safeguard within a programme, not compliance on its own.

What POPIA actually asks of you

The Protection of Personal Information Act is principle-based. It does not hand you a checklist of technologies. Section 19 requires a responsible party to secure the integrity and confidentiality of personal information in its possession or under its control by taking appropriate, reasonable technical and organisational measures to prevent loss, damage, unauthorised destruction, and unlawful access to or processing of that information.

The section then describes a process rather than a product. In summary, a responsible party must take reasonable measures to:

1. identify all reasonably foreseeable internal and external risks to personal information;
2. establish and maintain appropriate safeguards against the risks identified;
3. regularly verify that the safeguards are effectively implemented; and
4. ensure that the safeguards are continually updated in response to new risks or deficiencies.

It also requires regard to generally accepted information security practices. That phrase matters for email. When the major mailbox providers began requiring SPF, DKIM and a DMARC record from bulk senders in 2024 and 2025, domain authentication stopped being a specialist topic and became a baseline expectation. Our article on Google, Yahoo and Microsoft sender requirements sets out what changed.

Why email impersonation is a personal information risk

It is tempting to file spoofing under “fraud” and keep it away from the privacy conversation. That separation does not hold up. Consider the common patterns South African organisations face:

• Data requests in your name. A message appearing to come from hr@yourcompany.co.za asks a payroll provider, medical aid broker or a branch office to send employee records or ID copies. The data leaves through a legitimate process because the request looked internal.
• Credential phishing against your own staff. A spoofed internal notice leads staff to a fake login page. A compromised mailbox then exposes every client conversation and attachment it holds.
• Impersonation of you to your clients. Clients receive mail that appears to be from your domain asking them to “verify their details” or update banking information. Their personal and financial information is exposed, and your domain was the instrument. See how spoofing leads to invoice fraud for how these attacks typically unfold.

In each case, an attacker’s ability to send convincing mail as your exact domain is the enabling step. Under section 19’s logic, that makes direct domain spoofing a reasonably foreseeable external risk, and the natural question becomes: what reasonable safeguard did you put in place against it?

Where DMARC fits

DMARC lets you publish a policy telling receiving servers what to do with mail that claims to come from your domain but fails authentication. At p=reject, receivers that honour DMARC refuse that mail outright. It maps onto the section 19 process unusually well.

Two qualifications matter. First, the protective value comes from enforcement. A record at p=none is monitoring only; it tells receivers to deliver spoofed mail as normal. Our article on monitoring-only DMARC explains why that is a starting point and not a safeguard. Second, the evidence trail is a genuine asset. If you ever need to show that you took reasonable steps, a dated history of policy changes, approvals and reports is far more persuasive than “our IT person set something up once”.

Where DMARC does not help

Overselling DMARC does nobody any favours, least of all an Information Officer who has to stand behind the programme. DMARC protects the exact domain it is published on. It does not:

• stop lookalike domains such as yourcompany-za.co.za or yourc0mpany.co.za;
• stop display-name deception, where the visible name says your company but the address is a free webmail account;
• stop mail sent from a genuinely compromised mailbox on your domain, which passes authentication because it is real;
• filter inbound spam, malware or phishing aimed at your own staff from other domains;
• secure data at rest, access control, backups or any of the other areas section 19 covers; or
• make you POPIA compliant. No single technical control does.

What DMARC does is remove the easiest attack and force criminals onto techniques that are easier for people and other controls to catch. That is meaningful, but it is a layer.

The rest of a reasonable email security programme

A defensible position on email combines technical controls with organisational ones. A practical framework for South African SMEs:

Technical

• SPF, DKIM and DMARC at enforcement on every sending domain, with parked domains locked down so they cannot be abused either.
• Multi-factor authentication on every mailbox and administrator account, without exceptions for senior staff.
• Inbound filtering, external sender tagging and attachment controls from your mail platform.
• TLS for mail in transit, and reporting to see when it fails.

Organisational

• Staff training that covers impersonation, not just suspicious links.
• A payment verification rule: any change to banking details is confirmed by phone on a number already on file, never one supplied in the email.
• A named owner for email security decisions, with changes approved and recorded.
• Operator agreements with third parties that send on your behalf, consistent with POPIA’s provisions on operators.
• An incident response plan that people have actually read.

Questions an Information Officer should be able to answer

If the programme is real, the person accountable for it can answer these without phoning IT first:

1. Which domains do we own, and which of them send email?
2. What DMARC policy is each domain on today, and when did it last change?
3. Which third-party services send email as us, and is each one authenticated and covered by an operator agreement?
4. Who approved our current policy, and where is that approval recorded?
5. Who reviews the reports, how often, and what happened the last time something unusual appeared?

The third question deserves emphasis. The inventory of senders that DMARC work produces doubles as a list of operators processing personal information through email on your behalf: your accounting platform, payroll provider, CRM and newsletter tool. Many organisations discover services in their reports that nobody in management knew were sending as the company, which is exactly the kind of foreseeable risk section 19 expects you to identify.

When something goes wrong: section 22

Section 22 requires a responsible party, where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, to notify the Information Regulator and, subject to limited exceptions, the affected data subjects, as soon as reasonably possible after discovery. The notification must contain enough information for data subjects to take protective measures.

Email incidents trigger this more often than people expect. A spoofed request that led staff to send out employee data, or a compromised mailbox containing client records, can both reach that threshold. Two practical points follow:

• Evidence shortens investigations. DMARC reports help establish whether mail claiming to be from your domain actually came from you, which affects how you assess and describe the incident.
• Decisions need owners. Who assesses whether notification is required, who drafts it and who sends it should be settled before an incident, not during one.

This article is general information, not legal advice; speak to a qualified adviser about your organisation’s specific obligations.

MailMarq takes domains from monitoring to enforcement through an evidence-based, written-approval process and produces plain-language reporting that can sit alongside your wider POPIA documentation. We do not sell compliance, and we will tell you plainly what DMARC covers and what it does not. Start with a free assessment through our contact page, or read how it works.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.