South Africa DMARC tracker

Key numbers

Percentages are of all 186 organisations, rounded to whole numbers. 1 organisation could not be checked on this date; it is part of the total of 186 but of none of the four numbers above.

By group

• JSE Top 40 40 organisations · 34 enforced

  Reject 22 · Quarantine 12 · Enforcing in part 2 · Monitoring only (p=none) 4

• Banks & insurers 47 organisations · 45 enforced

  Reject 28 · Quarantine 17 · Monitoring only (p=none) 1 · No DMARC record 1

• National government & state entities 64 organisations · 34 enforced

  Reject 16 · Quarantine 18 · Monitoring only (p=none) 15 · Record not valid 1 · No DMARC record 13 · Could not check 1

• Provinces & metros 17 organisations · 9 enforced

  Reject 5 · Quarantine 4 · Enforcing in part 1 · Monitoring only (p=none) 3 · No DMARC record 4

• Universities 26 organisations · 17 enforced

  Reject 12 · Quarantine 5 · Enforcing in part 1 · Monitoring only (p=none) 8

8 organisations belong to two groups and are counted in both, so the group sizes add up to more than 186.

All organisations

Scroll the table sideways to see every column.

No organisations match these filters.

What the statuses mean

Reject

One valid DMARC record with p=reject that applies to all mail from the domain itself that fails DMARC (no pct below 100, no test mode). Receivers that honour DMARC are asked to refuse mail that fails DMARC. A subdomain policy (sp=) that differs from p is named in the detail column. Read more: DMARC policy: none, quarantine, reject.

Quarantine

One valid record with p=quarantine that applies to all mail from the domain itself that fails DMARC. Receivers are asked to treat mail that fails DMARC as suspicious, usually by delivering it to spam. A subdomain policy (sp=) that differs from p is named in the detail column. Read more: DMARC policy: none, quarantine, reject.

Enforcing in part

p=reject or p=quarantine is published, but either pct below 100, which under RFC 7489 asks receivers to apply it to only part of the mail that fails DMARC (RFC 9989 removed pct; a receiver following it may apply the policy to all such mail), or test mode t=y asks them to apply one step less. The detail column says which. Read more: DMARC record tags explained.

Monitoring only (p=none)

A valid record with p=none. Receivers send reports if a reporting address is set, but apply no policy to mail that fails DMARC. Read more: DMARC policy not enabled: what it means.

Record not valid

A record is published, but receivers cannot use it as written: more than one DMARC record at the same name, or no valid p= tag. Read more: DMARC record tags explained.

No DMARC record

Resolvers run by two different companies (Google and Cloudflare) both returned a definite no-record answer (NXDOMAIN or an empty answer) for _dmarc.<domain>, and no read found a record. Read more: DMARC policy: none, quarantine, reject.

Could not check

We did not get one clear answer: a timeout, a resolver error, or answers that disagreed with each other. The detail column says which. We try again at the next check.

The SPF column names how the domain's SPF record ends. -all (strict) states that senders the record does not list are not authorised, and receivers may reject their mail; ~all (soft) says they are probably not authorised, and receivers should not reject on that alone but may treat the mail as suspicious. SPF's own names for these results are fail and softfail (-all is often called hardfail); see SPF softfail vs hardfail (~all vs -all). ?all (neutral) asks for nothing either way. "Over 10 lookups" means the record needs more DNS lookups than SPF allows (SPF: too many DNS lookups (PermError)), and "Multiple SPF records" means receivers can use none of them (Two SPF records on one domain). "Redirected" means the record ends with redirect=, which hands the check to another SPF record whose own ending then applies; we do not follow it. "No all mechanism" means the record ends without either. "Could not check" means we could not finish reading the record: a lookup failed, the record names an include we could not follow, or the two resolver operators disagreed about whether there is an SPF record at all. "No SPF record" needs both operators to answer without one.

How we check

• Who is listed. Five groups, each from a stated source:
  • JSE Top 40 (40 listed): Companies in the Satrix 40 (JSE Top 40 tracker) holdings as at 21 Oct 2026, cross-checked against the September 2026 index review; the official FTSE/JSE constituent file is not public.
  • Banks & insurers (47 listed): A selection of South African registered banks, insurers and medical schemes, compiled on 11 Nov 2026; not a complete register.
  • National government & state entities (64 listed): National departments from the gov.za department directory, Parliament, two Chapter 9 institutions (the Auditor-General and the Electoral Commission) and major state entities, compiled on 11 Nov 2026. Not listed yet: Department of Transport, State Security Agency — we could not yet confirm, with two independent checks, the main domain they use for email, so they are left out rather than shown with a domain that may be wrong.
  • Provinces & metros (17 listed): The nine provinces and the eight metropolitan municipalities, as of 11 Nov 2026. For Eastern Cape, Free State, KwaZulu-Natal and Limpopo we list the Office of the Premier, because each provincial department there sends mail from its own domain.
  • Universities (26 listed): Public universities listed by Universities South Africa and the Department of Higher Education and Training, as of 11 Nov 2026.
