DMARC Explained: A Complete Guide for South African Businesses

Email is the single most abused channel in cybersecurity. According to the FBI’s 2024 Internet Crime Report, Business Email Compromise (BEC) alone caused over $2.77 billion in adjusted losses globally, across more than 21,000 reported complaints. South Africa is not insulated from this — a Positive Technologies study found that 22% of all cyberattacks targeting African countries hit South Africa, more than any other nation on the continent.

For a South African business, one forged email can redirect a supplier payment, damage a brand built over years, or expose customer data in breach of the Protection of Personal Information Act (POPIA). DMARC is the technical control that stops domain spoofing at its source — and yet only a small fraction of domains have actually deployed it at enforcement.

This guide explains, in plain language, what DMARC is, how it works with SPF and DKIM, why it matters specifically for South African organisations, and how to roll it out safely without breaking legitimate email.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol published as an open standard in RFC 7489. It builds on two older protocols — SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) — and adds two critical things they lacked:

1. A unified policy that tells receiving mail servers what to do when an email fails authentication checks (monitor, quarantine, or reject).
2. Reporting — structured feedback reports sent back to the domain owner showing exactly which mail is passing, which is failing, and from which IP addresses.

Without DMARC, SPF and DKIM are passive. A receiving server may check them, but it has no standardised instruction on how to respond to a failure, and the domain owner is blind to the outcome. DMARC closes both gaps.

The three DMARC policies

DMARC defines three policy levels, set with the p= tag in the DNS record:

Policy	Tag	What receivers do with failing mail
None	p=none	Deliver the mail normally, but send reports. Monitoring mode.
Quarantine	p=quarantine	Send failing mail to the spam or junk folder.
Reject	p=reject	Refuse the failing message outright at the SMTP gateway.

p=reject is the only policy that actually blocks spoofed email. The other two are stepping stones on the way there. Reaching p=reject safely is the end goal of any DMARC deployment — and the hardest part.

Why DMARC matters for South African businesses

South African organisations face a combination of factors that make email authentication particularly urgent:

• High attack volume. South Africa is the most-targeted country for cyberattacks in Africa, accounting for roughly 22% of attacks on the continent. Email is the primary delivery vector.
• Payment redirection fraud. Business Email Compromise — where an attacker spoofs a trusted supplier or executive to redirect an EFT payment — is widespread in the South African mid-market. A single successful attack can cost hundreds of thousands of Rand.
• Bank and SARS impersonation. Phishing campaigns routinely spoof South African banks, SARS, and major retailers. Customers lose trust in a brand that allows its domain to be used this way.
• POPIA compliance. The Protection of Personal Information Act requires “appropriate, reasonable technical and organisational measures” to secure personal information. Email is personal information in transit, and an unauthenticated domain is a demonstrable security gap that an Information Regulator investigation would flag.
• Deliverability. Gmail and Yahoo implemented stricter sender requirements in 2024 that effectively require DMARC for bulk senders. Without it, your legitimate mail is more likely to land in spam — even mail you send to your own customers.

The bottom line: for a South African business, DMARC is simultaneously a security control, a compliance measure, and a deliverability requirement.

How SPF, DKIM, and DMARC work together

DMARC is not a standalone protocol. It is a policy layer that evaluates the results of SPF and DKIM authentication. To understand DMARC, you need to understand its two prerequisites.

SPF — “which mail servers are allowed to send for this domain?”

SPF is a DNS TXT record that lists the IP addresses and servers authorised to send email on behalf of your domain. When a receiving server gets a message claiming to be from yourdomain.co.za, it looks up your SPF record and checks whether the sending server’s IP is on the list.

A typical SPF record looks like this:

yourdomain.co.za.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.mailchimp.com ~all"

• v=spf1 marks this as an SPF record.
• include: pulls in the authorised server lists from other providers (your email host, your marketing tool, your ticketing system).
• ~all (soft fail) or -all (hard fail) is the catch-all for anything not listed.

A common trap: SPF has a hard limit of 10 DNS lookups. Each include, redirect, mx, or a mechanism counts as a lookup. If you stack too many third-party senders, your SPF record will silently fail — called a “permerror.” This is one of the most common causes of legitimate mail failing DMARC.

DKIM — “did this message come from who it says it did?”

DKIM adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key; the receiving server verifies the signature using the corresponding public key published in your DNS.

A DKIM DNS record looks like this (the selector lets you host multiple keys):

selector1._domainkey.yourdomain.co.za.  IN  TXT  "v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM survives forwarding (SPF does not), which is why having both is important — DMARC passes if either SPF or DKIM aligns.

DMARC — the policy and the alignment

DMARC takes the results of SPF and DKIM and applies one more check: alignment. The domain in the visible From: address must match the domain that passed SPF or DKIM. This prevents the classic attack where a spammer passes SPF for spammer.com but sends mail with a From: ceo@yourdomain.co.za header.

A minimal DMARC record:

_dmarc.yourdomain.co.za.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.co.za;"

• p=none — start in monitoring mode.
• rua= — the address that receives aggregate reports (XML summaries of authentication results, sent daily).
• ruf= (optional) — the address for forensic reports (copies of individual failing messages).

A step-by-step DMARC setup guide

A safe DMARC rollout is incremental. Rushing straight to p=reject will break legitimate mail. Follow this sequence.

Step 1: Inventory every sender

Before touching DNS, list every system that sends email as your domain. Common ones:

• Your primary email host (Google Workspace, Microsoft 365, HostAfrica, Afrihost)
• Marketing and newsletter tools (Mailchimp, Sendinblue/Brevo, Dotdigital)
• Billing and accounting systems
• CRM or ticketing platforms (Zendesk, Freshdesk)
• Website contact forms and server notifications
• Third-party SaaS apps that send on your behalf

