ORA-29278: SMTP transient error: 421 service not available

ORA-29278 is not an SMTP code itself — it is the Oracle PL/SQL exception raised by UTL_SMTP (and the UTL_MAIL wrapper) when the remote mail server returns a transient 4xx reply. The text after it, 421 service not available, is the actual SMTP reply code your database received and is passing through verbatim.

What does ORA-29278: 421 service not available mean?

Per RFC 5321 §4.2.1, a leading 4 is a transient negative completion reply: the command failed, but the condition is temporary and the same request may succeed if retried later. Reply 421 specifically means "Service not available, closing transmission channel" (RFC 5321 §4.2.3) — the mail server accepted your TCP connection on the SMTP port, then refused to continue the conversation and hung up. RFC 5321 §3.8 confirms a server may send 421 at any point, including immediately after connection, if it needs to shut down or reject the session — this is a documented but informal alternative to waiting for a command before erroring out.

So ORA-29278 with a 421 tells you two things: your Oracle instance did reach a listener on the target host/port, and that listener declined service. This is the key distinction from ORA-29260 (network error / host unreachable) and ORA-24247 (the connection was blocked by Oracle's own ACL before it ever left the box).

What causes ORA-29278: 421 service not available?

Common, documented causes:

• The relay is down, busy, or restarting. 421 is exactly what a server emits when it "knows it has to shut down" or is overloaded — one widely-cited troubleshooting writeup traces this to a mail daemon that wasn't running or a misconfigured SMART_HOST in sendmail.mc.
• Connection refused / firewall. A firewall or security group permits the TCP handshake to a proxy but the real SMTP service behind it isn't listening, producing "Connection refused by smtp.host.com" in /var/log/maillog.
• Rate limiting / connection throttling. Many providers return 421 when a single source opens too many connections or sends too fast. This is per-IP and temporary.
• Greylisting or reverse-DNS/HELO checks at the receiving edge that defer the session.

Note: if the database itself blocks the call you'll usually see ORA-24247 ("network access denied by access control list"), not ORA-29278 — but a too-narrow ACL (e.g. missing resolve so the hostname can't be looked up, or wrong port range) can still leave you unable to complete a session and surface connectivity-style failures.

How do I fix ORA-29278: 421 service not available?

1. Confirm reachability from the database host (isolates Oracle from the network):

# from the DB server, not your laptop
telnet smtp.example.com 25     # or 587 / 465
# expect: 220 smtp.example.com ESMTP ...

If you do not get a 220 greeting (connection refused, hang, or an immediate 421), the problem is the mail server or the path to it — not your PL/SQL. Check /var/log/maillog, confirm the daemon is running, and have your network admin open the SMTP port. If DNS is flaky, try the relay's IP literal instead of its hostname.

2. Grant the database a network ACL (mandatory on 11g+ for UTL_SMTP/UTL_MAIL, via DBMS_NETWORK_ACL_ADMIN). Grant both connect (TCP) and resolve (DNS), and assign the host with the correct port:

BEGIN
  DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
    host => 'smtp.example.com',
    ace  => xs$ace_type(
              privilege_list => xs$name_list('connect','resolve'),
              principal_name => 'APP_USER',
              principal_type => xs_acl.ptype_db));
END;
/

(On 11gR1 use the older CREATE_ACL / ADD_PRIVILEGE / ASSIGN_ACL sequence.) A missing resolve privilege is a frequent reason a hostname-based send fails where an IP would work.

3. Back off and retry. Because 421 is transient, the correct application behavior is to queue and retry with a delay rather than treat it as a hard bounce. If 421s correlate with volume, you're being throttled — reduce concurrent connections and sending rate, or move to an authenticated submission relay.

4. Use the right port and TLS. Submission on 587 (STARTTLS) or 465 (implicit TLS) is preferred for authenticated relays; both are valid per RFC 8314. Port 25 is for server-to-server MTA traffic and is often blocked outbound by cloud providers (Azure blocks it by default for many subscription types, though not for Enterprise Agreement/MCA-E). If your provider filters outbound port 25 at the network layer, you'll typically see a connection timeout or refused connection rather than any SMTP reply — switch to submission on 587/465 through an authenticated relay. Getting an actual 421 means you reached a live SMTP listener, which rules out simple port filtering as the cause.

If you are sending through Courier rather than a self-managed Oracle relay, you avoid UTL_SMTP entirely — Courier manages the SMTP connection, retries, and provider failover for you.