• One domain per organisation. We check the main domain we found each organisation using for email (every listed domain published MX records on 11 November 2026). Organisations often own several domains; the one we chose, and an evidence page for it, are in the CSV (evidence_url). If we chose the wrong one, tell us.
• The CSV. One row per organisation with the DMARC record as published, except that the mailbox part of each reporting address is replaced by * (some are a named person's own address); the domain part is kept. The file is comma-separated UTF-8: a spreadsheet set to a semicolon list separator should open it through its text import (in Excel: Data, From Text/CSV).
• How. On 11 November 2026 we asked public DNS-over-HTTPS resolvers run by Google and Cloudflare (in this order: dns.google, cloudflare-dns.com, 8.8.8.8, 1.1.1.1) for the TXT record at _dmarc.<domain>, the domain's SPF record and its MX records, and read them with the same code as our free DMARC checker. The DMARC answers on this date came from cloudflare-dns.com, 8.8.8.8 and 1.1.1.1.
• Every DMARC answer is asked twice. We ask resolvers run by two different companies, Google and Cloudflare, for every _dmarc record. We only say an organisation has no DMARC record when both returned a definite no-record answer (NXDOMAIN or an empty answer). If they disagree — a record on one and none on the other, or records that differ in what this page reports (p, sp, pct, t, whether a reporting address is published, or how many records there are) — the row shows "Could not check". A record found by one counts when the other could not answer at all. Before we say "No DMARC record" we ask again at the end of the scan, on every resolver address of both operators (the answers may come from the resolvers' caches), and compare the version (SOA serial) of the DNS zone behind each no-record answer: if a newer copy of the zone was seen that day, or the confirmation could not be read, the row shows "Could not check". This narrows, but cannot rule out, the case where every resolver relays an out-of-date name server. A timeout or a resolver error is never shown as "No DMARC record".
• Conflicting answers. Public resolvers relay what the organisation's own name servers say, and those can disagree with each other. If we see a domain's answers change between reads — in the scan, or when we re-read it while reviewing the results before publishing — the row shows "Could not check" and the detail column says what we saw. On this date that applies to 1 organisation. We never set any other status by hand.
• Public data only. Every DMARC, SPF and MX fact on this page is public DNS that anyone can look up. We do not send email to these domains, probe their servers, or use any non-public source.
• DKIM is not assessed. DKIM keys are published under selector names that cannot be listed from outside, so a domain that signs its mail can look identical to one that does not.
• Subdomains and public suffixes. Many listed domains sit directly under a public suffix such as gov.za, ac.za or co.za. Each organisation is classified by the record at its own _dmarc.<domain>, which is where receivers look first. Under RFC 7489 a public suffix's own record does not apply to the domains beneath it; RFC 9989 (May 2026), which replaces RFC 7489, lets a receiver fall back to a record higher up the DNS tree when a domain has none of its own. On 11 November 2026, no DMARC record was published at _dmarc.ac.za, _dmarc.gov.za, _dmarc.mil.za, _dmarc.org.za; _dmarc.co.za published a DMARC record with p=none; a receiver following RFC 9989 may apply it to a co.za domain that has no record of its own, but we classify every organisation by its own record.
• What DMARC does and does not tell you. DMARC lets a domain owner ask receivers to refuse or quarantine mail that falsely uses their domain, and to send them reports. A missing or relaxed record is not evidence of a breach or of any wrongdoing; organisations may protect their mail in other ways, or send from a different domain than the one listed.

Why it matters

Email that pretends to come from a bank, a university or a government department works because people trust the domain in the From address. DMARC is the published standard that lets the owner of that domain tell Gmail, Outlook and other receivers what to do with mail that fails DMARC. Large mailbox providers now require at least a DMARC record from bulk senders; see Google & Yahoo DMARC requirements. For the basics, read What is DMARC?

Corrections and right of reply

If you represent a listed organisation and something here is wrong — the domain, the group, or the reading — email [email protected]. We aim to reply within 5 working days. Corrections are listed in the change log below with their date.

The data is published under the Creative Commons Attribution 4.0 licence: you may reuse it if you credit DMARCmetric, link to this page and to the licence, and say if you changed anything.

Change log

• 11 November 2026 — First publication.