Resolving: This message was classified as rSPAM and may not be delivered

If an InterServer-hosted application or mailbox receives This message was classified as rSPAM and may not be delivered, start with the complete SMTP rejection, not repeated attempts to send the same message. The response identifies an outbound filtering decision; it does not, by itself, prove that your mailbox was hacked or that the recipient rejected the mail.

InterServer uses MailBaby for outbound filtering. The code explanations below are adapted for InterServer customers from MailBaby’s rSPAM troubleshooting guidance. Delivery still depends on authentication, message content, sender reputation and the receiving system; filtering cannot guarantee inbox placement.

Collect the rejection details

Record the timestamp and timezone, sending address, destination domain, full SMTP status, additional three-digit code and any named rule. Preserve the message ID when available. Check whether the failure affects one message, one mailbox or every sender from the application.

A rejection can include a diagnostic link on mail.outboundspamprotection.com. Review the rule details there and use its false-positive reporting option when appropriate. Treat diagnostic links and message content as private. Do not publish them, credentials or an unredacted customer email in a public forum.

Code 100: account restriction or local blacklist

Rules such as COMPROMISED_EMAIL_FROM_BLACKLIST or LOCAL_BL_FROM indicate a sender restriction. The rule name alone is not a complete compromise investigation. Check application sending logs, mailbox access and unexpected message volume before deciding the cause.

If you find unauthorized activity, pause the affected sender, rotate exposed credentials and repair the entry point. Check that configuration files containing SMTP passwords are outside the public web root and not downloadable. Request review through the diagnostic page or an InterServer support ticket after documenting the corrective steps. Do not assume a password change alone removes a manual restriction.

Code 200: SPF-related authentication failure

Rules such as SENDER_FAILS_SPF_SPOOF and REDIS_SPFFAIL_CHECK call for checking the sending domain and its authorized outbound route. Ask support for the correct SPF authorization for your service if you are unsure. Do not add an arbitrary include or replace a working record without accounting for other legitimate senders.

Edit the existing SPF record rather than publishing a second SPF policy. Confirm the DNS change on the authoritative nameservers and retest after relevant caches expire. There is no universal one-hour recovery guarantee; DNS caching and filtering state can differ. Supply the updated record and a fresh rejection to support if the problem remains.

Code 300: malware-related detection

The underlying rule matters. CLAM_VIRUS can indicate a scanner detection in message content or an attachment. DBL_MALWARE refers to a domain reputation match, not necessarily an infected attachment. Spamhaus describes the Domain Blocklist as a domain-based list.

Inspect attachments and linked domains safely. Do not open suspected malware to test it or simply rename an attachment to evade detection. If a domain you operate is implicated, investigate the website and its listing. For a suspected false positive, send support the rule and relevant diagnostic information through a private ticket.

Code 400: content or fuzzy-match filtering

Rules including FBL_FUZZY_DENIED and FUZZY_PLUS_DENIED indicate similarity to content associated with filtering reports. Verify that the message is expected, that recipients consented where required, and that its links and attachments are legitimate.

Correct genuinely misleading content or an unsafe link, but do not repeatedly vary wording to work around a filter. Report legitimate false positives with the full rule details so the sending problem can be reviewed rather than concealed.

What to include in an InterServer ticket

Open a ticket in the InterServer customer portal. Include the affected service, timestamp, sender, destination domain, SMTP response and diagnostic link. Explain whether the message came from a mail client, website or scheduled job, and summarize any DNS or security changes already made.

Never include a mailbox password, API key or private key. Support can request additional message evidence through the appropriate private channel. After resolution, send one controlled test and check both server acceptance and actual delivery before resuming a queued workload.