Idea Summary

Add an instance-level setting that marks an APEX instance as non-production, which APEX_MAIL then uses to automatically redirect or suppress real recipient addresses regardless of what the calling application code does. Today, apex_mail/the instance's email configuration has no concept of "this is a non-prod environment" — email delivery is just a per-instance SMTP configuration (host, port, per-workspace send limits), with no built-in safety net distinguishing a production instance from a development or test one. If a non-production instance's SMTP settings happen to point at the same relay as production (whether by initial setup, a copy/refresh, or simple oversight), any outbound mail from that instance reaches real people with no platform-level safeguard in the way.

Use Case

Any organisation running multiple APEX instances across environments (dev/test/prod) where application code sends email to real staff, customers, or external parties — approval workflows, notifications, password resets, etc. During testing or after a database refresh from production (copying real data, including real email addresses, into a non-prod environment), test activity can trigger real emails to real people if the non-prod instance's mail configuration isn't independently verified every time. This is currently handled, if at all, by bespoke application-layer code (e.g., a shared "send mail" package that checks the database name and diverts non-prod traffic to a safe address) — a pattern that has to be re-implemented and remembered by every development team, rather than being guaranteed by the platform itself.

Preferred Solution

An instance-level flag (e.g. under Manage Instance → Instance Settings → Mail), such as "Environment Type: Production / Non-Production." When set to Non-Production, APEX_MAIL.SEND (and the underlying mail queue processing) would automatically override the p_to/p_cc/p_bcc recipients with a configured safe address (or simply not send/queue at all, per an additional setting), independent of any application code — so the safeguard survives even if a specific app's own logic has a bug, is bypassed, or was never written in the first place. Ideally this would apply uniformly to every apex_mail call across every workspace/application on that instance, rather than being something each application has to opt into individually.