One section per finding. Each says what it means for forged mail, what to change, and the standard it comes from. Example records use example.ca; put your own domain in its place.
DMARC_MISSING
Receiving mail servers get no instruction about forged mail that claims to come from this domain, so most will deliver it.
What to change. Publish a TXT record at _dmarc.<domain>. Start with p=none and a rua address to collect reports, then move to quarantine and reject once every legitimate sender passes.
_dmarc.example.ca TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.ca"
Reference: RFC 7489 §6.1; CCCS ITSP.40.065
DMARC_MULTIPLE
When a domain publishes two DMARC records, receivers are required to ignore both. The domain is effectively unprotected.
What to change. Merge them into one TXT record at _dmarc.<domain> and delete the other.
Reference: RFC 7489 §6.6.3
DMARC_SYNTAX
The record exists but receivers can't use it, usually because v=DMARC1 is not the first tag or the p tag is missing or misspelled.
What to change. Rewrite the record so it starts with v=DMARC1 followed by p=none, p=quarantine or p=reject.
_dmarc.example.ca TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.ca"
Reference: RFC 7489 §6.3, §6.4
DMARC_POLICY_NONE
p=none asks receivers to deliver forged mail as normal and only send reports. It is the right first step, not a place to stay.
What to change. Read the aggregate reports, make sure every service that sends as this domain passes SPF or DKIM, then change p=none to p=quarantine.
Reference: RFC 7489 §6.3; CCCS ITSP.40.065 Annex A
DMARC_POLICY_QUARANTINE
p=quarantine tells receivers to treat failing mail as suspicious, usually by filing it as spam. Recipients can still find and open it.
What to change. Once reports show no legitimate mail failing, change p=quarantine to p=reject.
Reference: RFC 7489 §6.3
DMARC_PCT_PARTIAL
A pct value below 100 means the policy is applied to only that percentage of failing messages. The rest are treated as if the policy were one step weaker.
What to change. Raise pct to 100, or remove the tag, since 100 is the default.
Reference: RFC 7489 §6.3
DMARC_SUBDOMAIN_WEAKER
The sp tag sets a weaker policy for subdomains, so forged mail from made-up subdomains such as billing.example.ca is treated more leniently.
What to change. Set sp to the same value as p, or remove sp so subdomains inherit p.
Reference: RFC 7489 §6.3
DMARC_NO_REPORTS
Without a rua address the domain owner never sees who is sending mail in its name, which makes it hard to tighten the policy safely.
What to change. Add rua=mailto: with a mailbox or a reporting service you control.
Reference: RFC 7489 §7.2
DMARC_REPORT_DEST_UNAUTHORIZED
Reports are addressed to a different domain, and that domain has not published the record saying it accepts them. Many receivers will skip sending reports there.
What to change. Ask the owner of the report domain to publish <your-domain>._report._dmarc.<their-domain> TXT "v=DMARC1".
Reference: RFC 7489 §7.1
DMARC_ENFORCED
p=reject applies to all failing mail. Receivers that honour DMARC will refuse messages that forge this domain.
Reference: RFC 7489 §6.3
SPF_MISSING
The domain doesn't list which servers are allowed to send its mail, so SPF can never pass. DMARC then depends entirely on DKIM.
What to change. Publish one TXT record at the domain listing your mail providers, ending in -all or ~all.
example.ca TXT "v=spf1 include:spf.protection.outlook.com -all"
Reference: RFC 7208 §3
SPF_MULTIPLE
Two records starting with v=spf1 cause a permanent error, so SPF fails for every message.
What to change. Combine the mechanisms into a single record and delete the other.
Reference: RFC 7208 §4.5
SPF_TOO_MANY_LOOKUPS
Counting every include, a, mx, ptr, exists and redirect, including those inside included records, the total is over 10. Receivers return a permanent error and SPF fails.
What to change. Remove services you no longer use, replace a and mx with ip4 and ip6 ranges where they are stable, or move some senders to a subdomain.
Reference: RFC 7208 §4.6.4
SPF_VOID_LOOKUPS
More than two lookups in the record return no answer. Receivers may treat this as a permanent error.
What to change. Remove includes and hostnames that no longer resolve.
Reference: RFC 7208 §4.6.4
SPF_INCLUDE_BROKEN
An include points to a domain that has no SPF record. That is a permanent error, so SPF fails for every message.
What to change. Fix the hostname in the include or remove it.
Reference: RFC 7208 §5.2
SPF_PASS_ALL
+all tells receivers that any server may send for this domain, which defeats the purpose of SPF.
What to change. Change +all to -all or ~all.
Reference: RFC 7208 §5.1
SPF_NEUTRAL_ALL
?all, or a record with no all at all, says nothing about servers not listed. Mail from them is neither passed nor failed.
What to change. End the record with -all or ~all.
Reference: RFC 7208 §4.7, §5.1
SPF_SOFTFAIL_ALL
~all marks unlisted servers as suspicious rather than failing them. With DMARC at quarantine or reject this is common and acceptable. -all is the stricter choice.
What to change. Optional: change ~all to -all once you are sure every sender is listed.
Reference: RFC 7208 §8.5
SPF_PTR
ptr is slow, unreliable and discouraged by the SPF standard. Some receivers ignore it.
What to change. Replace ptr with ip4, ip6 or include entries.
Reference: RFC 7208 §5.5
MX_NONE
The domain has no MX records, so it probably doesn't receive mail. It can still be forged as a sender.
What to change. If the domain never sends mail, see NON_MAIL_DOMAIN_OPEN.
Reference: RFC 5321 §5.1
MX_NULL
A null MX record tells senders this domain never accepts mail. It's the correct setup for a domain used only for a website.
example.ca MX 0 .
Reference: RFC 7505
NON_MAIL_DOMAIN_OPEN
The domain has no mail servers or a null MX, but hasn't published v=spf1 -all and p=reject. Attackers favour domains like this because nobody watches them.
What to change. Publish v=spf1 -all at the domain and v=DMARC1; p=reject at _dmarc.
example.ca TXT "v=spf1 -all" _dmarc.example.ca TXT "v=DMARC1; p=reject;"
Reference: CCCS ITSP.40.065; RFC 7505
MTASTS_MISSING
Other mail servers aren't told to require an encrypted connection when delivering to this domain. This is about privacy in transit, not spoofing.
What to change. Publish _mta-sts.<domain> TXT and a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, starting in testing mode.
Reference: RFC 8461
MTASTS_TESTING
The policy is published but senders only report problems instead of refusing unencrypted delivery.
What to change. Change mode: testing to mode: enforce once TLS reports are clean.
Reference: RFC 8461 §5
MTASTS_POLICY_UNREACHABLE
The TXT record says a policy exists, but the policy file did not load over HTTPS. Senders will ignore MTA-STS.
What to change. Check that https://mta-sts.<domain>/.well-known/mta-sts.txt loads with a valid certificate.
Reference: RFC 8461 §3.3
TLSRPT_MISSING
The domain won't hear about failed encrypted deliveries.
What to change. Publish _smtp._tls.<domain> TXT "v=TLSRPTv1; rua=mailto:tls-reports@<domain>".
Reference: RFC 8460
DKIM_FOUND
A DKIM public key was found at one of the common selectors, so at least one sender signs mail for this domain.
Reference: RFC 6376 §3.6
DKIM_UNKNOWN
DKIM keys can only be found if you know the selector name, and none of the common ones answered. This does not mean DKIM is missing.
Reference: RFC 6376 §3.1
DNS_NXDOMAIN
DNS says this domain doesn't exist. The inventory entry is probably wrong.
What to change. Check the domain against the organization's official website and correct data/inventory.csv.
DNS_TIMEOUT
The lookup timed out, so this result is incomplete. The next scan will try again.