Email authentication
SPF and DMARC presence, policy strength, and visible configuration.
FREE DNS + EMAIL SECURITY TOOLS · FOR MSPS
Build and review DNS, email-authentication, certificate, browser-protection, and security-contact drafts for an MSP-managed client. The work stays in the browser until the MSP validates, approves, and publishes it through the client’s normal change process.
EVIDENCE · INSIGHT · PROOF
Published SPF, DKIM and DMARC evidence.
Selected published configuration and records.
Supported public observations, with their dates and limits.
Not established by public evidence. Ask for approved read-only access.
EVIDENCE · INSIGHT · PROOF
Published domain, DNS, email authentication, certificates and external evidence.
Supported Microsoft 365 identity, app, permission, licensing and configuration evidence.
No message bodies, private files, chats or prompts. Unread is not clean.
Use the existing bounded Public Domain Score. Email-authentication configuration alone cannot prove delivery, account compromise or complete spoofing protection.

Review a prospect or client domain for public-facing email, DNS, certificate, web, and security-contact evidence. Every pass, gap, unread source, and scoring boundary stays visible. See your free result on screen without entering an email address.
A useful first look for the conversation ahead—not a claim about controls hidden inside the business.
SPF and DMARC presence, policy strength, and visible configuration.
DNSKEY and DS reads to determine whether the DNSSEC chain is published.
CAA records that name which certificate authorities may issue.
Authoritative nameserver delegation and observable redundancy.
One bounded HTTPS homepage read for supported security headers.
The RFC 9116 /.well-known/security.txt contact path.
The current domain-security workflow schedules 35 collectors and can produce 123 distinct finding types. A collector can execute multiple atomic checks and return evidence, no finding, an unavailable source, or an error; SCOUTz records that distinction instead of turning missing coverage into a pass.
DNS depth, certificate health, SPF, DMARC, DKIM signals, MTA-STS, TLS-RPT, DNSSEC, CAA, delegation, reputation, and IPv6 mail-path context.
Subdomains, takeover signals, TLS posture, response headers, website compliance, CMS and technology fingerprints, and public-facing hardening context.
Lookalike domains, impersonation signals, source-labeled historical breach associations, outside-in perimeter context, and supported public-exposure evidence.
Public Microsoft 365 tenant discovery, managed-versus-federated identity signals, and the evidence boundary for requesting a customer-approved cloud review.
Hosting, email-security, SaaS, telecom/UC, platform, vendor, and incumbent-management signals derived from public records and fingerprints.
Firmographic, entity, mobile-app, digital-presence, compliance-readiness, and public AI-governance signals that help an MSP prepare the right conversation.
Start with the domain’s public email-authentication evidence. Review SPF senders, DMARC policy and alignment, and the DKIM selector supplied by your mail provider. An unknown selector is not proof that DKIM is absent.
An appropriate policy follows an inventory of legitimate senders and alignment testing. Move toward enforcement through the authorized change process; a published reject policy alone does not prove complete spoofing protection.
A message fails when neither its SPF nor DKIM result passes with the required alignment. A DNS-only review cannot establish every message’s authentication result; inspect authorized message headers and reports.
The bounded public score is free and its result is visible without signup. Website safeguards still apply. Local fix generators prepare drafts; they do not publish changes.
They are browser-based fix-preparation utilities for MSPs: generate a draft, review text pasted by the operator, and plan a safe client rollout. Work stays local to the page. Publishing and final validation remain inside the MSP’s authorized client change process.
The domain view uses the public evidence available before a customer authorizes deeper access. It can support an informed question about domain, DNS, email, certificate, web, and related external posture. It cannot establish internal identity, application, device, sharing, licensing, recovery, or operational controls.
Why the first review stays outside-in →Because a finding without a useful next step is theater. These ungated tools help an MSP understand the control, prepare a draft, and explain the rollout without touching the domain or consuming the production review workflow. The MSP and client still own authorization, validation, publication, and rollback.
Start with the factual public score →Prepare SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, DANE/TLSA, BIMI, security-header, CSP, and security.txt drafts.
Paste an SPF or DMARC record to flag common formatting and policy considerations without looking up the domain.
Carry a copy-ready draft into the MSP’s normal approval, publication, rollback, and validation workflow.
Bring dated evidence, clear limits, and useful questions.