> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure Email Delivery

> Choose how Living Security sends transactional and training email: platform delivery, your verified domain, or your SMTP server.

Email Delivery controls transactional and training email, including supported assignments, nudges, welcome messages, and operational notifications. Open **Settings → Communications → Channels** and select **Email**.

<Warning>
  Phishing simulation sender infrastructure is configured separately. Changing
  Email Delivery does not configure or authorize a phishing simulation sender.
</Warning>

## Choose a Sending Method

| Method                       | Infrastructure    | Sender                                          | Setup required                                          |
| ---------------------------- | ----------------- | ----------------------------------------------- | ------------------------------------------------------- |
| **Living Security delivery** | Living Security   | Shared Living Security sender                   | None; this is the default                               |
| **Your domain**              | Living Security   | A verified domain and From identity you control | DNS verification and activation                         |
| **Your SMTP server**         | Your organization | Sender accepted by your SMTP server             | SMTP server, TLS, and authentication or IP allowlisting |

Only one method is active at a time. Inactive custom settings remain saved unless you remove or disable them.

<Note>
  Custom domain and SMTP delivery require the Custom Email Delivery capability.
  If those choices are not visible, contact your Living Security account
  representative.
</Note>

## Use Living Security Delivery

Choose **Living Security delivery** when you want Living Security to manage both the sending infrastructure and sender.

1. Open the Living Security delivery card.
2. Select **Use this method** if another method is active.
3. Send a test message.

No DNS or SMTP credentials are required. The active-method card shows the From name and address used by your environment.

## Use Your Domain on Living Security Infrastructure

Choose **Your domain** when messages should use your organization's From identity while Living Security continues to deliver them.

### Prerequisites

* Living Security administrator access
* Permission to edit DNS for the sending domain
* A dedicated subdomain such as `training.example.com` or `security.example.com`
* An approved From display name and email prefix

Using a subdomain isolates Living Security mail reputation from your root corporate domain.

<Steps>
  <Step title="Enter the sender">
    Open **Your domain** and enter:

    * **Domain** — domain only, without `@` or a URL
    * **From display name** — the name recipients see
    * **From email prefix** — the part before `@`
    * **Return path subdomain** — optional bounce-handling subdomain
  </Step>

  <Step title="Publish the DNS records">
    Copy every record exactly as shown into your DNS provider. Records typically
    include CNAME records used for domain authentication and DKIM. If your
    provider automatically appends the root domain, avoid entering it twice.
  </Step>

  <Step title="Verify records">
    Return to Living Security and select **Verify records**. DNS changes often
    appear quickly but can take up to 48 hours. Keep the records in DNS after
    verification.
  </Step>

  <Step title="Activate the sender">
    After all records show **Verified**, save the sender identity and select
    **Activate sender**. Verification proves control of the domain; activation
    makes it the current sending method.
  </Step>

  <Step title="Send a test">
    Send a message to a recipient in your organization and review the result in the Communications Log.
  </Step>
</Steps>

You can choose **Use platform delivery** to deactivate the domain without deleting it. **Remove domain** deletes its Living Security configuration and returns email to the configured platform route; remove obsolete DNS records only after confirming they are not used elsewhere.

## Use Your SMTP Server

Choose **Your SMTP server** when policy requires Living Security to relay transactional and training messages through infrastructure your organization controls.

### Prerequisites

* SMTP host and port
* Supported TLS mode: STARTTLS or TLS wrapper
* From address and optional From display name
* One supported authentication method:
  * username and password
  * OAuth 2.0 credentials and refresh token
  * IP allowlisting without SMTP authentication

<Steps>
  <Step title="Allow Living Security egress when required">
    If your relay uses IP allowlisting, copy the static IP fleet shown in the SMTP section and allow it on your server. Use only the IPs displayed for your deployed environment.
  </Step>

  <Step title="Enter SMTP settings">
    Provide the host, port, TLS mode, authentication fields, and sender. Confirm
    the relay accepts the sender and recipient domains you intend to use.
  </Step>

  <Step title="Save the transport">
    Select **Save**. Stored secrets are encrypted and are not shown again. To
    rotate a secret, enter the replacement value and save it.
  </Step>

  <Step title="Activate and test">
    Select the SMTP method, then send a test. The test uses the active delivery route and records provider or SMTP diagnostics in the Communications Log.
  </Step>
</Steps>

If the method shows **Needs attention**, email is not silently rerouted through the shared sender. Correct or disable the SMTP configuration, or deliberately select another sending method.

## Verify Delivery

Every method includes **Send a test**:

1. Enter a recipient you can inspect.
2. Send the test.
3. Open **Settings → Communications → Log**.
4. Confirm the message's route and delivery status.
5. For a failure, inspect attempts, rejected recipients, provider details, and SMTP response codes when available.

An “accepted” test means the communication pipeline accepted the message; use the log and recipient mailbox to confirm final delivery.

## Troubleshooting

<AccordionGroup>
  <Accordion title="DNS verification remains pending">
    Compare each public DNS record with the value shown in Living Security. Check for copied whitespace, a duplicated root domain, proxying by the DNS provider, or an unexpired previous TTL. Wait up to 48 hours before escalating.
  </Accordion>

  <Accordion title="A verified domain is not being used">
    Confirm **Your domain** is the active sending method. Verification and
    activation are separate steps.
  </Accordion>

  <Accordion title="SMTP authentication fails">
    Confirm the authentication method, username, secret or refresh token, TLS
    mode, and port. For IP allowlisting, confirm every static IP displayed in
    Living Security is allowed by the relay.
  </Accordion>

  <Accordion title="The test is accepted but not delivered">
    Open the Communications Log and inspect the latest attempt. Then check the
    recipient system's quarantine, sender restrictions, relay policy, and
    rejection details.
  </Accordion>

  <Accordion title="Custom delivery choices are missing">
    Your organization may not have Custom Email Delivery enabled. Contact your account representative instead of configuring phishing-sender settings as a substitute.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Communication Log" icon="clock-rotate-left" href="/features/communications/log">
    Review delivery attempts and diagnostics.
  </Card>

  <Card title="Delivery Policies" icon="shield" href="/features/communications/delivery-policies">
    Control supported communication timing and delivery behavior.
  </Card>

  <Card title="Microsoft Teams" icon="microsoft" href="/integrations/outbound/teams">
    Configure Teams as another notification channel.
  </Card>

  <Card title="Communications Overview" icon="comments" href="/features/communications/overview">
    Understand channels, policies, queue, and history.
  </Card>
</CardGroup>
