Five Ways Out, and One of Them Is Yours
A message this product sends on your behalf can leave through your own mail provider rather than ours, chosen per category rather than all at once. Five transports, one message body, and a fall-through at every step that decides what happens when yours is unavailable.
The address an automated email comes from is the whole of its credibility, and it is decided by whose account it leaves through.
Every message the product sends on your behalf — an invoice, a reminder, a notification, a supplier request — is built once, in one shape. What differs is which door it goes out of, and an organisation can put its own door in the path.
Five transports, chosen in order
When a message carries both an organisation and a category, five options are tried before the platform's own mail. Each one is asked whether it is configured and whether it wants this particular category, and each falls through silently if not.
| Order | Transport | What it means for the recipient |
|---|---|---|
| 1 | Your Google Workspace connector | The message comes from your own mailbox, and sits in its sent items. |
| 2 | Your Microsoft 365 connector | The same, on the other platform. |
| 3 | Your Mailjet account | Sent from your own sending domain and counted against your own reputation. |
| 4 | Your Mailgun account | The same, on your own domain. |
| 5 | Your Brevo account | The same again. |
| — | The platform mailer | The fallback, used when none of the five is configured for this category or none succeeds. |
Per category, not per organisation
The choice is made per message type rather than once for everything. A workspace can send invoices and statements from its own domain — where the sender address matters commercially — while leaving internal notifications on the platform mail, where nobody cares and nobody wants their own sending reputation spent on them. That granularity is the difference between a useful feature and a switch nobody dares flip.
One body, five transports
The message is composed once in a single structure, and each transport converts that structure into whatever its provider expects — a direct post for one, a multipart request per message for another, a different transactional format for a third. The composition, the templates, the reply-to handling and the recipient lists are identical whichever door is used.
That is the property that keeps this maintainable. The alternative — a separate composition path per provider — produces five subtly different emails, and the differences surface as a missing attachment or a broken link on the one provider nobody tests.
The message is written once. Only the envelope changes.
What happens when your provider fails
Each attempt returns either a delivered response or nothing, and nothing means fall through to the next option. A category that is switched off, a connector that is not configured, and a send that failed all produce the same outcome: the next transport is tried, and eventually the platform mailer.
That is a deliberate choice in favour of delivery over purity. The alternative would be to fail the message when the configured transport fails, which is defensible for a marketing send and wrong for an invoice. It has one consequence to be aware of: a message you expected to come from your own domain may arrive from the platform's, and the fall-through itself is quiet.
Two things that stop a message before any of this
-
A testing environment sends nothing
Messages composed while the application is running its own tests are logged with a summary and suppressed. That is what makes it safe to run a full test suite against realistic data without a single message reaching a real address.
-
A blocked recipient domain is refused
A configured list of domains that must never be written to, checked before any transport is chosen, with the refusal logged as a warning naming the recipients. The list can be empty, in which case nothing is blocked — but where it exists it is absolute and it is checked first.
The second is the more useful of the two in practice. It is how a staging environment restored from a production database is prevented from emailing every real customer in it — a failure that is memorable, expensive and entirely preventable by a list of domains checked before anything is sent.
What sending under your own name buys you
- Recognition. An invoice arriving from your own domain is opened. One arriving from a platform your customer has never heard of is treated as a phishing attempt, and occasionally reported as one.
- Reputation you control. Deliverability is a property of the sending domain. Sending under your own means your history is yours — which is a liability as well as an asset, and worth knowing before you switch it on.
- A record on your side. Where the connector is a mailbox rather than a sending service, the message lands in your own sent items, which is where anybody looking for it will look first.
- Replies that go somewhere useful. A message from your own domain can be replied to, and the reply reaches your own inbox rather than an address nobody monitors.
What AWRA OpsHub does today
- Outbound mail routed through your own Google Workspace or Microsoft 365 mailbox, or your own Mailjet, Mailgun or Brevo account, chosen per message category.
- One message composed in a single structure and converted by each transport into whatever its provider expects, so templates, attachments and recipients are identical whichever door is used.
- A per-category opt-in on each connector, so invoices can leave your domain while internal notifications stay on the platform's.
- A fall-through at every step — a category switched off, a connector missing or a send that failed all pass to the next option and eventually to the platform mailer.
- A default reply-to applied to the message before any transport is chosen.
- Complete suppression of outbound mail while the application is running its own tests, logged with a summary.
- A configurable list of blocked recipient domains, checked before any transport is selected, with refusals logged as warnings naming the recipients.
- A clean refusal from each connector when its configuration is incomplete, rather than a failure part-way through a send.
More we can add to your workspace
- A notification when a message falls through to the platform mailer, so a connector that stopped working is visible rather than quiet.
- A per-message record of which transport carried it, visible on the document the message was about.
- A configuration test per connector, confirming a sending account authenticates before it is relied on.
- Bounce and complaint handling returned from each provider into one suppression list.
- A sending volume view per transport, so an organisation can see what is leaving under its own name and what is not.
- A per-recipient send history, answering precisely which messages reached a given address and when.
Where we point you to a specialist
- We will keep falling through to the platform mailer rather than failing a message. An invoice or a password reset that was not sent because a connector was misconfigured is a worse outcome than one that arrived from an address the recipient did not expect, and delivery is the obligation that comes first.
- Authenticating your sending domain with your provider — the records that prove you are entitled to send as yourself — is between you and them. We will send through the account you configure; whether the wider mail system trusts it is a matter of your own domain records.
- We will not send from your domain without your connector. Sending as somebody else is what the entire domain authentication system exists to prevent, and a product that offered it would be offering to make your mail less trustworthy rather than more.
A notification when a message falls through to the platform mailer is the smallest piece here and closes the one quiet failure in the ladder — a connector that stopped working while everything continued to arrive.
Knowing which door a message used
The routing works and the fall-through keeps mail moving. What is missing is visibility — which transport carried a given message, and whether a connector has quietly stopped being used.
The transport recorded per message
Which door a message went out of, visible on the record it was about, so a delivery question can be answered precisely.
An alert on fall-through
A notification when messages start arriving from the platform mailer because your own connector is failing.
A connector test
A check confirming a configured sending account authenticates, run on demand and on a schedule.
We publish scope, not dates.
Scope email deliveryOur take
The design decision worth praising here is granularity. Most products offer sending under your own domain as one switch, which forces an organisation to choose between putting its reputation behind every internal notification and putting none of it behind its invoices. Choosing per category resolves that properly, and the single message body means the five transports cannot drift into five subtly different emails. The one thing to watch is the quiet half of the fall-through: a connector that stops working produces mail that still arrives, from a different address, with nothing announcing the change. That is the correct behaviour for the message and the wrong behaviour for the operator, and the fix is a notification rather than a different policy.
Five questions to ask about outbound mail
Can mail go out under our own domain?
A good answer sounds like
Yes, and how.
What ours actually is
Through your Google Workspace or Microsoft 365 mailbox, or your own Mailjet, Mailgun or Brevo account.
Is it all or nothing?
A good answer sounds like
Per category, ideally.
What ours actually is
Per category. Invoices can leave your domain while internal notifications stay on the platform's.
What happens if our provider fails?
A good answer sounds like
The message still goes.
What ours actually is
It falls through to the next configured transport and eventually to the platform mailer. Delivery is preferred over purity.
What stops a test system emailing real customers?
A good answer sounds like
More than good intentions.
What ours actually is
Complete suppression while the application is running its own tests, plus a configurable blocked-domain list checked before any transport is chosen.
Can we tell which transport carried a message?
A good answer sounds like
Ideally yes.
What ours actually is
Not per message today. Recording the transport on the record it was about is the first item on the list of what would be added.
Start with the documents your customers read
Invoices, statements and quotations are where the sender address earns its keep. Internal notifications are where it does not. Choosing per category means you do not have to trade one for the other.
Talk through email deliveryFrequently asked questions
Can we send everything from our own domain?
You can configure a connector for as many message categories as you like, up to all of them. Most organisations deliberately stop short — the documents customers read go out under their own name, and internal notifications stay on the platform mail, because there is no benefit to spending your own sending reputation on a message to your own staff.
What happens if our mail provider is down?
The message falls through to the next configured transport, and eventually to the platform mailer. That is a deliberate preference for delivery over consistency: an invoice that arrives from an unexpected address is a worse outcome than an invoice that does not arrive. The cost is that the fall-through is quiet, which is why a notification when it happens is the first thing on the list of what would be added.
Will the message look different?
No. The message is composed once in a single structure and each transport converts it for its own provider — templates, attachments, recipients and reply-to are identical whichever door is used. The alternative, a separate composition per provider, is how a missing attachment ends up affecting only the provider nobody tests.
How do we stop a copy of production emailing our customers?
A configured list of blocked recipient domains, checked before any transport is chosen, with the refusal logged as a warning. It is absolute where it exists and blocks nothing where the list is empty. This is the control worth setting up before you ever restore a production database anywhere else, rather than after.
Does using our own mailbox mean the message appears in our sent items?
Where the connector is a mailbox — a Google Workspace or Microsoft 365 account — yes. That is often the deciding factor for a small organisation, because the first place anybody looks for a message they sent is their own sent folder, and a message that is not there is a message they cannot confirm.
Do we need to configure anything with our provider?
Yes — the domain records that prove you are entitled to send as yourself. That is between you and your provider and it is what the wider mail system checks. We will send through whichever account you configure; whether the receiving side trusts it depends on that authentication rather than on us.
