E-mail Accounts

Adding an Account

An account is the mailbox mail is sent through, with the credentials to reach it.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Activity:

• E-mail Log — every message sent, with its result

Architect Panel → Layout & Pages:

• E-mail Templates — templates that send through it

What an account holds

• A from address and a from name.
• The connection details for its type.

The from name is what people see

In most mail clients the name is prominent and the address is not shown at all until somebody looks. So the name is doing the work of telling a recipient who this is from.

Use the organisation's name as people know it, not an internal one. "Notifications" from an unfamiliar system is deleted; the same message from a recognised organisation is opened.

Use an address you collect from

People reply. An address nobody monitors discards those replies silently, and the sender concludes they were ignored.

Several accounts, deliberately

Different purposes often want different addresses — transactional mail from one, campaigns from another, alerts from a third. That is worth doing for two reasons: recipients get a sensible from address, and a deliverability problem with one does not affect the others.

Keep the number small enough that each has an owner.

Organisational credentials, always

Never a person's mailbox or password. It breaks when they leave or change their password, and it attributes the platform's mail to them.

The domain configuration matters more than anything here

Receiving servers check whether your domain authorises this sender. Without that, your mail is treated as suspicious regardless of how correctly the account is configured.

That is the single biggest factor in whether your mail arrives, and it is configured at your domain rather than in the platform. Confirm it before concluding you have a sending problem — it is the cause more often than anything on this screen.

Test to several providers

Send to accounts at the mail providers your recipients actually use, and check whether the message landed in the inbox rather than merely being accepted. Corporate filters and consumer spam folders behave differently, and a send that "worked" to your own mailbox proves little.

Watch for credential expiry

Modern providers expire credentials and tokens. An expired one stops all mail through that account at once — usually noticed when somebody asks why a customer never got something. Diary any expiry you know about.

Worked example

An organisation runs two accounts: one for transactional mail from a monitored support address, one for campaigns. Both use organisational credentials, both from names use the trading name customers recognise. Domain authorisation was confirmed before launch, and test sends to four providers all reached the inbox.

Recommendations

• Use a from name people recognise.
• Send from an address you collect from.
• Confirm domain authorisation before blaming the account.
• Test to real providers, and check the inbox not just the send.

SMTP Accounts

SMTP is the standard way to send mail, supported by essentially every provider.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Activity:

• E-mail Log — every message sent, with its result

What it needs

• A server and port.
• Encryption.
• Credentials.

Your provider publishes all four. Use what they document rather than what worked somewhere else.

Always encrypt

Unencrypted SMTP sends your credentials and your message content in clear text across the network. There is no situation where that is the right choice today, and providers increasingly refuse it anyway.

Use an application password where offered

Many providers issue a credential specific to one application rather than using the account password. Where that is available, use it: it can be revoked without changing anything else, and it usually works where the main password is blocked.

When SMTP is the right choice

• The provider offers nothing better.
• You are sending through a dedicated mail service.
• You want one method across several providers.

When a provider connection is better

For Microsoft 365 in particular, the Graph connection is generally the better option: it avoids credentials being refused as organisations disable basic authentication, and it is what the provider is steering people towards.

If your organisation is on Microsoft 365 and SMTP has started failing, that is usually the reason rather than anything you changed.

Sending limits

Providers cap how much you may send — per hour, per day, per recipient count. A general mailbox is not built for bulk, and exceeding a limit gets your account restricted rather than politely throttled.

If you send campaigns, use a service intended for it rather than a mailbox.

Failures are informative

SMTP errors are more specific than most. An authentication failure, a relay refusal and a rate limit read differently in the log — worth reading rather than treating every failure as "mail is broken".

Test a send and a failure

Send successfully, then send to a deliberately invalid address to see what the failure looks like in the log. The second is what your support team will actually encounter.

Worked example

An organisation configures SMTP against its provider's documented settings with encryption and an application password. Transactional mail goes through it; campaigns go through a separate sending service, after a bulk send through the mailbox triggered a rate limit and suspended the account for an afternoon.

Recommendations

• Always encrypt, and use the provider’s documented settings.
• Use an application password where offered.
• Prefer Graph on Microsoft 365.
• Do not send campaigns through a mailbox.

IMAP and POP3

