Transactional email setup.

Transactional email is a production dependency from day one. Reward Loyalty sends OTP sign-in codes and operational messages by email, so a live installation needs a provider designed to deliver that mail and report what happened.

Host SMTP is an evaluation fallback. Gmail is testing-only, never the recommended production route.

Choose a supported transport

Reward Loyalty uses Laravel's mail system. The shipped configuration supports these production transport paths:

The configuration also contains local and diagnostic mailers such as log, array, and Mailpit. They do not deliver a production OTP to a real inbox. sendmail depends on a working local mail transfer agent and is not the default self-hosted recommendation.

Sending-domain strategy

Use a dedicated transactional sending domain or subdomain, such as notify.example.com. Keep the visible From address recognizable to members, and use a monitored Reply-To address when replies should reach a person.

Separating transactional identity from bulk marketing makes ownership and reputation easier to inspect. It does not remove the need to authenticate every service that sends for the parent domain.

Before adding DNS records, inventory existing senders. Then configure:

• SPF, or the provider's aligned return-path record, so receiving systems can identify authorized infrastructure;
• DKIM, so the provider signs mail with a key published in your DNS;
• DMARC, so the domain owner sets alignment policy and receives reports.

Publish only one SPF policy for a hostname. Follow the selected provider's exact records instead of combining examples from different services. Start DMARC monitoring with a policy and reporting plan that fits your existing mail estate, inspect the reports, then tighten enforcement when every legitimate sender aligns.

SMTP settings

Set the mailer and provider-issued values in .env:

MAIL_MAILER=smtp
MAIL_HOST=provider-smtp-host
MAIL_PORT=587
MAIL_USERNAME=provider-issued-username
MAIL_PASSWORD=provider-issued-secret
MAIL_ENCRYPTION=tls
[email protected]
MAIL_FROM_NAME="Your loyalty program"

Use the port, encryption mode, username, and secret shown by the provider. Do not paste a normal mailbox password when the provider issues a separate SMTP credential. Store production credentials in the host's protected configuration and never in source control.

Brevo through SMTP

Brevo documents its SMTP relay integration, including provider-issued SMTP credentials, in its SMTP integration guide. Use the SMTP key where Brevo requires it, not an unrelated API key. Configure the exact hostname, port, and encryption combination shown in the current Brevo account.

Add and authenticate the sending domain using Brevo's domain authentication and verification guide. Confirm the domain shows authenticated after DNS propagation before testing Reward Loyalty.

SMTP2GO through SMTP

SMTP2GO publishes its current server, ports, and authentication path in SMTP Settings. Create a dedicated SMTP user for Reward Loyalty and use the provider's supported encrypted port.

Verify a sender domain. SMTP2GO explains how its records cover SPF and DKIM, while DMARC remains a domain-level TXT record, in SPF, DKIM and DMARC Overview.

API transport settings

When using Mailgun, SES, Postmark, or Resend, choose the matching MAIL_MAILER and set the credentials required by the shipped config/services.php, config/mail.php, and provider package.

Do not copy credentials between providers or assume an SMTP password is also an API token. Use the provider's first-party setup and sender-authentication documentation for the selected transport.

Bounce and complaint handling

Delivery is an operating loop, not a one-time DNS task.

1. Review provider activity for delivered, deferred, bounced, rejected, and complained messages.
2. Stop sending to an address after a hard bounce unless you correct the address and the provider permits a retry.
3. Keep complaint addresses suppressed unless the recipient confirms the complaint was accidental.
4. Investigate spikes in soft bounces, authentication failures, or deferrals.
5. Monitor the Reply-To inbox and DMARC reports.

Brevo exposes transactional activity for delivery review in its transactional activity API documentation. SMTP2GO documents bounces and rejections and spam complaint handling.

Reward Loyalty cannot repair a provider suppression or a receiving mailbox policy from the admin dashboard. Keep provider access and alert ownership with the person responsible for production email.

After installation: prove a real OTP arrives

Complete the provider, credential, and DNS sections before installation. Run this test only after you install Reward Loyalty, and run it from the application rather than the provider's generic test button.

1. Open the Reward Loyalty admin sign-in page in a private browser window.
2. Request an OTP for a real inbox you can inspect.
3. Confirm it arrives without delay and does not land in spam.
4. Inspect the message headers and provider activity. SPF, DKIM, and DMARC should show the expected aligned result.
5. Use the OTP to complete admin sign-in.
6. Repeat with a second mailbox provider when practical.

A provider dashboard that says delivered is useful evidence, but the required smoke test is an OTP that arrives and completes Reward Loyalty sign-in.

Evaluation fallbacks

Host SMTP can unblock an evaluation when the host supplies authenticated settings and allows the traffic. It is not the production baseline because visibility, rate limits, reputation controls, and support vary by host. Record its disclosed limits and replace it with a transactional provider before launch.

Gmail is testing-only. If a short-lived test uses Gmail SMTP, use Google's current account security flow and never store a personal account password. Do not publish Gmail as the production recommendation.

Continue

After a real OTP succeeds, finish the post-install checklist and inspect mail status in the Health Center.