Setting up outgoing email delivery

Connect an outgoing delivery service so Cedros can send messages from the addresses your business uses. A working inbox does not automatically mean sending is ready: the provider, sender or domain authentication, and a real delivery test each need to succeed.

This guide covers the site's outbound setup. For incoming mail and the first Cedros mailbox, use Setting up Cedros email on your domain. For the meaning and verification of individual DNS records, use Understanding and verifying your email DNS records.

Choose the sending path you need

Check which kind of message you are setting up:

• Cedros-hosted mailbox messages use the native mail service's Amazon SES connection. Selecting another provider for the site's other email does not replace that native SES requirement.
• Google Workspace mailbox messages use the connected Google account's sending access. Follow Connecting your Google Workspace account; a successful Google send does not establish that the site's separate campaign or notification delivery is configured.
• Other site email, such as campaigns and notifications, uses the applicable site sending setup. On a self-managed site, Settings → Providers → Email offers provider configuration. A managed site may supply delivery through Cedros and hide customer credential fields.

Before changing an existing provider, identify the messages already using it and the addresses they send from. Provider changes can affect more than the one inbox you are looking at. Plan a test for each important message type, including automated mail, before treating the change as complete.

Have access to the site's provider settings, the sending account, and any DNS records needed for authentication. Use an independent recipient address you control for testing. Enter credentials only in the intended provider fields, not in email, chat, or a support screenshot.

Connect Amazon SES on a self-managed site

Open Settings → Providers → Email and select Amazon SES in Provider. If the panel already says SES connected and Provider record: active / connected, review the existing connection before replacing it.

For a new connection:

1. Under Connect Amazon SES securely, start with Verify a sender. Use Open Amazon SES and confirm that AWS shows a verified email address or domain appropriate for your intended mail. See AWS's identity verification instructions.
2. Select Download AWS setup in Cedros. Use the file generated for this site's setup rather than an old file from another installation.
3. Follow Open AWS CloudFormation. In the intended AWS account, choose Upload a template file, upload the downloaded file, and use the stack name shown by Cedros. Review the requested access and the IAM acknowledgement with your AWS administrator, then create the stack.
4. Wait for the stack to show CREATE_COMPLETE. A stack that is still creating or has failed is not a completed connection.
5. Open the stack's Outputs tab and copy CedrosConnection. Return to Cedros and paste that complete value into AWS connection.
6. Wait for automatic connection and saving to finish. Read any error and confirm SES connected and the saved status before leaving. The message Connection ready — connecting automatically means work is still in progress.

This connection uses temporary AWS credentials. The setup does not ask you to create an AWS access key, paste an IAM secret key, or enter an SES SMTP password. Cedros discovers a verified sender and region and sets up sending and delivery tracking. Check the resulting sender in the messages you test; discovery can select a default, and it does not mean every address on your site has been tested.

If the page says secure SES setup is temporarily unavailable, try again later or contact the site administrator with that message. Do not substitute an unrelated AWS credential to bypass it.

Provider edits save automatically. Read the save-status message: a field containing a value is not proof that the server accepted it. If saving fails, resolve the reported cause and use the offered retry action.

Finish native-mail authentication and account readiness

For Cedros-hosted mailboxes, return to Settings → Site → Mail and check the intended Mail domain. If offered, select Finish SES setup or Retry automatic setup. Follow the resulting status and DNS instructions until the domain shows SES verified.

Use the generated DKIM and bounce-domain records for this domain and sending region. Managed DNS or an available Cloudflare connection can publish records automatically; otherwise, coordinate manual entry with the DNS administrator. The email DNS guide explains the exact-entry and verification steps. Changing incoming MX records is not a remedy for an outgoing authentication failure.

For native mailbox sending, confirm that the address and mail domain are active as well as authenticated. Cedros recognizes eligible native addresses without requiring you to manually add them in Verified outbound senders. That does not remove the need for SES readiness or permission to send from the mailbox.

Check the provider account's sending restrictions separately. Amazon SES sandbox status is regional: a verified sender can still be unable to send to an unverified recipient. If Cedros shows Request production access, or AWS reports sandbox restrictions, have the AWS administrator follow the production-access process. Account approval and sender verification are separate; completing one does not complete the other.

On a managed site, use the managed-service status and ask the person responsible for the site's email service to resolve a provider problem. Do not create a separate AWS account just because the self-managed fields described above are absent.

Check Mail service for an SES outbound warning, but also test the sending path you actually use. Provider connection status, domain verification, mail-service health, and delivery to a recipient describe different parts of the setup.

Configure another external provider when needed

For a self-managed site's external sending, the Provider selector also supports Mailgun, Postmark, and a custom SMTP connection. Choose the service already intended for your site and follow the instructions displayed for it. This selection does not move incoming mail or reconfigure a Google account.

• Mailgun: choose the Region matching the sending domain and enter the sending API Key in the corresponding field. The public email-validation key cannot send messages. Verify the sending domain with Mailgun. Its region documentation explains the separate US and EU endpoints.
• Postmark: use the Server API Key for the server that will send the messages, and complete the sender/domain verification in Postmark. The Account API Key serves a different purpose. Postmark's sending guide covers the server token and verified sender requirement.
• Custom SMTP: use the SMTP Connection URL supplied or assembled according to the mail administrator's instructions, with the correct host, port, authentication, and encryption. Treat the complete URL as a credential. A mailbox app password and the site's provider connection are different setup tasks; do not copy one into the other without checking what the service expects.

