DMARC Checker Results Explained: What Each Status Means and What to Fix First
A DMARC checker gives you a wall of statuses. This guide translates each one into plain language and gives you a priority order for fixing them.
A DMARC checker tells you three things: whether your domain publishes a DMARC policy and how strict it is, whether SPF is valid and within its limits, and whether DKIM keys can be found. Fix them in this order: dangerous SPF settings and permanent errors first, then a missing DMARC record, then reporting, then the journey from p=none to p=reject.
How to read a checker result
Most DMARC checkers, including the MailMarq DMARC checker, query public DNS for your domain and report on what they find. That is both their strength and their limit. They can tell you exactly what you have published. They cannot tell you whether your real email passes, because that depends on how each sending system is configured, which only shows up in DMARC aggregate reports over time.
So treat a checker result as a configuration audit, not a verdict. A domain with a perfect-looking record can still have half its legitimate mail failing, and a domain showing warnings may be in the middle of a careful, deliberate rollout. The useful question for every status is: what does this mean for a receiving server deciding what to do with mail claiming to be from us?
DMARC statuses
No DMARC record found
There is no TXT record at _dmarc.yourcompany.co.za. Receiving servers have no instructions from you, and you receive no reports. Since February 2024 Google and Yahoo have required a DMARC record from bulk senders, and Microsoft applied similar rules to Outlook.com consumer domains from May 2025, so this increasingly affects deliverability as well as security. The fix is to publish a monitoring record such as v=DMARC1; p=none; rua=mailto:reports@yourcompany.co.za and start collecting data.
Multiple DMARC records
Two TXT records beginning with v=DMARC1 at the same name. Receivers are expected to ignore DMARC entirely in this case. Merge them into one.
Policy p=none
You are monitoring only. Receivers report to you but take no action against failing mail. This is the correct starting point and the wrong place to stay, as we explain in why monitoring-only DMARC is a false sense of security.
Policy p=quarantine
Failing mail should be treated as suspicious, usually delivered to spam or junk. This is a genuine protective step and a sensible intermediate stage.
Policy p=reject
Failing mail should be refused outright. This is the goal for most domains, reached once every legitimate sender is aligned.
pct below 100
A tag such as pct=25 asks receivers to apply your policy to only a portion of failing mail. It is a rollout aid, and some receivers apply it inconsistently. If you see a low pct that has not changed in months, the rollout has stalled.
No rua address
Without a rua tag you receive no aggregate reports. You cannot see who sends as you, so you cannot safely tighten policy. If reports go to an address on a different domain, that domain must publish an authorisation record for yours, or receivers will not send to it.
Syntax errors
A record that does not start with v=DMARC1 as its first tag, uses an unknown policy value, or contains a malformed mailto: address may be ignored in whole or in part. Typical causes are smart quotes pasted from a word processor, a missing semicolon between tags, or a DNS control panel that adds the domain name to the end of the host field, producing _dmarc.yourcompany.co.za.yourcompany.co.za. If a checker cannot find a record you know you added, check the host name first.
Strict alignment (adkim=s or aspf=s)
By default DMARC uses relaxed alignment, so mail signed or bounced through mail.yourcompany.co.za still aligns with yourcompany.co.za. Strict mode requires an exact match. It is rarely needed and frequently breaks legitimate third-party senders, so if a checker shows it, make sure someone chose it deliberately. DMARC alignment explained covers the difference.
Subdomain policy
The sp= tag sets policy for subdomains. If it is absent, subdomains inherit p=. An sp=none under a p=reject leaves every subdomain open to spoofing. See subdomains and the sp= tag.
SPF statuses
No SPF record
No TXT record starting with v=spf1. Receivers cannot verify which servers may send for your domain. Publish one that lists your actual sending platforms.
Multiple SPF records
Two or more v=spf1 records at the same name cause a permanent error. This usually happens when a new service’s setup guide says “add this SPF record” and someone adds a second record instead of merging. Combine them into one.
Too many DNS lookups (permerror)
SPF allows a maximum of 10 DNS-querying terms (the include, a, mx, ptr and exists mechanisms and the redirect modifier), counted across all nested includes, and no more than 2 lookups that return nothing. Exceed either and SPF returns a permanent error for every message. Our guide to fixing the 10-lookup limit walks through the options.
+all
The record ends in +all, which authorises every server on the internet to send as you. This is worse than having no SPF at all, and it should be fixed today.
?all
Neutral: SPF makes no statement about unlisted servers. It offers almost no protection.
~all and -all
~all (softfail) and -all (fail) are both reasonable. Under DMARC enforcement the policy does the heavy lifting, so many domains run ~all safely. Use -all on domains that never send.
DKIM and MX statuses
DKIM selector not found
DKIM keys live at selector._domainkey.yourcompany.co.za, and there is no way to list every selector a domain uses from DNS alone. Checkers therefore test common names: selector1 and selector2 for Microsoft 365, google for Google Workspace, and generic names such as default, s1 or k1. “Not found” can mean DKIM is genuinely not set up, or simply that your platform uses a selector the checker did not guess. Look at the DKIM-Signature header of a real message from each system: the s= value is the selector and d= is the signing domain.
Weak or malformed key
A 1024-bit key still works but 2048-bit is the current recommendation where the platform supports it. A malformed record, often caused by a key split incorrectly across TXT strings, fails verification for every message.
No MX record
The domain cannot receive mail. That is fine for a parked domain, and even better if paired with a null MX (0 .) and full lockdown, as described in locking down parked domains. For an active domain it is a serious problem.
MX pointing somewhere unexpected
If your MX points to an old host after a migration, mail may be going somewhere nobody reads. Confirm it matches your current platform.
What to fix first: a priority framework
Not every warning is equally urgent. Work through them in this order:
| Priority | Finding | Why first |
|---|---|---|
| 1 | SPF +all | Actively authorises anyone to send as you |
| 2 | SPF permerror, multiple SPF or DMARC records | Breaks authentication for all your mail |
| 3 | No DMARC record | No policy, no visibility, bulk sender rules unmet |
| 4 | No rua address | You cannot see what to fix |
| 5 | DKIM missing on main platform | Alignment depends on fragile SPF alone |
| 6 | p=none (after a business cycle of data) | Reports show the way to enforcement |
| 7 | pct below 100, sp=none, ?all | Gaps in an otherwise sound setup |
| 8 | Parked domains without lockdown | Easy, low-risk wins |
Items 1 to 4 are configuration fixes that rarely affect legitimate mail. Items 5 and 6 need evidence from reports before you change anything, because tightening policy before senders are aligned is how legitimate invoices end up rejected. The staged approach is set out in moving from p=none to p=reject.
After the check
Run the check again after every DNS change, and remember that DNS changes take time to propagate according to the record’s TTL. Keep a dated note of what you changed so that if mail behaves differently a day later you know where to look. If you manage several domains, check them all: the forgotten .com or old trading name is often the one with no protection at all.
Then look past DNS. Configuration is the easy half. The hard half is identifying every system that sends as you and making each one align, which is where most of the time in a DMARC project goes.
How MailMarq helps
Our free checker is the starting point. If the results raise questions, MailMarq’s free assessment covers DMARC, SPF, DKIM, MX and your parked domains, and our managed service takes you from the first record to p=reject with evidence at every stage. See the packages or ask us to look at your results.
Frequently asked questions
Why does the checker say DKIM is missing when my email is signed?
The checker can only test selectors it guesses. If your platform uses an uncommon selector, find it in the s= value of a real message’s DKIM-Signature header and check that name directly.
Is a green result on a checker enough?
No. It confirms your published records are sound, but only aggregate reports show whether every legitimate sender is passing and aligned.
Should I go straight to p=reject if the checker shows p=none?
Not without data. Collect reports for at least one full business cycle, align every legitimate sender, then progress through quarantine to reject.
How often should I re-run a check?
After every DNS change, and periodically as part of routine maintenance, because records get edited during migrations and new service onboarding.
Sources and standards
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). The IETF specification that defines DMARC policies, alignment and reporting.
- RFC 7208: Sender Policy Framework (SPF). The IETF specification for publishing and evaluating SPF records.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. The IETF specification for DKIM signing and verification.
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.
Keep reading
How Much Does DMARC Cost in South Africa?
The DNS record is free; the work is not. A frank breakdown of what DIY, self-service software and managed DMARC really cost a South African business.
Managed DMARC vs DMARC Software: Which Does Your Business Need?
DMARC software and managed DMARC both process your reports. The difference is who does the work afterwards. A frank comparison and a framework for choosing.
DMARC Alignment Explained: Why SPF and DKIM Pass but DMARC Fails
SPF and DKIM can both pass while DMARC still fails, because DMARC asks a different question: do the authenticated domains match the From address your recipient sees?
Find out where your domain stands
Send us your domain. We will review your DMARC, SPF and DKIM set-up, map the services sending as you, and tell you plainly what it would take to reach enforcement. No charge and no obligation.