Identify the listing level before assigning responsibility
UCEPROTECT publishes three listing levels with different scopes. A result concerning one IP address is not interchangeable with a result concerning its allocation or autonomous system. Record the exact level, object and observation time before deciding which team can investigate or whether the finding explains a delivery problem.
This guide uses the operator's public level and removal policies reviewed on 8 November 2026. It describes those policies without endorsing the operator's characterizations of customers or providers. No real address was queried, no network cause was established, and no removal, allowlisting or payment action was taken. A listing must still be connected to current operator evidence and an actual recipient effect.
Keep the three scopes in separate evidence fields
Level 1 is defined around individual IP addresses. The current policy includes automatic and manual criteria, not only one simple spamtrap threshold. Read the explanation applicable to the actual entry instead of assuming every Level 1 observation proves the same behavior. A host-level listing is an operator finding to investigate, not permission to accuse every user sharing the address. UCEPROTECT Level 1 policy
Level 2 concerns a network allocation. Its automatic path uses Level 1 impacts, allocation-dependent thresholds and a seven-day observation window. Separately, the policy allows manual, permanent network listings independent of Level 1 where the operator suspects a network was created for spamming. Establish which path applies; a covered IP need not have its own Level 1 entry. UCEPROTECT Level 2 policy
Level 3 concerns an autonomous system's IP space. Automatic escalation uses Level 1-derived network criteria, but the policy also allows manual, permanent ASN listings independent of Level 1 under the operator's stated suspicion criteria. Neither path proves misconduct by every contained host. The operator acknowledges collateral effects on innocent users. UCEPROTECT Level 3 policy
Prove that the recipient used the relevant level
Ask for the actual delivery diagnostic and identify which level, if any, it cites. A scanner showing Level 3 does not prove that the affected recipient uses Level 3, uses UCEPROTECT at all or rejected the message for that reason. The operator's published data and the recipient's decision are separate observations.
The informational RFC 6471 explains that administrators using a DNSBL remain responsible for their filtering decisions. Apply that distinction when reporting impact: an operator-confirmed network result is a reputation observation; a rejection tied to that level is delivery evidence. Do not describe a broader list as a universal Internet block. RFC 6471
For a fictional example, an IP without a Level 1 entry can be covered by Level 3. A rejection citing that level establishes an effect on that recipient path, not universal rejection or host culpability.
Validate the observation before planning a remedy
Retain the operator result, listed scope, relevant explanation and UTC capture time. If a DNS query is used in an authorized investigation, preserve the exact zone, encoded object, responding resolver, status and returned data. Match the interpretation to that level's current documentation rather than importing another operator's error-code meanings.
A timeout or SERVFAIL leaves the lookup unresolved. It does not establish a listing and cannot be recorded as a clean result. An unexplained code or empty display also requires investigation of query construction and service access. No command output or live DNS test is supplied here. RFC 1035
Changing header statistics are not case evidence. Retain the relevant policy date, not the operator's population counts or judgments about unrelated providers.
Assign host work and network work to the right owners
For an individual entry, the system or service owner should examine the operator's explanation and relevant sending or security evidence. If a shared outbound address is involved, the hosting or mail provider may control the needed logs. A customer should not claim to have repaired an entire shared service based only on checks of one application.
For an allocation or AS-level result, involve the provider's abuse or network team through an authorized channel. The provider should establish the listing type and applicable reason before predicting recovery. Supply the affected IP, level, current observation and recipient diagnostic without speculating about other tenants.
The proposed corrective action should match the verified cause. Do not make an IP migration, provider purchase or broad receiving-side exemption the automatic first response. Each can create new risks or merely move the symptom. Preserve a reviewable plan and approval boundary before any operational change.
Read expiry rules without promising a countdown
The Level 1 removal page describes automatic free expiry for temporary entries seven days after the last relevant spamtrap event. Do not generalize that wording to every manual criterion or start the clock from when a customer first sees a warning. Current entry details and continuing events matter. UCEPROTECT Level 1 removal
For automatic Level 2 or Level 3 escalation, the removal pages describe de-escalation when the relevant criteria no longer hold. That guidance is not a countdown for manual, permanent entries, which each listing policy permits independently of Level 1. Ask the provider owner to verify the entry type and applicable operator process before predicting removal. One customer's repair, or lower Level 1 activity alone, does not establish that a manual entry will clear. UCEPROTECT Level 2 removal UCEPROTECT Level 3 removal
The operator also advertises optional paid removal routes. Their existence is neither a recommendation nor a guarantee against relisting or future rejection. This article does not quote an unverified price, initiate a payment or imply that payment is required for automatic expiry. Any commercial decision needs separate current terms and authorization.
Close the case with scoped recovery evidence
After a separately approved correction or provider response, obtain a fresh operator observation for each relevant level and retest the affected delivery path with permission. Record whether the level changed, whether the message was accepted and whether subsequent filtering occurred. These findings can differ, so do not compress them into a single all-clear statement.
The required original evidence remains absent: an operator-confirmed listing with a documented cause, corrective action and delivery retest. Keep that execution gate separate from this source-backed explanation, and keep unresolved network ownership or recipient-policy questions visible until evidence answers them.
Required original evidence: An operator-confirmed listing and a documented cause, corrective action and delivery retest. This gate is open; no such case execution is claimed.