Match the server, port and encryption mode
Lexoh email settings connect supported outgoing messages to a mail service through SMTP, the Simple Mail Transfer Protocol. The available messages, settings and sending permissions depend on your installation. Open the email configuration with an authorized administrator and confirm which workflows use it.
Obtain the SMTP hostname, port, encryption mode, authentication method and authorized sender from your mail administrator. Enter the hostname without an https:// prefix or a web-page path. Use the provider’s documented hostname rather than substituting an IP address.
Treat the port and encryption mode as a pair. With implicit TLS, encryption starts when the connection opens; with STARTTLS, the SMTP connection upgrades to TLS before credentials or message content are submitted. Require successful TLS and certificate validation. A secure connection to the sending server does not establish end-to-end message encryption.
587 and STARTTLS
A common message-submission combination, when supported by the provider and your Lexoh installation. Confirm that TLS is required, not merely attempted.
465 and implicit TLS
Use only when the provider documents it. A setting labelled SSL/TLS may mean implicit TLS; confirm its meaning instead of switching ports without changing the mode.
25 or 2525
Port 25 is also used between mail servers and for configured relay services; it is not simply obsolete. Port 2525 is a provider-specific alternative. Neither number alone guarantees encryption or authorization.
Use the authentication method approved for the account
Confirm the methods supported by both your deployed Lexoh version and the mail provider before entering credentials. A username/password form does not establish OAuth support. Do not assume a normal mailbox password, app password and SMTP-specific credential are interchangeable.
Use a dedicated sending identity with the permissions needed for the chosen sender. Enter secrets only in the approved configuration process. A masked password field does not prove encrypted storage; request the applicable security documentation if storage or key management must be verified.
Coordinate credential rotation with the administrator: update the sending configuration, test it, then revoke the old credential according to the account’s procedure. Keep passwords, tokens and active access codes out of screenshots and support tickets. Resolve an authentication mismatch with the provider and Lexoh support rather than disabling account protections.
Verify the sender and the reply destination
Choose a recognizable display name and a From address your organization is authorized to use. The display name helps recipients recognize the message; it does not authenticate the sender.
The visible From address, SMTP sign-in account, envelope sender used for delivery failures and Reply-To address can serve different purposes. If Reply-To is configured, replies may go there instead of From. Test the actual reply path. Naming an address noreply does not, by itself, prevent replies.
Your From domain does not need to be the same as the provider’s SMTP hostname. Ask the mail administrator to configure sender authorization and the domain’s SPF, DKIM and DMARC requirements. SPF checks permitted sending infrastructure; DKIM signs mail; DMARC checks alignment with the visible From domain and specifies handling policy. Passing these checks does not guarantee inbox placement.
Verify the trigger before enabling automatic messages
For an access-card email option, confirm its saved state, the recipient source and whether creation, assignment, resend or another action triggers a message. Check which credential types and customer or operator records are included. Do not assume the option is enabled by default or applies to every creation method.
Review an actual test message for the correct language, facility, entrance instructions, support contact and applicable validity period. Where a QR code or link is included, test readability and destination with a test credential. Template availability and the fields inserted into a message must be checked in your installation.
Creating a credential, generating a message, receiving it and being authorized at a reader are separate steps. An emailed card does not bypass its access rules, schedule or expiry. Resending a message does not necessarily create a new credential or revoke an old one.
Before a batch, test with controlled records and check the recipient count, duplicates and provider limits. Confirm queue and retry behavior before resending after a delay. Turning off future notifications may not recall queued or delivered messages. Keep an agreed alternative delivery procedure for visitors who cannot receive email.
Test submission, receipt and the real workflow
A successful test covers the path and recipient tested. It does not establish that all templates, recipients or automated triggers work. Use an authorized test mailbox and a harmless test record; the steps below describe a verification procedure, not a delivery-time guarantee.
- Record the environment, selected mail settings without secrets, sender and intended recipient. Confirm whether the test uses saved settings or the values currently in the form.
- Send one test using the available control. Record its time, application result and message reference if provided. Avoid repeated clicks while the result is pending.
- Compare the application result with available provider logs. Distinguish connection, TLS, authentication, submission, queueing, rejection and recipient-server delivery.
- Check the recipient’s inbox, junk folder and any organizational quarantine. Inspect the sender, reply destination, language, links and attachments. Record actual arrival time rather than assuming a fixed delay.
- Test the relevant automatic trigger with a controlled record. For an access credential, separately verify the intended reader, schedule and validity using the site’s test procedure.
- Check an approved failure case, such as a provider test address or test mode, before relying on error handling. Establish who monitors failures and whether retries can duplicate messages. Do not use an unrelated person’s address as a test.
| Observation | What it establishes |
|---|---|
| Credential created | The test record exists. No delivery or reader authorization has yet been shown. |
| Application reports sent | Check the meaning of this status and the provider reference. It may describe submission rather than final delivery. |
| Provider records recipient-server acceptance | The receiving system accepted the message. Inbox placement, reading and identity are still separate checks. |
| Message visible in the test inbox | Receipt at this mailbox is verified. Check the content and reply route. |
| Test credential accepted at the intended reader | That credential worked under the tested conditions. Other readers, schedules and expiry still need their own checks. |
Confirm current provider requirements
Provider references checked on 30 September 2026. These notes describe provider requirements, not certified Lexoh integrations. Confirm your account policy, region, sending limits and the authentication methods available in your installation.
Google accounts
App passwords require 2-Step Verification and may be unavailable under account or organization policies. Google prefers Sign in with Google where supported. Confirm an approved compatible sending method rather than assuming every Google account can generate an app password.
Microsoft 365 / Exchange Online
Microsoft documents smtp.office365.com with STARTTLS on port 587 for client submission and recommends OAuth. Verify mailbox and organization policy plus the application’s authentication support. Personal Outlook.com accounts use separate guidance. Do not treat a mailbox password as a universal setup.
Twilio SendGrid
SendGrid documents smtp.sendgrid.net, username apikey and an appropriately permitted API key as the SMTP password. Confirm the provider’s TLS/port combination and sender authorization. The account sign-in password is not this SMTP credential.
Mailgun
Use the SMTP credentials for the selected sending domain and its documented endpoint. Confirm the account region and TLS/port pair. Do not substitute an API key for a domain’s SMTP password or assume a sandbox has production recipient permissions.
Investigate the failing stage
Keep a short test log with expected result, observed result, time and message reference. Escalate with the relevant evidence and no secrets. After a correction, repeat the failed case and one successful workflow before extending the change to more recipients.
Connection or TLS failure
Check the hostname, approved port/mode pair, DNS, outbound network policy, server time and certificate validation from the system that sends the mail. Do not bypass certificate checks or switch to an unencrypted mode to hide the error.
Authentication or sender rejection
Capture the exact response without credentials. Verify credential type, account state, allowed authentication and Send As or sender-verification permissions. A correct password does not resolve a policy or sender-authorization failure.
Accepted but not received
Check the recipient, provider reference, queue, bounce or suppression information and the recipient’s quarantine. Review domain authentication with the mail administrator. Diagnose before resending to avoid duplicates.
Test message arrives but automation does not
Check the trigger, saved option, recipient field, template and queue for the actual workflow. A generic test may not exercise those components.
Wrong content or unusable credential
Compare the associated test record, language, validity, destination and reader configuration. Correct the responsible template or access rule; sending another copy alone may not fix the underlying problem.