smtpRS Decisions, Scores, Confidence & Evidence

Conceptual model

How smtpRS evaluates an email.

A request supplies an email address and selects an analysis profile. The public smtpRS contract exposes the resulting validation, risk, evidence, and decision fields, but it does not guarantee a particular internal execution sequence. Conceptually, smtpRS normalizes the input, evaluates available technical signals, combines rule-derived and machine-learning contributions in its risk analysis, and assembles the published response.

Conceptual evaluation flow. Email input and analysis profile → validation and signal collection → combined risk evaluation with rule-derived and machine-learning contributions → published score, reasons, response context, and decision → your application policy.

This diagram groups the concepts exposed to developers. It is not a promise that every implementation step always runs serially or at a fixed internal boundary. The API does not expose model architecture, weights, training data, proprietary feature engineering, internal thresholds, or the implementation details used to combine signals.

1. Input and evaluated signals.

The required request body contains an email string. The selected profile chooses a documented analysis mode; the default is quick. Profiles can change the available checks, context, entitlement, and credit cost, but a profile name does not guarantee a fixed internal execution plan for every request.

Signal family	Documented behavior
Address structure	Parses and normalizes the address, including casing, whitespace, common formatting edge cases, and malformed structure.
Domain status	Evaluates whether the domain exists, appears usable, and can be assessed completely.
Mail capability	Evaluates whether the domain appears configured to receive email, including multiple or partially configured mail routes.
Authentication context	Eligible responses may expose directly observed authentication-record fields such as `spf_present` and `dmarc_present`.
Disposable and mailbox patterns	Checks known temporary or disposable domains and evaluates documented role-based, shared-mailbox, and local-part patterns.
Domain risk context	Product documentation describes domain-level indicators and reputation context. The public contract does not promise a fixed set of reputation sources, and available context can vary by profile and signal availability.
Analysis profiles	`quick` is the lightweight default; `standard` provides broader passive analysis; `adaptive` can add checks when the initial result needs context; `deep` provides comprehensive analysis without catch-all probing; and entitled `catch_all` analysis includes that probing. These are documented service modes, not guarantees about exact internal operations.

The public API documentation does not identify message content, device telemetry, network telemetry, or a customer's historical behavior as inputs to the smtpRS endpoint. Applications may combine smtpRS with those separate controls in their own risk policy.

2. Observable and rule-derived checks.

Some findings come directly from the submitted address or from technical facts observable when the request runs. These include parsing and normalization, syntax validity, domain existence, mail capability, authentication-record presence, and matches against known disposable-domain or mailbox-pattern data.

These checks differ from probabilistic analysis because they report an observed state or a rule-derived classification. They are still time-sensitive: domain and mail configuration can change, and network-dependent checks can be unavailable or inconclusive. smtpRS can therefore return partial or indeterminate context rather than treating every unavailable check as a definitive failure.

3. Machine-learning risk analysis.

smtpRS uses Paravane's proprietary machine-learning model as a meaningful part of its risk analysis. Observable and rule-derived signals are combined with machine-learning contributions in the resulting assessment, but the public API contract does not identify the exact boundary between those contributions or guarantee their internal execution order.

At a public, non-proprietary level, the model contributes to evaluation of the combined signal pattern and the normalized risk assessment. Paravane does not expose the model's architecture, weights, training data, proprietary feature engineering, formulas, or internal decision thresholds through the API or this documentation.

4. Risk scoring.

The stable response field overall_risk is the normalized overall risk score. It summarizes the result of the available validation and risk signals for the selected analysis profile.

A score is not a probability. The published API contract does not define a universal minimum, maximum, formula, or numeric threshold mapping for overall_risk. Do not interpret it as a percentage probability or hardcode undocumented cutoffs.

Use the score with decision, reasons, the selected analysis_profile, and any returned domain or diagnostic context. Different profiles can perform different depths of analysis, so profile context belongs with the score when results are logged or reviewed.

5. Confidence and evidence completeness.

In the public preview interface, risk and confidence messaging answer different questions. Risk describes how concerning the evaluated signal pattern appears, while the preview's confidence label and explanation communicate how much usable evidence supports that interpretation. A low-risk preview can still have limited evidence when a relevant check was not performed or could not be completed.

The public smtpRS preview exposes a human-readable confidence label and reason, including when mailbox verification is not part of the preview. The stable production response documented today does not define a universal top-level numeric confidence field. Production integrations should use documented fields such as reasons, analysis_profile, domain_signal, and entitled response context rather than expecting a separate confidence percentage.

6. Evidence and response context.

smtpRS returns context so developers can understand and route a result instead of relying on one number alone.

Field or context	How to use it
`reasons`	Human-readable findings that support the decision. They are intended for logs, review queues, and operator context.
`domain_signal`	Normalized domain, mail, authentication-record, and optional company-context facts when returned.
`reason_codes`	Machine-readable domain-signal codes when included in the response.
`analysis_profile`	Identifies whether `quick`, `standard`, `adaptive`, `deep`, or `catch_all` analysis ran.
`response_profile`	Distinguishes the stable `summary` shape from an entitled `full` response.
`layers`	Entitled diagnostic context. Treat layer payloads as diagnostic rather than stable fields for hardcoded business rules.

