What the result says
The check reports one line for each record, worded from what is published:
- SPF: “Unlisted senders fail SPF”
- The record ends in
-all. Not flagged. - SPF: “Soft fail for unlisted senders” or “Neutral”
- The record ends in
~allor?all. Flagged for review, because unlisted senders are not asked to fail. - SPF: “Published; no explicit all policy found”
- A
v=spf1record without anallterm at the end. Flagged. - DMARC: “Rejection” or “Quarantine requested”
p=rejectorp=quarantine. Not flagged.- DMARC: “Monitoring policy”
p=none: reports can arrive, but no handling is requested for failing mail. Flagged.- “Not published” or “Published without a policy”
- No record was found, or the DMARC record has no
p=tag. Flagged.
A flag is a reason to look, not a verdict: p=none is the right first step while a domain’s senders are still being listed.
SPF: what the policy means
SPF lists permitted sending sources for an envelope domain. An unmatched sender can produce a fail, soft fail or neutral result:
-all- Unlisted senders fail SPF. The receiver decides how to handle that result.
~all- Unlisted senders produce a soft fail; this does not require delivery or rejection.
?all- Neutral: no assertion about whether the sender is authorised.
Glarion summarises the published policy. It does not fully evaluate a message’s SPF result or validate every included sending service.
DMARC: the requested response
A message passes DMARC when SPF or DKIM passes with alignment to the visible From domain. For messages that fail DMARC, the policy requests:
p=reject- Rejection.
p=quarantine- Suspicious handling, such as a spam folder.
p=none- No DMARC-specific delivery action. Reports may be requested separately.
Receivers can apply their own policies. These records do not guarantee an inbox outcome or stop every kind of phishing, including lookalike domains.
Review before changing a policy
List the legitimate services that send for your business, including invoicing, newsletters and support. Review authentication and available DMARC reports before tightening a policy, so legitimate mail is not blocked.
The public check reads DNS records; it does not send test messages or change your email settings.
Common questions
What does the SPF and DMARC check show?
One line for each record, worded from what is published: the SPF policy ending (-all, ~all, ?all or none) and the DMARC policy (reject, quarantine, none, or no policy).
Is DMARC p=none a problem?
It is flagged for review because no handling is requested for failing mail. It is also the right first step while a domain’s legitimate senders are still being listed and reports are read.
Does a published policy guarantee inbox delivery or stop phishing?
No. Receivers can apply their own policies, and these records do not stop lookalike domains or every kind of phishing.
Does the check send test emails or change my settings?
No. It reads public DNS records only.
Reference and next steps
Technical definitions: SPF specification, RFC 7208 and DMARC specification, RFC 7489.
- SSL certificate checkerCheck when a client site’s certificate expires.
- Explain findings to a clientTurn the observation into a clear review task.
- Monitor verified client sitesScheduled checks and branded reports on paid plans.
- Security headers checkThe six response headers the same free check reads.
- HSTS checkerIs HTTPS enforced, and for how long?
Checking client domains every week
DNS records change when a client adds a newsletter tool or moves mail provider. A paid plan rechecks SPF and DMARC on every verified client domain and puts any change into a branded report with what it means and what to review.