InboxGrade

Listed on SORBS SMTP

Your sending IP is listed on the SORBS SMTP zone because it was observed operating as an open relay or otherwise misconfigured SMTP server.

Impact — High impact

Receivers that query smtp.dnsbl.sorbs.net (notably Proofpoint, SpamAssassin's default rules, and many ISP filters) will reject or defer your mail with 5xx/4xx SORBS errors in the SMTP response. Expect bounces citing blocked using smtp.dnsbl.sorbs.net, degraded delivery to downstream filters that aggregate SORBS, and a growing feedback loop as retries accumulate on your queue. Until the underlying relay or auth misconfiguration is fixed, delisting will fail SORBS's automated retest and the listing will return within hours.

What causes it

  1. MTA accepting mail from unauthenticated external senders because mynetworks is too broad or smtpd_relay_restrictions is missing reject_unauth_destination in Postfix (or RelayHostsOnly/access map errors in Sendmail).
  2. Submission port 587 exposed without smtpd_sasl_auth_enable=yes and permit_sasl_authenticated, letting attackers relay through authenticated-looking sessions without credentials.
  3. Compromised SMTP account whose password was leaked or brute-forced, now being used by a botnet to relay spam through your authenticated submission port.
  4. Legacy application servers (phpmailer scripts, printer/scanner SMTP, old WordPress plugins) sending directly from the IP with forged envelope senders, triggering SORBS's spamtrap feeders.
  5. NAT/egress IP shared with a tenant VM or container that is running a vulnerable MTA (exim CVE-2019-10149, misconfigured Mailcow/Mail-in-a-Box) with no outbound port 25 lockdown.

How to fix it

Confirm the listing and the exact SORBS zone

Query the SMTP zone directly before touching your MTA. A positive result returns 127.0.0.9 (open relay) or 127.0.0.14 (misconfigured). Also check whether you're on other SORBS zones at the same time, which changes the remediation path.

dig +short 4.3.2.1.smtp.dnsbl.sorbs.net TXT
dig +short 4.3.2.1.dnsbl.sorbs.net A

Lock down relay and submission

In Postfix, restrict smtpd_relay_restrictions so only authenticated clients and your own networks can relay, and require TLS + SASL on 587. Reload and tail the log for Relay access denied on previously-permitted sessions to confirm the fix. For Sendmail, remove any wildcard entries from /etc/mail/access and rebuild with makemap.

# /etc/postfix/main.cf
smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination
mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/24

# /etc/postfix/master.cf (submission)
submission inet n - y - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Prove you are not an open relay before requesting delisting

Run an external relay test from an IP outside mynetworks. SORBS will re-scan on delisting request; if the test still succeeds you'll be relisted automatically. Use swaks or a public tester like mxtoolbox's open-relay check.

swaks --server your.mail.example.com --port 25 \
  --from attacker@external.example \
  --to victim@external.example \
  --h-Subject 'relay test'
# Expect: 554 5.7.1 Relay access denied

Rotate credentials, then submit the SORBS delisting request

If the cause was a compromised SASL account, force a password reset on all mailbox users and audit /var/log/mail.log for sasl_username entries from unexpected IPs. Once the relay test is clean, submit the delisting form at https://www.sorbs.net/cgi-bin/support referencing the IP and the specific fix applied. SORBS requires a human-written justification; auto-generated text is rejected.

Fixed it? Run a fresh test to confirm.

Test my inbox →

Related errors