7. Final decision.

decision is the customer-facing recommendation produced from the evaluated signal set. It is designed to be an input to the integrating application's policy, not a replacement for that policy.

Decision	Documented meaning	Typical integration response
`allow`	The signal set does not indicate high risk.	Continue the normal workflow while retaining the result for appropriate logging.
`manual_review`	The address or domain has ambiguous or elevated signals.	Queue for review, request more context, or introduce proportionate friction.
`reject`	The signal set indicates strong risk or invalid structure.	Block, deny, or request a safer alternate address according to your policy.

8. Example result.

This fictional example follows the documented full-response shape. Values are illustrative and are not the result of a live request.

Illustrative full response

{
  "email": "alice@example.com",
  "raw_risk": 2,
  "organization_validity_enabled": false,
  "organization_adjustment": 0,
  "overall_risk": 2,
  "decision": "allow",
  "tier": "PRO",
  "analysis_profile": "deep",
  "response_profile": "full",
  "credit_cost": 5,
  "credits_charged": 5,
  "reasons": [],
  "domain_signal": {
    "domain": "example.com",
    "domain_exists": true,
    "mail_capable": true,
    "spf_present": true,
    "dmarc_present": true,
    "company_valid": null,
    "company_evidence_routes": [],
    "documentary_association": {
      "routes": []
    },
    "reason_codes": [
      "dns_resolved",
      "mx_present",
      "organization_not_evaluated"
    ]
  },
  "layers": {},
  "usage": {
    "limit": 10000,
    "used": 21,
    "remaining": 9979,
    "window": "calendar_month_utc"
  }
}

Example field	Interpretation
`email`	The normalized email address represented by the response.
`raw_risk: 2`	The contract's risk value before any organization-validity adjustment. This guide does not define its internal calculation.
`organization_validity_enabled: false`	The optional organization-validity evaluation was not enabled for this illustrative request.
`organization_adjustment: 0`	No organization-validity adjustment is applied because that optional evaluation is disabled in this example.
`overall_risk: 2`	The normalized score returned for this illustrative result. It is not presented as a probability.
`decision: "allow"`	The evaluated signal set does not indicate high risk in this example.
`tier` and `response_profile`	Identify the account tier and entitled response shape associated with the result.
`credit_cost` and `credits_charged`	Report the documented cost of the selected analysis and the credits charged for this request.
`analysis_profile: "deep"`	The request used the documented deep profile rather than the default quick profile.
`reasons: []`	No human-readable findings are included in this example. An empty list is not a guarantee about ownership or future deliverability.
`domain_signal`	Shows directly returned domain, mail-capability, authentication-record, and optional organization context.
`domain`, `domain_exists`, `mail_capable`, `spf_present`, and `dmarc_present`	Report the normalized domain and the nullable technical observations represented in this example. They describe observed context, not guaranteed delivery.
`company_valid`, `company_evidence_routes`, and `documentary_association`	Carry optional organization-validity context. They remain null or empty here because that evaluation is disabled.
`reason_codes`	Machine-readable evidence codes that support programmatic interpretation without exposing the score calculation.
`layers`	Reserved here for entitled diagnostics; consumers should not build critical policy around undocumented layer internals.
`usage`	Reports the account's limit, usage, remaining credits, and accounting window. These are quota fields, not risk evidence.

9. What smtpRS does not guarantee.

A structurally valid address does not prove that a particular person owns or actively uses it.
Domain or mail capability does not guarantee future message delivery, inbox placement, or recipient engagement.
The public preview does not contact the destination mail server and does not claim mailbox verification.
A risk score or reject recommendation is not absolute proof of fraud; it is a risk assessment for policy use.
An allow recommendation does not guarantee that an identity is legitimate or that its infrastructure will remain unchanged.
Network-dependent and external technical signals can change, time out, or remain inconclusive.
Analysis depth and available evidence vary by profile, entitlement, and response shape.

10. How to use the result.

Use smtpRS as one structured control inside the workflow your application already owns. Preserve the decision, score, profile, and evidence together so operators can understand what ran and why a case was routed.

Use allow to continue ordinary signup, intake, or onboarding flows under your existing controls.
Use manual_review to add context, request verification, or route the case to a human review queue.
Use reject according to your policy when the result reports strong risk or invalid structure.
Read reasons and returned signal context before creating exceptions or escalation rules.
Choose an analysis profile deliberately and record it with the result; deeper profiles can add context but also have different entitlement and credit requirements.
Combine smtpRS with separate message, device, network, transaction, and behavioral controls when those signals are relevant to your application.

Keep policy authority in your application. smtpRS provides email validation and email risk intelligence. Your application's risk tolerance, exceptions, regulatory obligations, and human-review process determine the final action.

Explore the smtpRS email validation API API documentation Response field reference smtpRS pricing

Understanding smtpRS Decisions, Scores, Confidence, and Evidence