Supabase Custom SMTP: Configure Auth Email and Test the User Journey

TL;DR

• Supabase's default Auth mail service is intended for limited testing; configure an appropriate production delivery path for real users.
• Custom SMTP needs the provider's actual SMTP host, port and credentials, plus an authorized sender address.
• A REST email API is a different interface; use a supported Auth Hook integration when the provider does not offer SMTP.
• Test signup, recovery and invitation links through the complete application, including failure and expiry behavior.

Separate the Auth service from the delivery provider

Supabase Auth manages authentication workflows, while an email delivery service transports the messages those workflows produce. A problem can occur in either layer. Start by identifying whether the application requested the Auth action, whether a message was submitted and what the receiving user experienced.

The official custom SMTP guide describes the default service as a limited testing facility, including restrictions on eligible recipient addresses. For production, it documents custom SMTP configuration with a host, port, username, password and sender details. Check the current project and provider limits rather than assuming a test configuration is ready for a public launch.

Use an authorized test account that represents a real external user. Testing only with organization members can miss restrictions that affect everyone else.

Obtain the correct credentials

Choose a delivery service that explicitly supports SMTP if you intend to use the custom SMTP settings. Obtain its documented submission hostname, port and credential format. Do not put a generic REST API endpoint into the SMTP hostname field.

MailBlastr's public documentation describes its REST sending API. That documentation alone does not establish a drop-in SMTP configuration. If your chosen service is API-only, evaluate Supabase's Send Email Auth Hook and implement the supported server-side integration deliberately.

Keep credentials in the appropriate server configuration. They should not appear in a browser bundle, public repository, screenshot or support message. Use separate credentials for environments where the provider supports that arrangement, and document how to rotate them.

Configure the sender and domain

Use an address on a domain that the delivery provider has authorized. Complete the provider's required DNS setup and inspect an actual received message to confirm the intended authentication results. A successful SMTP connection is not a complete domain-authentication test.

If domain verification fails, diagnose the specific DNS record instead of repeatedly replacing credentials. Our domain-verification checklist explains how to distinguish record names, values and propagation from unrelated application errors.

Test each user journey separately

Create a small test matrix for signup confirmation, password recovery, magic links and invitations, covering the flows your application actually enables. Trigger each through the normal interface and follow the resulting link in the intended browser context.

Confirm that the destination is correct and that the user reaches the expected signed-in or recovery state. Check what happens when a link is expired, already used or opened in a different session. The message arriving in an inbox is only one step in the workflow.

Review email templates without replacing required variables or links with guessed URLs. A visually attractive button that drops an authentication parameter can break the journey. Keep security-sensitive values out of analytics URLs and ordinary application logs.

Diagnose failures by layer

If no provider submission appears, inspect the Auth request and the project configuration. If the provider rejects submission, use its sanitized error details to distinguish authentication, sender authorization and rate-limit issues. If the recipient server accepts the message but the user cannot find it, investigate the mailbox outcome separately.

Record the timestamp, environment, action type and available message identifier. These details help Supabase support and the delivery provider connect their evidence. Avoid sending them live recovery links, passwords or full credentials.

Use the application's own request identifier to connect the user action with delivery events where the integration supports it. This is particularly helpful when a user clicks “resend” several times and multiple attempts must be distinguished.

Prepare for launch traffic and abuse

Confirm how the application handles repeated requests and automated signups. A public authentication form can generate unwanted traffic even when the normal user journey is sound. Configure the supported rate limits and abuse controls before a large launch.

For an API-based Auth Hook, verify webhook authenticity using Supabase's documented method and design retries to avoid duplicate sends. Treat that as an integration requiring tests, not as a place to paste an unreviewed generic email request.

Keep a deployment checklist with the production sender, callback configuration, credential owner and test results. A reliable Supabase email setup is one where the intended user action succeeds, failures are diagnosable and the delivery interface matches the provider's actual capabilities.