Versioning
Every report identifies the methodology and check-catalog version used. A later rule change does not rewrite an earlier run.
Methodology
A launch decision backed by observable evidence.
OutboundQA checks the technical infrastructure around an outbound launch and records what it found. It does not predict or guarantee inbox placement.
One check, end to end
How a missing DMARC record becomes a verified recovery.
1. Input
Sending domain harbor-mail.com in the Harbor Health launch workspace.
2. Observed evidence
At 2026-08-21 14:32 UTC, authoritative DNS returned NXDOMAIN for TXT at _dmarc.harbor-mail.com. Resolver and response are retained with the run.
3. Rule
Methodology v3. A sending domain must publish one syntactically valid DMARC TXT record. A missing record is not inferred from cached or prior evidence.
4. Severity
Critical. The required authentication policy is absent.
5. Verdict impact
Do Not Launch. One critical result is sufficient to block the workspace verdict.
6. Remediation
Publish v=DMARC1; p=none; rua=mailto:dmarc@harbor-mail.com at _dmarc.harbor-mail.com, then wait for authoritative DNS to serve it.
7. Verification
A fresh full rerun at 2026-08-22 09:26 UTC observed the record, parsed it successfully, and replaced the failure with Pass. The report keeps both runs.
Evidence policy
Fresh evidence earns the verdict.
Freshness
The observed-at time travels with each result. A rerun reads the source again instead of re-labeling old evidence.
Unknowns and outages
Timeouts, unavailable providers, missing permissions, and insufficient samples become Unknown. Unknown never silently becomes Pass.
False-positive review
An operator can challenge a finding with source evidence. The original result remains in history, and only a fresh check can change the current verdict.
Decision process
Four steps from evidence to a client-safe report.
- 1
Collect
Read the configured DNS, HTTP, TLS, RDAP, blacklist, sender, inbox, tracking, and SMTP evidence that applies to the workspace.
- 2
Classify
Store pass, warning, fail, or unknown with the raw evidence, a clear reason, and an exact remediation where one is available.
- 3
Decide
Apply the versioned severity rules: critical failures produce Do Not Launch, warnings produce Needs Fix, and a clean completed run produces Ready.
- 4
Verify
After a change, run fresh checks. Recovery is shown only when the completed run supports the new verdict.
Boundaries
What the evidence can and cannot establish.
Infrastructure configuration
OutboundQA can verify configured records and observable endpoints at the time of a completed check.
Inbox placement
OutboundQA cannot establish where every recipient provider will place a future campaign without separate placement evidence.
Transient failures
An unavailable resolver, provider, or network path is recorded as unknown instead of silently blocking a launch.
Monitoring reliability
A settings toggle is not proof. The monitoring surface shows completed checks, baseline coverage, and alert-test freshness until a controlled production drill is complete.
Versioned checks
The report explains the decision, not just the result.
Every completed run keeps its check evidence, status, severity, and remediation guidance. The client report stays readable while technical evidence remains available to the operator.
Questions
No. It verifies observable infrastructure configuration and records what the checks found. Inbox placement also depends on message content, recipients, sending behavior, mailbox-provider filtering, and other evidence outside a DNS check.
OutboundQA records an unknown result instead of treating a transient network problem as a failure. The report keeps the evidence and time of the check so an operator can decide whether to rerun it.
Only after a controlled production drill has recorded a change, detection, destination delivery, recovery, and a fresh verification run. Configuration alone is not proof.