SMTP Connection Refused in Production for Cursor-Generated Email Code
Your Cursor-generated application sends emails perfectly during local development but fails with SMTP connection errors in production. Users aren't receiving signup confirmations, password resets, or notification emails. The server logs show connection refused, timeout, or authentication errors when attempting to connect to the mail server.
Email delivery is critical infrastructure — when it breaks, users can't sign up, can't reset passwords, and lose trust in your application. Cursor often generates SMTP code configured for a local mail server or development service like Mailtrap/Mailhog, which doesn't translate to production.
The issue might also manifest as emails being sent successfully according to your application logs, but never arriving in users' inboxes due to DNS, SPF, or deliverability configuration problems that only affect production domains.
Error Messages You Might See
Common Causes
- Port 25 blocked by cloud provider — AWS, GCP, Azure, and most cloud providers block outbound SMTP port 25 by default to prevent spam. You need to use port 587 (STARTTLS) or 465 (SSL/TLS)
- Development SMTP credentials in production — Cursor configured Mailtrap, Mailhog, or localhost:1025 credentials that only work in development
- Missing or wrong TLS/SSL configuration — Production SMTP servers require TLS encryption but the code uses plain text connections, or uses SSL when STARTTLS is expected
- Firewall or security group blocking outbound — The production server's security group or network ACL doesn't allow outbound connections on port 587 or 465
- SMTP authentication method mismatch — The email provider requires OAuth2 authentication (like Gmail) but the code uses plain username/password
- DNS resolution failing for SMTP host — The SMTP hostname can't be resolved from the production environment due to internal DNS or networking constraints
How to Fix It
- Use port 587 with STARTTLS — Configure your SMTP connection to use port 587 with STARTTLS encryption. This is the standard for authenticated email submission and is not blocked by cloud providers
- Switch to an email API service — Replace SMTP with an HTTP-based email API like SendGrid, Resend, Postmark, or AWS SES. These are more reliable than SMTP in serverless/cloud environments and include deliverability features
- Verify production environment variables — Check that SMTP_HOST, SMTP_PORT, SMTP_USER, and SMTP_PASS are set correctly in your production environment, not pointing to development values
- Check cloud provider email restrictions — If on AWS, you may need to request removal of the port 25 throttle. On most providers, using SES or a third-party email API is the recommended approach
- Test SMTP connectivity from production — SSH into your production server and run
openssl s_client -connect smtp.provider.com:587 -starttls smtpto verify the connection is possible - Configure SPF, DKIM, and DMARC — Even if SMTP connects, emails may be rejected without proper DNS records for your sending domain
Real developers can help you.
You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.
Get HelpFrequently Asked Questions
Why does email work locally but not in production?
Local development often uses a local SMTP server (Mailhog, Mailtrap) or your machine has no firewall restrictions. Production environments block port 25, require TLS, and need real SMTP credentials. Switch to an email API service like SendGrid or Resend for reliable production email.
Should I use SMTP or an email API?
For production apps, use an HTTP-based email API (SendGrid, Resend, Postmark, AWS SES). They're more reliable than SMTP in cloud/serverless environments, handle retries automatically, and include deliverability monitoring and analytics.