Overview

When sending emails from a web application, e-commerce platform, or automated PHP script (e.g., PHPMailer), your messages may be rejected by outbound email filters (such as MailChannels, Gmail, or Outlook) with errors like:

550 5.7.1 [CS] Message blocked

This error frequently occurs when an application script is configured using a raw server IP address (e.g., 184.71.119.86) instead of a fully qualified domain name in its site configuration settings.

Why Is the Email Blocked?

Anti-spam filters inspect both the headers and the body content of outgoing emails. Raw IP addresses trigger severe spam flags (NUMERIC_HTTP_ADDR) for two main reasons:

• Raw IP Links in Message Body: Spammers frequently use raw IP links to hide destinations. Security filters flag body links formatted as [http://184.71.119.86/verify](http://184.71.119.86/verify) instead of [https://rebel.ca/verify](https://rebel.ca/verify).

• Raw IP in Message-ID Header: Automated mailing scripts often construct the default Message-ID header using the host IP (e.g., <uniqueid@184.71.119.86>). Standard mail filters require a valid domain name after the @ symbol (e.g., <uniqueid@rebel.ca>).

Understanding the Roles: Web Domain vs. Email Domain

Your application uses two distinct domain parameters when delivering mail. They do not need to be the same domain, but neither should ever be a raw IP address:

[ Application Script ]
   │
   ├── 1. Site URL (App Domain) ──► Generates links in the email body (e.g., http://rebel.ca/verify)
   │
   └── 2. SMTP Login (Email Domain) ─► Handles email delivery & authentication (e.g., support@rebel.com)

Scenario Examples:

Common Misconception: "Is this an SPF Record Issue?"

It is very common to assume that outbound email blocks require modifying your domain's SPF record—for example, updating your record from:

v=spf1 a mx include:relay.mailchannels.net -all

to

v=spf1 a mx ip4:184.71.119.86 include:relay.mailchannels.net -all

Why changing SPF won't fix this specific error:

• The 550 5.7.1 [CS] error is triggered by the Content Scanner ([CS]) inspecting body links and headers after email authentication takes place.

• In the delivery bounce logs, you will notice that SPF and DKIM already passed (spf=pass).

• While ensuring your sending IP is authorized in SPF is good security hygiene, modifying SPF will not resolve a [CS] block as long as your application script is still embedding raw IP addresses in the body links or Message-ID headers. The Site URL configuration inside the script must be updated to an active domain name.

How to Resolve the Issue in 3 Steps

Step 1: Map Your Domain or Subdomain to Your Server IP

Create a DNS A Record pointing your web domain or subdomain to your server's IP address (184.71.119.86).

• If managed in Plesk Hosting DNS: Follow our guide on How to access your DNS records in your Plesk hosting package to add an A Record (e.g., Host: @ or app, Points to: 184.71.119.86).

• If managed in Rebel Domain Manager: Follow our guide on How do I access the Advanced DNS for my domain to add an A Record in your domain dashboard.

Step 2: Update Your Application Settings

In your web application's admin panel or configuration file (config.php, .env, etc.):

1. Locate the Site URL or Domain Name setting.

2. Replace (http://184.71.119.86) with your domain (e.g., (http://rebel.ca) or (http://app.rebel.ca)).

3. Save your changes.

This automatically cleans up all generated links and Message-ID headers.

Step 3: Keep Authenticated SMTP Active

Do not attempt to run an unauthenticated local mail server on your server. Ensure your application script remains configured to authenticate through Rebel SMTP using your official email account (e.g., support@rebel.com or support@rebel.ca).

Once these updates are complete, outgoing emails will satisfy security filters and deliver normally to inbox providers like Gmail and Outlook!