Mail and SMTP

Outcome

You will know how hosted email behavior works by default, when to use custom SMTP, and what to verify after changing mail settings.

Default vs Custom SMTP

Default mail

Hosted sites can send mail without any custom SMTP configuration. The sender identity is derived from the site name and site domain so outbound mail looks consistent with the site it came from. This is the right choice for most marketing sites, forms, and transactional notifications.

• No configuration required.
• Sender identity follows the site domain.
• Delivery is handled by the hosted mail path.
• Suitable for password resets, form notifications, and routine transactional messages.

Custom SMTP

Use custom SMTP when your organization needs a specific mail relay, authentication method, or sender policy that differs from the default hosted behavior. Common reasons include using a corporate relay for compliance, sending from a domain that is not the site domain, or routing through a transactional provider for higher deliverability and reporting.

• Requires SMTP host, port, encryption, and credentials.
• Sender domain must align with your SPF and DKIM records on that domain.
• Test thoroughly before rolling out to production traffic.
• Keep credentials in a password manager and rotate them on a schedule.

What You Can Configure

Setting	What it controls
Sender name	The friendly name that appears in the From header.
Sender email	The address used as From. Should match a domain you own and authenticate.
Reply-to	The address replies are routed to. Useful when sending from a no-reply identity.
Blind copy	Optional BCC recipient for outbound site mail, where supported.
SMTP host and port	The relay you are sending through, with the port your provider requires.
Encryption	TLS or SSL, per your provider’s documentation.
Authentication	Username and password (or app password) for the relay.
Test email	Sends a one-off message so you can confirm the relay and identity end to end.

SPF, DKIM, and DMARC in one minute

Three DNS-based standards determine whether mailbox providers trust mail claiming to come from your domain.

• SPF lists the servers allowed to send mail for your domain. Defined in RFC 7208.
• DKIM cryptographically signs each message so recipients can verify it was not modified in transit. Defined in RFC 6376.
• DMARC tells mailbox providers what to do when SPF or DKIM fails and reports the results back to you. Defined in RFC 7489.

If you switch to custom SMTP or send from a new domain, update all three before high-volume sending. A deliverability glossary in your DNS provider’s docs is usually enough to set them up; otherwise ask the relay provider for the exact records to add.

When To Use Custom SMTP

Use custom SMTP only when the default behavior does not meet a specific requirement. The default path is the easiest to support, so changing it adds responsibility for monitoring deliverability on your side. Reasonable triggers include:

• A compliance requirement that all mail flow through a specific relay.
• A separate transactional provider with its own analytics and warm-up.
• A sender domain that does not match the site domain.

What Success Looks Like

• Site mail is delivered from the sender identity you intended.
• Password resets, form notifications, or transactional messages arrive as expected.
• You have a clear rollback plan if custom SMTP causes issues.

Related Troubleshooting

Use Hosted Troubleshooting if mail stops sending, lands with the wrong sender identity, or behaves differently after an SMTP change.