Sending Portal Email from Your Own Domain

Out of the box, portal email is sent by Pental. It works, and there is a button that keeps it that way deliberately if you are not ready. But the address is not yours, and a client receiving an invitation from a name they do not recognise is a support call waiting to happen. The setup is in two places, and knowing which is which saves a lot of hunting.

The connection: your pental.io dashboard

Sign in at pental.io, open Portal Settings, and choose which address email should come from. You give it the host, the port, the username and the password for your own mail service, along with the sender name and address clients will see.

Send the test email before you save. The screen offers it for a reason: a wrong port or a blocked password is much easier to see now than after the first client invitation bounces.

• Publish SPF and DKIM for the sending domain, or your invitations will land in spam and the portal will get the blame.
• Send the test to an address on a different provider from your own. Your own server is always kind to you.
• Use a from address somebody could reply to.

Connecting a mailbox instead of typing a password

The same screen offers Microsoft 365 and Google directly. You sign in once, Pental holds a token rather than a password, and mail goes out through that mailbox exactly as Outlook or Gmail sends it: nothing to switch on at the server, no app password, and a copy lands in the mailbox's Sent Items. If the address is a shared mailbox, sign in with an account that has Send As rights on it rather than with the mailbox itself.

ONE THING A CONNECTED MAILBOX DOES NOT CARRY: the sender name and where replies go. Both belong to the mailbox, and Microsoft and Google apply their own whatever a sending application asks for, so the portal does not offer boxes that would do nothing. Set the display name in the Microsoft 365 admin centre under Users, or in Gmail under Accounts and Import, and set a reply or forwarding address on the mailbox itself. The password route below is different: there the headers are ours, so both fields are yours to set.

Sending from no-reply, and whether you should

Most firms start on a monitored address and move to a no-reply one when the volume of automated mail makes a monitored inbox a chore. Both are legitimate; the reason to move is volume, not etiquette. A no-reply address is filtered slightly harder by some gateways, and a few people reply to it regardless, so the move only pays once somebody is genuinely spending time on replies that need no reply.

• MICROSOFT 365: create noreply@yourfirm.com as a SHARED mailbox (Microsoft 365 admin centre, Teams and groups, Shared mailboxes). It needs no licence. Give the account you connected Send As rights on it, then put the address in the sending field here.
• GOOGLE WORKSPACE: create it as an alias or a group you own, then add it under Gmail settings, Accounts and Import, Send mail as, and verify it. The connected account can then send from it.
• Either way, set a reply-to that somebody reads. A no-reply sender with no reply-to is a dead end for anyone who does reply, which is the part people notice.

A no-reply mailbox nobody reads is worse than a monitored one: mail arrives and sits there unseen. Give it a mail-flow rule that REJECTS incoming mail with a line saying where to write instead, so the sender is told immediately rather than left waiting. In Exchange it is Mail flow, Rules, "Reject the message with the explanation"; in Google it is a routing rule on the address.

The wording: your portal

Inside the portal, Settings then Email Templates lets you rewrite every transactional message to match your tone, with variables for the parts that change. The signature block that goes out beneath them is on the SMTP & Signature tab in the same settings area.

Sign-in emails carry a CODE, never a link, on both sides of the platform. Security gateways such as Safe Links, Proofpoint and Mimecast fetch every URL in a message to detonate it, which spends a single-use link before the recipient ever sees it. A code has to be typed, so a scanner cannot spend it. Do not add a sign-in button to that template.

Check it end to end

• Invite yourself as a client user and read the whole journey exactly as they receive it.
• Confirm the links in that mail point at your portal hostname, not the default one.
• Set the notification preferences so your team hears about what matters and nothing else.