Custom SMTP

Custom SMTP lets you send authentication emails through your own email provider instead of Sticklight’s built-in mailer.

Who can do this: Workspace Owners and Admins. Editors and Viewers cannot configure SMTP settings. See Roles and Permissions for details.

What is SMTP?

SMTP (Simple Mail Transfer Protocol) is the standard way applications send emails. When your app needs to send a signup confirmation or password reset (see also Google Sign-In for social auth), it connects to an SMTP server that handles the actual delivery.

Every email provider (Gmail, Outlook, your company mail server) uses SMTP behind the scenes. When you configure Custom SMTP in Sticklight, you are telling your app to route authentication emails through your chosen provider’s servers instead of Sticklight’s default system.

This gives you control over:

• The sender address your users see
• Email deliverability and inbox placement
• Sending limits and quotas
• Your domain’s email reputation

Why Use Custom SMTP?

Sticklight includes a built-in mailer for testing, but it has limitations:

• Rate-limited to approximately 2 emails per hour
• Intended for development and testing only
• Emails come from a generic Sticklight address

With Custom SMTP, your authentication emails come from your domain. Your users see [email protected] instead of a system address. Emails are more likely to reach the inbox, and your brand stays consistent throughout the signup experience.

What Emails Does This Affect?

Custom SMTP controls delivery for authentication emails only:

• Signup confirmation
• password reset (see also Google Sign-In for social auth)
• Email verification links
• Magic link sign-in (if enabled)

This setting does not turn email verification on or off. That is controlled separately by the Require email verification toggle in Settings → Users → Authentication Settings.

Before You Start

You need an email sending provider with SMTP access. Common options include:

• Resend
• SendGrid
• Mailgun
• Postmark
• Amazon SES

Before configuring Sticklight, set up your provider:

1. Create an account with your chosen provider
2. Add and verify a sending domain (like mail.yourapp.com or auth.yourapp.com)
3. Add the required DNS records (typically SPF and DKIM)
4. Wait for domain verification to complete
5. Generate an API key or SMTP credentials

Using a dedicated subdomain for authentication emails (separate from marketing) protects your domain reputation and improves deliverability.

Configure Custom SMTP

1. Go to Cloud → Auth users → Authentication Settings
2. Expand the Custom SMTP card
3. Enter your SMTP details:

Field	Description
SMTP host	Your provider’s SMTP server (e.g., smtp.resend.com, smtp.sendgrid.net)
Port	Usually 587 for STARTTLS or 465 for SSL/TLS
Username	Varies by provider. For Resend, use resend. For SendGrid, use apikey.
Password / API key	Your SMTP password or API key
Sender email	The “from” address (must match your verified domain)
Sender name	The display name recipients see (e.g., “Your App”)
Email rate limit (per hour)	Match this to your provider’s allowed sending rate

1. Click Save SMTP settings

The status badge changes from Off to Custom SMTP once configured.

Security Notes

Your password or API key is stored securely and never displayed after saving. If you need to change it, click Update password and enter the new value.

Provider-Specific Examples

Resend

• Host: smtp.resend.com
• Port: 587
• Username: resend
• Password: Your API key
• Sender email: An address on your verified domain (e.g., [email protected])

SendGrid

• Host: smtp.sendgrid.net
• Port: 587
• Username: apikey
• Password: Your SendGrid API key
• Sender email: An address on your verified sender domain

Removing Custom SMTP

To revert to the built-in mailer:

1. Expand the Custom SMTP card
2. Click Remove SMTP settings

Your app returns to using Sticklight’s built-in mailer with its testing rate limits.

Security considerations when removing SMTP:

If you have been using Require email verification with Custom SMTP, removing your SMTP configuration has important implications:

• The built-in mailer cannot reliably send verification emails at scale (limited to approximately 2 per hour)
• Users who signed up with verified emails remain verified
• New users may not receive verification emails, leaving their email addresses unverified
• Allowing email/password authentication without email verification is generally considered a security risk, as it enables account creation with unowned email addresses

Before removing Custom SMTP, consider whether your app requires email verification. If it does, keep Custom SMTP configured or disable Require email verification and understand the security trade-offs.

Troubleshooting

Emails not arriving

• Check that your domain is verified in your email provider’s dashboard
• Confirm the sender email matches your verified domain
• Verify your API key or password is correct

Emails going to spam

• Ensure SPF, DKIM, and DMARC records are configured correctly
• Use a sender address on your verified domain, not a personal email
• Avoid promotional content in authentication emails

Authentication failed

• Double-check your username and password
• Some providers require the API key as the password field
• Confirm you are using the correct port for your provider

Port blocked

• Port 25 is blocked on many networks
• Try port 587 (STARTTLS) or 465 (SSL/TLS)

Rate limit errors

• Increase the email rate limit in your SMTP settings to match your provider’s allowance
• The built-in mailer is limited to approximately 2 emails per hour

Verification emails not sending

• If Require email verification is enabled without Custom SMTP, most verification emails will fail due to rate limits
• Configure Custom SMTP before enabling email verification for production use

Important Distinction

Custom SMTP controls how authentication emails are delivered. The Require email verification setting controls whether users must verify their email before logging in. These are independent settings. Configuring SMTP does not automatically enable or disable email verification.

FAQs

Do I need Custom SMTP for my app?

If your app uses email/password authentication and you want users to verify their email addresses, yes. The built-in mailer is rate-limited to approximately 2 emails per hour and is only suitable for testing. For production apps with real users, configure Custom SMTP.

Can I use Gmail or my personal email as the SMTP provider?

Technically possible, but not recommended. Personal email accounts have strict sending limits, lack proper authentication records (SPF/DKIM), and are more likely to be flagged as spam. Use a dedicated transactional email provider like Resend, SendGrid, or Postmark.

What is the difference between Custom SMTP and Require email verification?

Custom SMTP controls how emails are delivered (which servers send them). Require email verification controls whether users must click a link in their email before they can log in. You can have one without the other, but enabling verification without reliable email delivery means users cannot complete signup.

Why are my emails going to spam even with Custom SMTP?

New sending domains start with no reputation. Deliverability improves over time with consistent, legitimate sending. Make sure your DNS records (SPF, DKIM, DMARC) are correctly configured, use a sender address on your verified domain, and keep authentication emails simple and free of promotional content.

What happens if my SMTP credentials expire or become invalid?

Authentication emails will fail to send. Users attempting to sign up, reset passwords, or verify their email will not receive the expected messages. Monitor your email provider dashboard for delivery failures and update credentials promptly if they change.

Can I test my SMTP configuration before going live?

Yes. After saving your SMTP settings, create a test account in your app to trigger a signup confirmation email. Check that the email arrives from your configured sender address and that links work correctly.

Is it safe to allow signups without email verification?

It depends on your app. Without verification, anyone can create an account using any email address, including addresses they do not own. This can lead to abuse, fake accounts, and potential security issues. For most production apps, enabling email verification with reliable SMTP delivery is the recommended approach.