POPIA, Email Security and DMARC: A Technical Perspective

South African organisations often ask whether DMARC is required by the Protection of Personal Information Act (POPIA). The short answer is no: POPIA does not name or prescribe DMARC.

DMARC can nevertheless form part of a broader email-security programme. It helps a domain owner understand and control how participating receiving systems handle messages that use the domain in the visible From address. That is useful, but it is much narrower than POPIA compliance.

This article provides technical context, not legal advice. An organisation should obtain appropriate legal or compliance guidance for its own obligations and circumstances.

What POPIA says about safeguards

Section 19 of POPIA addresses security safeguards for personal information processed by a responsible party. In broad terms, it requires appropriate, reasonable technical and organisational measures and an ongoing process of identifying risks, maintaining safeguards, verifying their effectiveness, and updating them where needed.

The authoritative text is the Protection of Personal Information Act 4 of 2013. The Information Regulator publishes regulatory information and guidance.

The Act is risk-based rather than a checklist of named email technologies. Whether a particular control is appropriate depends on the organisation’s processing, systems, threats, contractual arrangements, and other relevant circumstances.

Where DMARC fits

DMARC is a domain-published email-authentication policy and reporting mechanism. It builds on SPF and DKIM and checks whether an authenticated domain aligns with the domain visible to the recipient in the From address.

Used carefully, DMARC can support:

• visibility into services sending with an organisation’s domain;
• investigation of SPF or DKIM alignment gaps;
• a documented process for authorising and removing sending services;
• a receiver-facing policy for messages that fail DMARC; and
• ongoing evidence about participating receivers’ observations.

Those capabilities can contribute to risk management around exact-domain impersonation and email operations. They do not establish that an organisation complies with POPIA.

What DMARC does not cover

DMARC is not a complete email, privacy, or information-security control. It does not by itself:

• protect mailboxes against account takeover;
• inspect attachments, links, or message content;
• encrypt personal information in storage or in transit;
• stop lookalike-domain or display-name impersonation;
• govern access to customer records;
• define retention, deletion, or lawful-processing practices;
• manage incidents or regulatory notifications; or
• demonstrate that every organisational safeguard is appropriate and effective.

A message can pass DMARC and still be unwanted or harmful. A message can also fail DMARC because of forwarding or an incorrect legitimate configuration. Receivers retain discretion over final handling.

DMARC as one part of a wider programme

An organisation’s security measures may span several layers. Depending on its risk assessment, these can include:

• strong identity and mailbox-access controls;
• secure administration and change management;
• endpoint, link, attachment, and inbound-message protection;
• encryption and secure data-transfer practices where appropriate;
• supplier and processor governance;
• logging, monitoring, response, and recovery procedures;
• staff awareness and operational processes; and
• SPF, DKIM, and DMARC for authorised outbound email.

This list is illustrative, not a legal checklist. The relevant measures and evidence should follow the organisation’s actual processing and risk context.

A defensible technical workflow

1. Record the scope and ownership

List domains used for email, identify their owners, and document who may approve DNS or sender changes. Include domains that do not intentionally send mail, because their policy choice still needs an owner and a reason.

2. Inventory legitimate sending services

Map business mail, marketing platforms, support systems, billing tools, and other approved senders. Do not infer authorisation from a single DNS record alone; confirm the business owner and provider configuration.

3. Establish authentication and reporting

Configure SPF and DKIM according to each provider’s current documentation, then publish a DMARC record with an authorised aggregate-report destination. Validate the syntax and DNS result before relying on it.

4. Review evidence and correct alignment

Use aggregate reports and message samples to identify legitimate sources that pass or fail alignment. Resolve the underlying configuration where possible. Keep a change record showing the evidence, decision, owner, and rollback plan.

5. Progress policy based on evidence

Move beyond monitoring only when the organisation understands its important sending paths and has assessed likely delivery effects. There is no universal timetable. Continue reviewing reports after any policy change.

6. Reassess the control

New providers, DNS changes, acquisitions, and abandoned services can alter the domain’s sending surface. Periodic review helps determine whether the configuration still reflects the organisation’s authorised use.

Evidence to retain

Useful operational evidence can include:

• the domain and sender inventory;
• approved DNS changes and validation results;
• report-derived findings and remediation tickets;
• policy-change decisions and rollback criteria;
• ownership and review records; and
• exceptions with their rationale and expiry or review date.

These records can show that a technical process occurred. They are not, on their own, proof of legal compliance or a substitute for the organisation’s wider governance evidence.

Questions to ask a service provider

If DMARC is managed by an MSP or specialist provider, ask:

1. Which domains and report sources are in scope?
2. How are legitimate senders confirmed with the customer?
3. Who can approve DNS and policy changes?
4. What evidence supports each proposed policy step?
5. How are report data, access, retention, and deletion handled?
6. How are incidents, exceptions, and handover managed?
7. Which activities remain the customer’s responsibility?

Clear answers help separate a technical service from broader legal assurances that the service cannot make.

Frequently asked questions

Does POPIA require DMARC?

POPIA does not name DMARC. The appropriateness of DMARC as a control should be considered in the organisation’s broader risk and safeguards process.

Does a p=reject policy prove compliance?

No. It is a domain-owner request to participating receivers for DMARC failures. It does not assess the organisation’s other technical and organisational measures.

Is a DMARC report a compliance report?

No. An aggregate report describes authentication observations made by a participating receiver. It is useful operational evidence, but it is not a legal opinion, audit result, or compliance certificate.

Can DMARC protect personal information sent by email?

DMARC authenticates aligned domain use; it does not encrypt message content or decide whether personal information should be sent. Content protection and data-handling decisions require other controls.

Next step

Use the Vigil DMARC checker for a point-in-time view of public email-authentication records, then discuss the operational context with your internal team or contact Vigil. Treat the result as technical input, not a POPIA assessment.