Check the billing, HR, and support teams — they often use tools IT does not know about. This inventory is the foundation; a wrong list is the most common reason rollouts stall.

Step 2: Publish SPF and DKIM

Configure SPF to authorise all senders from your inventory, and enable DKIM signing on every platform that supports it. Most modern providers publish setup guides — Google Workspace, Microsoft 365, and Mailchimp all have step-by-step DKIM instructions.

Verify with a free DNS lookup tool before proceeding. Your SPF record must resolve without a “permerror,” and DKIM signatures must validate on test emails sent through each provider.

Step 3: Publish DMARC in monitoring mode

Add your DMARC record with p=none:

_dmarc.yourdomain.co.za.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.co.za; fo=1;"

At this stage, nothing is blocked. You are collecting data.

Step 4: Collect and analyse reports

Aggregate reports (sent daily as XML attachments) show every source sending mail as your domain, with SPF and DKIM results for each. This is where you discover:

• Authorised senders you forgot to add to SPF (shows up as SPF failures on legitimate mail).
• Third-party platforms that need DKIM enabled.
• Malicious spoofing already in progress — unknown IPs sending mail as your domain.

Parse the reports — manually at first, or with a monitoring service — until 100% of your legitimate mail passes authentication and the only failures are genuine spoofing attempts.

Step 5: Move to quarantine

Once you are confident legitimate mail passes, move to p=quarantine. Failing mail goes to spam rather than the inbox. Monitor for a few weeks; if real mail starts landing in junk, you have a sender you missed — fix it and continue.

Step 6: Move to reject

When quarantine is stable with no false positives, move to p=reject. This is the enforcement state where spoofing is actually blocked at the gateway. Keep reporting on so you can spot new legitimate senders the moment they are added.

A realistic timeline from p=none to p=reject for a business with a handful of senders is 4 to 8 weeks. Complex environments with many legacy systems can take months. The duration is a feature, not a failure — it is the time required to be certain you will not break mail.

Common DMARC mistakes

• Starting at p=reject. This blocks legitimate mail from day one. Always start at p=none.
• Ignoring reports. p=none does nothing on its own — its value is the data. If nobody reads the reports, you are stuck.
• The 10-lookup SPF limit. Stacking include statements past 10 lookups causes a silent SPF “permerror” that fails all your mail. Use SPF flattening or reduce redundant includes.
• Forgetting third-party senders. The invoice system, the HR platform, the marketing tool — each one that sends as your domain must be in SPF and signed with DKIM, or it fails DMARC.
• No DKIM at all. SPF alone is fragile (it breaks under forwarding). DKIM is what keeps your mail authenticating reliably across the open internet.
• Subdomain blindness. DMARC policy on the organisational domain does not automatically protect subdomains unless you set sp= (subdomain policy). Spoofers target support.yourdomain.co.za precisely because owners forget it.
• Treating DMARC as set-and-forget. Every time your business adds a new SaaS tool that sends email, DMARC must be updated. A monitoring service or dashboard catches this automatically.

Monitoring and enforcement

Reaching p=reject is not the end — it is the start of ongoing maintenance. Domains are living systems: new senders get added, DNS records drift, and attackers constantly probe for gaps.

Ongoing DMARC monitoring means:

• Continuous report ingestion — automatically parsing daily aggregate reports so you see every sending source.
• Alerting on new failure sources, so a forgotten sender is caught before it affects deliverability.
• Policy health tracking — watching your pass rate trend over time and spotting regressions.
• Subdomain coverage — ensuring sp=reject is in place so spoofers cannot bypass your main policy via an unprotected subdomain.

This is the gap DMARC Shield fills for South African businesses: it ingests the reports, turns them into plain-English dashboards, alerts you to new senders and failures, and guides you safely from p=none to p=reject — and keeps you there.

The South African regulatory context: POPIA

The Protection of Personal Information Act (POPIA) came fully into force in South Africa in 2021. Section 19 of the Act requires a “responsible party” to secure the integrity and confidentiality of personal information by taking “appropriate, reasonable technical and organisational measures.”

Email is one of the most common carriers of personal information — customer details, identity numbers, payment information, and correspondence. An email-authentication failure that allows impersonation of your domain is, under POPIA, a demonstrable failure to take reasonable technical measures.

A DMARC policy at p=reject provides auditable evidence that your organisation has implemented a recognised technical standard to prevent domain abuse. In the event of a data breach or an Information Regulator complaint, a properly enforced DMARC record is exactly the kind of documented control that demonstrates compliance.

Conversely, the absence of DMARC — or a record left permanently at p=none with no monitoring — is difficult to defend as “reasonable” when the open standard exists and is free to implement.

Beyond POPIA: the King IV and cyber resilience angle

King IV, South Africa’s corporate governance code, treats information and technology governance as a board-level responsibility. Email authentication falls squarely within it. For listed companies and larger organisations, a documented DMARC deployment with monitoring and enforcement is part of demonstrating that the governing body has discharged its IT governance duties.

Conclusion

DMARC is no longer optional for South African businesses. It is a security control that stops domain spoofing, a compliance measure that demonstrates POPIA alignment, and a deliverability requirement that major mailbox providers now enforce.

The path is well-defined: inventory your senders, publish SPF and DKIM, start DMARC at p=none, analyse your reports, and progress methodically to p=reject. The technology is free and open. The discipline — maintaining it, monitoring it, and responding to the data — is where most organisations need help.

If your domain is not yet at p=reject, you are one spoofed email away from a preventable incident. Start with a free DMARC lookup to see your current status, and move from there.

Ready to secure your domain? Check your DMARC record now with our free tool, or explore how DMARC Shield can manage the entire process for you with guided setup and monitoring.