Wait for the provider settings to save and read the resulting status. Do not switch providers experimentally on a live site: the choice is saved configuration, not an isolated test selector.

Delivery feedback is separate from permission to submit a message. For Mailgun, Cedros offers an optional HTTP Webhook Signing Key; for Postmark, it offers an optional Webhook Basic Auth credential and Generate webhook credential. Follow the displayed provider-event webhook instructions if you need delivery events recorded in Cedros. Protect those credentials, and confirm feedback after a controlled send. A missing feedback event alone does not prove the message was never sent.

If you send campaigns, also review Compliance footer on the Email provider panel. Check the organization and contact details and the subscription note for your audience. A working provider connection does not establish that a list, campaign, or unsubscribe flow is ready for broad sending.

Verify the external sender address

For an external provider, authentication must cover the actual From address, not merely a similar domain or another mailbox. Review any sender already created during connection before adding another.

1. Open Settings → Site → Mail and expand Other mail providers.
2. Find Verified outbound senders and check the existing address and status.
3. If the required sender is missing, expand Add a verified sender. Select the intended Provider, enter Sender email, and optionally enter Display name.
4. Select Add sender. Creating the row does not verify it or create a receiving mailbox.
5. Select Verify now on the sender and read the returned status or error. Complete any remaining provider or DNS requirement before trying again.

If no provider is available in the form, finish provider setup first. If an address is verified for a different provider, do not assume it is ready for the one now selected. If the provider says it is verified but Cedros still reports a missing requirement, give the administrator both results so they can reconcile the setup.

A display name changes the friendly name seen by recipients; it does not authorize an address. A Reply-To address, where configured by the message's workflow, must also lead to an inbox your team monitors. Check both in the delivered message.

Send a controlled test from the intended address

Test an ordinary message to an independent address you control. Start without attachments so the result is easier to diagnose.

1. Open Email → Inbox and select New email.
2. Read From. If Change appears, use it to select the intended sendable mailbox. Confirm the displayed address before continuing; a test from the wrong mailbox proves a different setup.
3. Add your independent address to To, enter a distinctive subject such as “Cedros outgoing test,” and write a short message. Make sure the recipient has been accepted into the recipient field.
4. Use an immediate send for this test. If a schedule is set, select Send now instead before selecting Send. Let any Undo send countdown finish and read the result.
5. Check the recipient's inbox and spam folder. Open the message and verify the sender, subject, body, and Reply-To behavior. A queued or accepted send is not proof of receipt.
6. Reply from the independent address and confirm that the response reaches the intended business inbox.

If you do not have a sendable mailbox for an external-only setup, use a test action in the actual campaign or notification workflow you intend to use, addressed only to your controlled recipient. Confirm its From address and delivery in the same way. Do not create an unnecessary native mailbox just to test a separate notification provider.

Repeat the relevant test for automated messages you depend on. A successful inbox message does not prove that a campaign, system email, or scheduled queue uses the same sender and settings. Use the workflow's test facility where available, then inspect the actual received message.

Mail service → Test delivery checks delivery within your Cedros mail service. Read its completed result, but do not use it to verify outgoing delivery through Amazon SES. Test sending to an outside account and confirm receipt there as described above.

If setup is saved but mail still fails, follow Why can I receive email but not send it?. If recipients find your messages in Junk, use Why are my emails going to spam?.

Repair an incomplete connection without starting over

If an existing SES connection needs a permissions update, use Update AWS permissions when offered, or Update or change AWS connection. Download the current setup file and follow the instructions to update the existing Cedros CloudFormation stack. Wait for UPDATE_COMPLETE.

For a permissions-only update, leave AWS connection blank to keep the saved connection. Cedros can detect the updated permissions and retry. Paste a new CedrosConnection value only when intentionally replacing the stack. Cancel change closes the replacement controls; it does not disconnect the existing service.

For other failures, follow the specific result:

• Provider not configured or not saved: check the selected service, required fields, and save error. Retry after correcting the cause.
• Sender unverified: confirm the exact address/domain and provider, finish authentication, then verify again. Do not replace the From address with one you do not control.
• Sandbox or provider approval restriction: resolve the account restriction; changing incoming MX will not help.
• DNS or Cloudflare failure: compare generated records with published values and repair the existing DNS connection where needed.
• Message queued or delivery uncertain: inspect its current result and provider activity before resending. An uncertain result can still have reached the recipient.
• Message accepted but not seen: check the destination address, spam folder, provider feedback, and any bounce or rejection. Acceptance is only one stage of delivery.
• Recipient suppressed: investigate the recorded bounce, complaint, or unsubscribe reason. Do not remove a suppression merely to force a test through; use another eligible address you control.

For support, provide the site, selected provider, intended From address, time and subject of the test, observed status, and error text. Remove credentials and unnecessary message content from screenshots. Keep the existing connection in place while investigating unless the administrator has identified a reason to replace it.

Outgoing setup is complete when the intended provider is saved, the actual sender is authorized, applicable domain/account requirements pass, and messages sent through each required workflow reach your test recipient with the right identity and reply behavior.