Collecting mail uses one of two protocols, and the difference is more consequential than it appears.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Integration & Connections:

• E-mail Inboxes — the inbox doing the collecting

The essential difference

• IMAP leaves mail on the server and syncs state. Several things can look at the same mailbox and agree about what has been read.
• POP3 downloads mail, typically removing it from the server.

Prefer IMAP

Because POP3's behaviour is destructive by default. If the platform collects by POP3 and removes messages, anybody else looking at that mailbox — a person, a backup, another system — finds them gone.

That is discovered at the worst moment: somebody goes looking for an e-mail they know arrived and it is not there.

Where POP3 still fits

A mailbox that exists solely for the platform, where removing collected mail is exactly what you want and nobody else will ever look. That is a legitimate arrangement and it should be a deliberate one.

Encrypt

The same as sending. Unencrypted collection sends credentials and message content in clear text.

Know what happens after collection

The setting that causes most surprises. Are messages left, marked read, moved, or deleted?

Whichever you choose, make sure it is a decision. "We did not realise it was deleting them" is a conversation that happens after something has been lost, and there is rarely a way back.

Do not collect from somebody’s mailbox

A person's inbox and an automated collector will interfere with each other, and the person will lose mail. Use a dedicated mailbox.

Watch the mailbox size

With IMAP leaving everything in place, a busy mailbox grows indefinitely and will eventually hit a quota — at which point new mail bounces and you stop receiving enquiries.

Have a plan: archive, move processed mail to a folder, or apply a retention policy at the provider.

Microsoft 365 again

As with sending, Graph is generally the better route where available, and organisations disabling basic authentication will break IMAP collection without warning you.

Worked example

A support mailbox is collected by IMAP with processed messages moved to a folder rather than deleted, so the mailbox stays a manageable size and nothing is destroyed. A retention policy at the provider clears the folder after a year, and the records created from those messages are the permanent copy.

Recommendations

• Prefer IMAP — POP3 is destructive by default.
• Decide what happens after collection, deliberately.
• Use a dedicated mailbox, never a person’s.
• Plan for mailbox growth before it hits a quota.

Microsoft Graph Accounts

For Microsoft 365, Graph is the modern connection for both sending and collecting.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Integration & Connections:

• Azure AD Tenants — the Microsoft application registration

Why it is the right choice there

Microsoft has been steadily disabling basic authentication, which is what SMTP, IMAP and POP3 rely on. Organisations that have not moved find mail integrations failing on a date set by Microsoft rather than by them.

Graph does not depend on it, so it does not break when that happens.

What it needs

An application registered in the organisation's Microsoft tenant, with permission to send and read mail for the mailbox in question, and the resulting identifiers and secret.

That is more setup than a username and password, and it is why it does not break.

Administrator consent is usually required

The step that catches people out. Mail permissions typically require a Microsoft administrator to consent on behalf of the organisation — a person who may not be you, and may need convincing.

Plan for that conversation rather than discovering it mid-configuration. Being able to say precisely which permissions you need, and for which mailbox, makes it much shorter.

Ask for the minimum, on the narrowest scope

Permission to read and send mail across an entire organisation is a lot to hold. Where Microsoft allows scoping the application to specific mailboxes, do that — it is a smaller ask, easier to get consented, and a much smaller thing to have if the credential leaks.

The secret expires

As with any Microsoft application registration, and when it does, mail stops entirely — sending and collecting both, at once.

Diary the renewal when you create it, choose the longest permitted lifetime, and record who in the Microsoft tenant can renew it. That last one matters: on the day it expires you need somebody with rights there, and it may not be anybody in your team.

It covers both directions

One connection serves sending and collecting, which is simpler than maintaining SMTP and IMAP separately with two sets of credentials that expire on different dates.

Test both directions

Send a message and collect one. It is entirely possible to configure permissions that allow one and not the other, and finding out later means going back to whoever consented.

Worked example

An organisation registers an application scoped to one shared mailbox, obtains administrator consent with a written list of the permissions and why, and uses it for both sending and collection. The secret is diarised at twenty-two of its twenty-four months, with the Microsoft administrator named alongside it.

Recommendations

• Use Graph on Microsoft 365 — basic authentication is going away.
• Scope to specific mailboxes where you can.
• Prepare for the consent conversation.
• Diary the secret, and record who can renew it.