Skip to main content

Documentation Index

Fetch the complete documentation index at: https://jetemail.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
Introduction

This error means the SMTP user has an IP restriction set, and the IP you’re connecting from is not on its allow list. The credentials themselves are valid; we reject the connection because the source IP isn’t authorized. If you didn’t intend to set an IP restriction, the fix is to clear the restriction list. If you did, the fix is to add the IP you’re connecting from.

​
What IP restrictions support

JetEmail SMTP users can be restricted to one or more allowed sources. The allow list accepts:
  • IPv4 addresses — e.g. 203.0.113.42
  • IPv6 addresses — e.g. 2001:db8::1
  • IPv4 CIDR ranges — e.g. 203.0.113.0/24 for an entire /24 block
  • IPv6 CIDR ranges — e.g. 2001:db8::/64
Mix and match as needed. A single SMTP user can have multiple entries covering different servers, regions, or providers.

​
How to fix this error

  1. Log in to the JetEmail Dashboard at dash.jetemail.com
  2. Go to Outbound → SMTP
  3. Click the SMTP user that’s failing to authenticate
  4. Either clear the IP restriction list to allow any source, or add the IP/range you’re connecting from
  5. Save and retry
To find the IP your server is connecting out from, run curl https://api.ipify.org (IPv4) or curl https://api64.ipify.org (IPv4 or IPv6) on the server itself.

​
Common scenarios

  • Cloud and load-balanced setups. Add every potential outbound IP. Most cloud providers list their egress ranges; using a CIDR for the whole pool is usually easier than chasing individual IPs.
  • Dynamic IPs (home / office). If your IP changes regularly, either lift the restriction, use a /24 (or larger) range covering your ISP block, or route mail through a server with a fixed IP.
  • Adding IPv6. Even if your server has both stacks, mail clients may use IPv6 by default. Add the v6 address (or /64) alongside the v4 one to cover both paths.

​
Best practices

  • Use IP restrictions on credentials shared by long-lived servers. They’re a strong second factor against credential leaks.
  • For credentials used by laptops or rotating cloud workers, IP restrictions are often more trouble than they’re worth — favour rotation and tight quotas instead.
  • Name the SMTP user after the server it’s tied to (mailserver-prod, app-eu-west) so future-you remembers which IPs the restriction was for.