Exception: 550 5.7.1 Refused by local policy

General
1

Hi,
We’ve been doing alot of testing on sign up & restore passwords for end users. Up until now nothing has restricted our sending emails via our own code generated on users devices to initiate password recovery BUT we have now tried using your icloud services for email recovery and are now getting -

"Application ID: 999D4F62-8A9B-4BFB-A20C-0CDEA2931FD6
Message: Send message ‘User Requests Password Recovery By Link’ was failed Recipients: pbhillen@gmail.com
Exception: 550 5.7.1 Refused by local policy. No SPAM please! (B-EX 155302::1778146622-4E994C43-37CE76A4/10/37982764432) [MSG0011]

Thank you for using Backendless!
the Backendless Team"

Is the error from Backendless specifically or your email server?
Can it be reset or fixed?
Regards,
Paul

2

Hello @Paul_HIllen

Based on the error message, I can confirm that this exception is being returned directly by the custom SMTP server configured in your application settings, not by Backendless itself.

The error 550 5.7.1 Refused by local policy. No SPAM please! is a standard SMTP response indicating that the mail server’s internal security or anti-spam filters have blocked the outgoing message.

Why this might be happening:

  • Rate Limiting: Since you’ve been doing a lot of testing, your email provider may have triggered a temporary block due to the volume of messages sent in a short period.
  • Security Policies: The “No SPAM please!” note suggests that the server’s automated filters flagged the content or the frequency of the password recovery links as suspicious.
  • DNS Configuration: If your domain does not have valid SPF or DKIM records, many SMTP servers will refuse to relay the mail to prevent spoofing.

Recommended Next Steps:

  1. Contact Your Email Provider: The best course of action is to reach out to your SMTP service support. Provide them with the full error text, including the reference ID in the brackets (B-EX 155302...). They can look up their internal logs and tell you exactly which “local policy” was triggered.
  2. External Test: Try sending an email with the same credentials using a standard desktop mail client. If it fails there too, the issue is strictly with the email account/server configuration.
  3. Consider Transactional Services: For production environments, we highly recommend using dedicated transactional email providers (like SendGrid, Mailgun, or AWS SES). Standard email hosting often has strict limits that are not ideal for automated application alerts and recovery links.

Regards