Custom SMTP Server for Automatic Emails
Context
Section titled “Context”No SMTP configuration is required to send the automatic customer emails: by default they leave through ProAbono’s own mail server, and every message carries the sender address notification@proabono.com.
The address a customer sees therefore belongs to ProAbono, and nothing in the message points back to the merchant’s domain. Deliverability and sender credibility are worked on continuously, so these messages reach the inbox — but a sender the customer does not recognise holds less attention than the merchant’s own, and a message can be set aside unread for that reason alone.
A custom SMTP server closes that distance. Once one is configured, every automatic email leaves through that server, from an address on the merchant’s own domain — the sender the customer already knows.
The settings are held per segment. A business running several segments can send from a different address for each one, and a segment left unconfigured keeps ProAbono’s sender.
Sending is one or the other. For a given segment, either a custom SMTP server is configured and every automatic email leaves through it, or none is and ProAbono’s own server is used. The two are never mixed, and there is no automatic switch from one to the other.
What Changes for the Customer
Section titled “What Changes for the Customer”What a custom server changes:
- the sender address shown in the inbox, and the display name beside it;
- the address a reply reaches, which may differ from the sender address;
- the mail server the message transits through, and therefore the domain whose reputation the receiving server judges.
What it leaves untouched:
- which emails are sent, and on which events;
- the content and the layout of each message, which are edited from their own templates;
- the invoice or the credit note attached in PDF form;
- the record of every message in the Sent Emails list.
The Settings
Section titled “The Settings”| Setting | What it holds |
|---|---|
| Host | The host name of the SMTP server or relay, not an IP address. |
| Port | The port on which the server accepts authenticated submission. 587 and 465 are the usual values. |
| Username | The account used to authenticate — a technical account dedicated to ProAbono, not a person’s mailbox login. |
| Password | The password or API key of that account. |
| From | The sender address the customer sees. The server has to be authorised to send for it. |
| Reply-to | The address a reply is sent to. It is often a mailbox that collects bounces, so it may differ from From. |
| Display name | The name shown beside the sender address in the customer’s inbox. |
A port that works from a desktop mail client is no guarantee that it works here: the two connections do not come from the same network, and a relay may answer on one submission port and not on the other. Where the connection fails or times out on one of the two usual ports, the other one is worth supplying.
Requesting a Configuration
Section titled “Requesting a Configuration”The SMTP settings are not editable from the back office, on any plan. They are applied by ProAbono’s teams on request, so that the credentials never pass through a web form or a browser session. Finding no such fields under the Settings menu is expected, and is not the sign of a missing option.
Configuring an SMTP server is a licence feature and is not part of every plan — see What a ProAbono licence includes and the pricing page.
1. Create a Dedicated Credential
Section titled “1. Create a Dedicated Credential”- Create an account on the mail server, or a credential on the relay, used by ProAbono and by nothing else.
- Authorise it to send for the address chosen as From.
A person’s mailbox password is never reused for this. A dedicated credential can be revoked or rotated without locking anyone out of their mail, and it limits what its disclosure exposes.
2. Send the Settings to Support
Section titled “2. Send the Settings to Support”- Open a conversation with support, from the chat in the back office or by email to
support@proabono.com. - Ask for the secure link used to transmit credentials, and enter the settings in it. A password does not belong in a chat message or an email thread, where it stays readable for as long as the conversation is kept.
- State which segment, or which segments, the configuration applies to.
3. Set Up Deliverability for the Sending Domain
Section titled “3. Set Up Deliverability for the Sending Domain”Once the messages leave through the merchant’s own server, their deliverability is no longer a matter for ProAbono: it is decided by the sending domain and by that server. The SPF, DKIM and DMARC records of the domain, and the wider set of email-authentication practices around them, have to follow current best practice — the largest mail providers now expect all three.
- Have the technical team, or the provider that administers the domain, set the records up and keep them current.
These records live in the domain’s DNS zone, which ProAbono cannot reach.
4. Verify the Configuration
Section titled “4. Verify the Configuration”- Read the sender address, the display name and the reply-to address on a message actually received, rather than on a preview.
- Confirm that the message reached the inbox and not the spam folder, on at least one large mail provider.
- Open the Sent Emails list and check the sending status of the most recent messages.
Any later change on the mail server — a renewed certificate, a rotated credential, a new host or port — calls for the same verification, and for a new request to support, since the settings cannot be edited from the back office.
When the Automatic Emails Stop Arriving
Section titled “When the Automatic Emails Stop Arriving”Since there is no fallback, a configured server that can no longer be reached stops the sending rather than changing the sender. The Sent Emails list is where that shows: it records every message with its sending status, and filtering on that status surfaces the ones that did not leave. A wrong recipient address produces the same symptom for a single customer, so the number of messages affected tells the two apart.
On the merchant’s side the usual causes are a certificate that expired or was renewed with a different chain, a credential that was rotated or revoked, a relay that changed host or port, and a server that stopped answering. Each of them calls for a new request to support.
OAuth 2 Authentication
Section titled “OAuth 2 Authentication”OAuth 2 authentication against a mail server is not supported. The connection is made over SMTP, authenticated with a username and a password.
This matters where a mail provider withdraws basic SMTP authentication: a mailbox on such a provider can no longer be used directly. The way round it is a third-party SMTP relay that still accepts password authentication, with the SPF and DKIM records of the sending domain pointing at that relay.