Login Email Setup
Brainbase sends login and invitation email through Amazon SES in your AWS account, in us-east-1. Release 2026-09-16.1 creates the sender identity, DKIM DNS records, SMTP credentials, and email-feedback resources. SES production approval is a separate customer-account step, not part of the Marketplace purchase or CloudFormation completion.
1. Verify the sender and account
- Open Amazon SES in us-east-1. Confirm you are in the account that owns the stack.
- Under Verified identities, open your deployment domain, such as
brainbase.example.com. Check identity verification and DKIM both succeeded. The sender isno-reply@<deployment-domain>; do not manually create replacement SMTP credentials. - Check the account dashboard for sending enabled, account health, sandbox/production status, and sending limits. If the account is paused, under review, or unhealthy, resolve that with AWS rather than repeatedly requesting login links.
- If verification is pending, inspect the public Route 53 zone and delegation. A certificate or identity record in the wrong zone cannot validate the domain.
CREATE_COMPLETE and a healthy app do not prove SES has verified the sender. Before requesting a login link, wait for the deployment identity to be verified and DKIM to show SUCCESS. SES sandbox recipient restrictions still apply even after sender verification.If DKIM is pending, compare all three CNAME names and targets shown under the SES identity's Authentication tab with the installer-created records in your public Route 53 zone. Verify they resolve publicly, not just inside the AWS console. Do not delete the stack or recreate the identity merely because verification is pending. AWS notes that DNS propagation can take up to 72 hours. Fix missing or incorrect records first; if correct public records remain unverified after that window, contact AWS Support.
Optional read-only SES status checks
Use AWS CloudShell or AWS CLI v2 authenticated to the deployment account. Replace the example domain before running. Neither command sends email.
aws sts get-caller-identity --region us-east-1
aws sesv2 get-account --region us-east-1 \
--query '{Production:ProductionAccessEnabled,Sending:SendingEnabled,Health:EnforcementStatus,Quota:SendQuota,Review:Details.ReviewDetails}'
aws sesv2 get-email-identity --region us-east-1 \
--email-identity brainbase.example.com \
--query '{Verified:VerifiedForSendingStatus,Dkim:DkimAttributes.Status,ConfigurationSet:ConfigurationSetName}'
Expect production and sending true, health HEALTHY, sender verified true, DKIM SUCCESS, and a configuration set. These checks do not prove feedback delivery or a successful sign-in; complete the remaining steps.
2. Confirm notifications and establish feedback handling
The AlarmEmail inbox receives two SNS subscription confirmations: one for infrastructure alarms and another for Brainbase email feedback. Confirm both after checking that they match your stack's SNS topics. These are operations subscriptions, not SES verification messages for application users.
- In CloudFormation Resources, locate the stack-owned SNS topics. Open their subscriptions and verify the operations email is confirmed, not PendingConfirmation. For the email-feedback subscription, leave the filter policy unset so bounce and complaint events are not dropped.
- In SES, open the deployment identity and its default configuration set. Check sending and reputation metrics are enabled, suppression covers both bounces and complaints, and an enabled SNS event destination includes both event types and points to the feedback topic.
- Assign an operator to monitor the inbox. Stop sending to complainants; investigate hard bounces and correct invalid addresses through an authenticated support process. Do not repeatedly retry them or bulk-clear suppression.
- Review the stack-created 3% bounce-rate and 0.05% complaint-rate alarms in CloudWatch. They notify an operator; they do not automatically pause login email. Also monitor regional SES account health and quotas.
- Protect feedback notifications: they contain recipient addresses and message metadata. Limit inbox access and apply your retention policy. Never put login links, tokens, or SMTP credentials into support tickets.
Suppression uses SES's regional account list, not a private per-appliance list. Other senders in the account can affect account health. If your account already has a feedback process, have its operator review compatibility; do not replace existing controls simply to follow this walkthrough.
3. Test the feedback path
- In SES Verified identities, select the deployment-domain identity and choose Send test email. Use
no-reply@<deployment-domain>as the sender and send a plain test message tobounce@simulator.amazonses.com. - Send a second plain test message to
complaint@simulator.amazonses.com. Do not include user content or login tokens. Do not override the configuration set: test that the sender identity default routes feedback. - Verify the operations inbox receives both SNS notifications with the expected bounce/complaint event types and matching message IDs. A confirmed subscription alone is not proof of delivery.
- If notifications do not arrive, check the default configuration set, event destination, SNS subscription/filter, topic permissions, and spam filtering before requesting production access.
AWS's mailbox simulator works in the sandbox without damaging sender reputation. It does not prove real-recipient suppression or trigger reputation-rate alarms. This console check validates feedback routing; the actual Brainbase login test below separately exercises the application's SMTP path.
4. Request SES production access
If this account is already in production in us-east-1, skip the request and test delivery. Otherwise, in SES Account dashboard open Get set up and Request production access. Choose Transactional, supply your real website and operations contacts, and have the account owner acknowledge requested recipients and an operating bounce/complaint process.
Explain that you operate a self-hosted Brainbase deployment sending user-requested login links and administrator-issued invitations to intended users. Describe your actual recipient controls, monitored feedback inbox, suppression, and response process. Supply realistic volume estimates if asked. Do not claim controls you have not checked or use another company's approval details as your own.
Submission is not approval. Monitor the SES review and associated AWS Support case; respond to requests for information. AWS describes an initial response within 24 hours, but approval can take longer. Follow the production-access procedure. No stack redeployment is required merely to pick up approval.
Optional pilot while waiting
In the SES sandbox, recipients must have a verified email address or be covered by a verified recipient domain. For a small consenting pilot, an administrator can create an email identity for the first user in SES and ask that person to complete the SES verification email before requesting a Brainbase login link. Sandbox sending limits still apply.
brainbase.example.com does not verify recipients at example.com. Do not add or verify a parent-domain identity without the domain owner's authorization. A pilot with verified recipients does not prove production email readiness.5. Complete a real login after approval
- Confirm SES shows production access and healthy sending in
us-east-1. - Use a consenting, provisioned Brainbase user whose recipient address and domain are not SES-verified. Check Verified identities first; a verified parent domain can cover an address even when the address is not listed separately.
- Have the user open
https://app.<your-domain>, request a magic link, confirm the email arrives, and open the newest link in the same browser/profile to complete sign-in. - Confirm the user reaches the workspace with the intended permissions. Email receipt alone is not a successful login. For new users, ask the deployment administrator to provision an account/invitation and appropriate team access; public signup remains closed.
Return to the first agent task. If delivery or sign-in fails, use troubleshooting. For older installations without the feedback resources, plan a reviewed stack update with your operator rather than deleting or replacing a live sender configuration set.