InboxGrade

Listed on TRUNCATE RBL

Your sending IP or netblock is listed on the TRUNCATE RBL (`truncate.gbudb.net`), which targets snowshoe operations and sources with no legitimate mail history.

Impact — High impact

Receivers running GBUdb-driven filters and SpamAssassin rules such as RCVD_IN_GBUDB_TRUNCATE will reject or heavily score mail from a listed IP, so legitimate transactional and bulk mail disappears into spam folders or returns 5xx rejects at SMTP time. Because TRUNCATE lists snowshoe patterns across /24 or wider ranges, a single bad neighbor on shared infrastructure can poison your delivery too. Delistings are not instant — TRUNCATE requires sustained clean traffic before the entry ages out.

What causes it

  1. Snowshoe spamming: rotating low-volume sends across many fresh IPs in the same /24 or across multiple nearby /24s to dodge volume-based filters.
  2. Cold-sending from a newly allocated IP range with no established reputation, rDNS, or warmup pattern — TRUNCATE treats absence of history as adversarial.
  3. Shared or VPS hosting where neighboring tenants on the same netblock are running affiliate blasts or bulk cold outreach, dragging the whole block into TRUNCATE.
  4. Mailing-list rental or purchased-list sends producing complaint and unknown-user bounce patterns consistent with scraped data.
  5. Compromised accounts or an open relay on your network sending authenticated spam through legitimate infrastructure.

How to fix it

Confirm the listing and scope

Query TRUNCATE directly to confirm your IP (and the surrounding /24) is listed. If neighbors are also listed, the problem is block-level and delisting your single IP will not help until the range cleans up.

dig +short 1.2.3.4.truncate.gbudb.net A
# 127.0.0.2 = listed
# Check neighbors in the /24:
for i in $(seq 1 254); do \
  r=$(dig +short $i.2.3.4.truncate.gbudb.net A); \
  [ -n "$r" ] && echo "4.3.2.$i -> $r"; \
done

Stop the abusive pattern before requesting delisting

TRUNCATE will not honor removal requests while abuse is ongoing — the listing re-triggers from live traffic data. Freeze all cold outreach, suspend any purchased-list campaigns, rotate credentials on authenticated SMTP users, and audit postfix / exim logs for compromised accounts. If you run shared infrastructure, suspend offending tenants and prove it in your removal appeal.

Rebuild sending reputation with proper warmup and authentication

Resume sending from the listed IPs only after fixing fundamentals: valid PTR matching HELO, aligned SPF and DKIM, and a DMARC record with rua reporting. Then warm up slowly — a few hundred messages/day scaling over 2-4 weeks — focused on engaged recipients only. TRUNCATE ages listings out based on observed clean traffic, so steady low-complaint volume is the actual fix.

# Verify rDNS matches HELO before resuming:
dig +short -x 1.2.3.4
# Should return the same hostname your MTA uses in EHLO

# Confirm SPF/DKIM/DMARC alignment on a test send:
swaks --to postmaster@your-check-domain.example \
      --from bounce@yourdomain.com \
      --server mail.yourdomain.com --tls

Request delisting via GBUdb once traffic is clean

TRUNCATE is operated by GBUdb (Message Sniffer / ARM Research Labs). There is no self-service web form — removals happen through their support channel at support@armresearch.com with evidence of what changed (abuse source eliminated, authentication fixed, warmup plan). Expect delisting to be probationary; a repeat listing is harder to clear.

Fixed it? Run a fresh test to confirm.

Test my inbox →

Related errors