A web application can work perfectly in local development and still fail at one surprisingly basic task after deployment:
sending an email.
Some hosting platforms restrict outbound SMTP connections. Others allow them only on certain plans or ports. Network policies can also make direct SMTP unreliable.
The application therefore needs a delivery method that matches the hosting environment.
First identify the actual failure
Email problems can come from several layers:
- DNS configuration;
- invalid credentials;
- blocked network ports;
- TLS errors;
- sender verification;
- provider rate limits;
- spam filtering;
- application bugs.
Before replacing the whole email stack, verify whether the deployed application can establish a connection to the SMTP server at all.
A local success does not prove that the cloud environment permits the same network traffic.
Prefer HTTPS APIs when available
Many email providers expose an HTTPS API in addition to SMTP.
This is often easier to use from modern hosting environments because normal outbound HTTPS traffic is expected.
The architecture becomes:
Application -> HTTPS API -> Email provider -> Recipient
Advantages include:
- fewer port restrictions;
- structured error responses;
- easier authentication;
- provider-level delivery tracking;
- simpler retries.
If a provider supports both SMTP and an API, the API is often the better choice for application-generated email.
A serverless relay can also work
Sometimes the application cannot call the preferred mail provider directly, or an existing serverless endpoint already owns the email workflow.
A small relay endpoint can accept a validated request and perform the privileged email operation.
The backend sends:
{
"template": "report_ready",
"recipient": "person@example.com",
"reportId": "..."
}The relay handles the credentials and provider-specific request.
This pattern is useful when the main application is deployed on constrained infrastructure.
Do not expose the relay publicly without controls
An open email endpoint can become a spam service.
At minimum, validate:
- allowed templates;
- recipient format;
- required fields;
- payload size;
- origin where appropriate;
- request frequency.
For higher-risk cases, require a server-side shared secret or signed request.
Secrets should never be embedded in public browser JavaScript.
Separate email generation from transport
The application should not mix business logic with SMTP-specific code.
A useful interface is:
sendReportEmail(recipient, report)The implementation behind that function can use:
- SMTP;
- an email API;
- a serverless relay;
- a queue.
This makes infrastructure changes much less disruptive.
Treat delivery as an asynchronous boundary
An application should not always make the user wait for an email provider to respond.
For non-critical email, a good flow is:
- finish the main application action;
- record that an email needs to be sent;
- trigger delivery;
- retry temporary failures;
- store delivery status.
This prevents a slow provider from making the entire user interaction feel broken.
Log delivery states
Useful states include:
- queued;
- sent to provider;
- delivered;
- bounced;
- failed;
- suppressed.
Not every provider exposes every event, but tracking what is available makes support much easier.
Avoid logging full email bodies or secrets unnecessarily.
Watch deliverability too
Successfully calling an API is not the same as reaching the inbox.
Production email should also consider:
- SPF;
- DKIM;
- DMARC;
- verified sender domains;
- consistent From addresses;
- unsubscribe handling for marketing email;
- separation of transactional and promotional flows.
A technically successful send can still land in spam if the domain setup is weak.
Keep a fallback path
For high-value workflows, it can be useful to provide an on-screen confirmation or downloadable result even if email delivery fails.
Email should improve the workflow, not become a single point of failure.
The broader lesson
Infrastructure constraints are part of application design.
When SMTP is blocked, the right response is rarely to keep retrying the same port. The better approach is to choose a transport that the deployment environment supports and isolate it behind a stable application interface.
For another lightweight integration pattern, see Static Forms with Google Sheets and Apps Script.
Need a web workflow to reliably generate and deliver reports, notifications, or leads? Describe the flow here.