Hybrid accounts on the same domain

1. How Bridge works

With lua Bridge, the domain has a single entry point: the MX points to Lua. Every incoming message goes through the antispam and antivirus and then continues to the provider where each account's mailbox is.

1. Entry. The message arrives at Lua's MX (mx.secure.edgium-dns.net), which filters spam, phishing and viruses for all accounts on the domain.
2. Per-account routing. Each address has a defined provider: lua.email, Microsoft 365, Google Workspace or another provider (Zoho, your own server, a system that receives email). Anyone without their own rule stays on lua.email.
3. Delivery. The message goes to the right mailbox, at the right provider, with the filter result recorded in the headers.

The way back also needs to be set up. When someone on Microsoft 365 writes to a colleague on lua.email, Microsoft needs to know that this address is not with them and send the message to Lua. The same applies in the opposite direction and at any other provider. Each provider has its own configuration points: chapters 4 to 7 explain each side.

In every case the same idea applies: Lua's MX knows every address on the domain, at any provider. That is why an address that does not exist anywhere is rejected there, at the entry point, and the sender gets the notice. The diagrams for each provider are in chapters 5 to 7.

2. Before you start

What to gather

• The list of accounts on the domain, with each one's provider (lua.email, Microsoft 365, Google or other). Include groups, aliases and shared mailboxes.
• Access to the domain's DNS, to change MX, SPF, DKIM and DMARC.
• Administrator access to each provider in use: Microsoft 365 (Exchange admin center), Google Workspace (Admin console) or the other provider's panel.
• For each account that stays outside lua.email, its technical address at the provider, for example maria@yourcompany.onmicrosoft.com. See chapter 4.

Recommended order

1. Register the accounts and each one's provider in the Lua panel.
2. Make the adjustments at each provider in use (chapters 5 to 7).
3. Publish SPF and DKIM for all providers (chapter 3).
4. Change the MX to Lua.
5. Run the tests in chapter 9 and, once everything is right, tighten DMARC.

3. Domain DNS

MX

The MX points only to Lua. Do not leave the old Google or Microsoft MX alongside it: a sender that uses the old MX delivers straight to that provider, without the filter, and lua.email accounts do not receive through that path.

yourcompany.com.   3600   IN   MX   5   mx.secure.edgium-dns.net.

SPF

SPF says who can send email on behalf of the domain. With Bridge, three systems send as @yourcompany.com, and SPF must authorize every one in use:

yourcompany.com.  IN  TXT  "v=spf1 include:spf.edgium-dns.net include:spf.protection.outlook.com include:_spf.google.com -all"

• The domain can have only one SPF record. Put everything on a single line.
• Keep the other systems that already send through the domain (ERP, invoicing, marketing).
• SPF accepts at most 10 DNS lookups counting all the includes together. Beyond that, the whole SPF fails. Check with an SPF checking tool after publishing.
• Start with ~all if you are not yet sure that all senders are in the record, and switch to -all after checking.

DKIM

Each provider signs messages with its own key, and each key has a DNS record. Publish the records for all providers in use:

• lua.email: the domain's DKIM record appears in the Lua panel. Copy the name and value exactly as they are there.
• Microsoft 365: two CNAMEs (selector1._domainkey and selector2._domainkey), shown in Microsoft Defender under Email authentication settings → DKIM. After publishing, turn on signing for the domain on the same screen.
• Google Workspace: a TXT record (google._domainkey), generated in the Admin console under Apps → Google Workspace → (email item) → Authenticate email. After you publish it, click Start authentication.
• Other provider: the record it gives you, usually with its own selector.

DMARC

DMARC tells the recipient what to do with a message that uses your domain and fails both SPF and DKIM. Raise the policy gradually:

1. Start: p=none, to monitor without affecting delivery.
2. After the tests (SPF and DKIM for the three providers checked): p=quarantine.
3. Once everything is stable: p=reject.

_dmarc.yourcompany.com.  IN  TXT  "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r"

To receive aggregate reports, add rua=mailto:dmarc@yourcompany.com (create the mailbox first). Without rua, no report is sent.

4. Per-account routing

In the Lua panel, each account on the domain has a provider. That is what decides where a message arriving from the internet goes.

Each account's provider

• lua.email: the mailbox stays at Lua. This is the default for anyone without their own rule.
• Microsoft 365: the message is delivered to the domain's Microsoft 365.
• Google Workspace: the message is delivered to the domain's Google.
• Other provider: the message is delivered to the server given for that account.

Switching an account to another provider only changes where new messages go. Messages already in the old mailbox are not moved: for that, use the migration tool in the admin panel (with migration GB you buy) or hire the Lua team for the migration (billed by the hour).

Technical address for accounts outside lua.email

The per-account rule applies to what arrives through the MX. When the sender is an account on lua.email itself, the message does not go out to the internet and does not pass through the MX, so Lua needs to know where to send it. That is why each account that stays outside lua.email uses two destination addresses, and you register both:

At each provider, the inbound host and the technical address are these:

What is automatic and what is manual

License and default destination

Each account routed outside lua.email uses a Bridge license (Bridge account, per routed account), subscribed directly at the checkout, at R$ 2.50 per account per month; for large volumes, the sales team puts together a proposal. The license applies to regular domains and only with spam filtering, and the panel shows how many are in use and how many are left (where to see usage). A mailbox that stays on lua.email uses the usual email license. Anything without its own rule follows the domain's default destination, which is lua.email: a new address, without routing, goes to the lua.email mailbox with that name (or is rejected, if the mailbox does not exist). Your Google and Microsoft licenses remain yours.

Groups, aliases and shared mailboxes

• A lua.email alias can point to accounts at any provider. For external accounts, use the technical address.
• A Microsoft 365 or Google group needs to be registered in the panel as an account at that provider, as if it were a mailbox.
• Do not register the same address as a mailbox at two providers. Choose one, otherwise each side delivers to its own copy and the person receives half the messages in each place.

5. Microsoft 365 settings

The domain's MX is Lua's. Microsoft 365 receives messages for the accounts that are on it, and whatever it does not recognize goes on to Lua's MX instead of being rejected. The real list of who exists is the one in the Lua panel.

Screen names are shown in English, because the Exchange admin center changes language depending on the user. Microsoft's step by step (learn.microsoft.com): accepted domains, connectors and directory-based edge blocking.

Who receives first and what happens with an account that does not exist

• Who receives first: Lua's MX. Microsoft 365 only receives what Lua delivers to it, through the inbound host in per-account routing.
• Source of truth: the Lua panel. Each account has its provider there.
• Account that does not exist on Microsoft 365: with the domain as Authoritative (the default), Directory-Based Edge Blocking (DBEB) rejects it right away with 550 5.4.1 Recipient address rejected: Access denied, and the lua.email colleague is never reached. With the domain as Internal relay, Microsoft 365 does not reject: it passes the message along through the connector to Lua's MX.
• Account that does not exist anywhere: Lua's MX rejects it and notifies the sender.

1. Domain as internal relay

This is the most important adjustment on Microsoft's side. By default, Microsoft 365 assumes all accounts on the domain are on it and bounces any address it does not know with 550 5.4.1 (or 550 5.1.10 RecipientNotFound). With the domain as internal relay, it delivers what is its own and passes along what is not. The connector in step 2 says where to.

1. In the Exchange admin center, open Mail flow → Accepted domains.
2. Open the domain. Under This accepted domain is, change Authoritative to Internal relay and save.

2. Outbound connector to Lua's MX

It tells Microsoft 365 where to send messages for accounts that do not exist on it: Lua's MX.

1. Under Mail flow → Connectors, click Add a connector. Under Connection from choose Office 365, and under Connection to choose Partner organization.
2. Under Use of connector, choose Only when email messages are sent to these domains and enter yourcompany.com.
3. Under Routing, enter the smart host mx.secure.edgium-dns.net and click +.
4. Under Security restrictions, require TLS and validate the connector with an address that is on lua.email.

3. Email contact for people on lua.email (optional)

Without this, everything works: the internal relay and the connector already carry the message to lua.email. The contact is there so the lua.email colleague appears in the global address list of Microsoft 365 and in Outlook.

1. In the Exchange admin center, open Recipients → Contacts and click Add a mail contact.
2. Enter a name, an alias and, under Email, the address joao@yourcompany.com. Create one contact per account that is on lua.email and keep the list in step with the panel.

Mail contacts, at Microsoft (learn.microsoft.com).

4. Inbound connector and enhanced filtering

Because internet messages reach Microsoft 365 through Lua's servers, Microsoft sees Lua's IP and not the original sender's. Enhanced Filtering makes Microsoft look past the last hop.

1. Create a From Partner organization to Office 365 connector, identified by the sender's IP address, with the IPs from the list resources.edgium.net/ips_mx.txt.
2. In Microsoft Defender, open Policies & rules → Threat policies → Enhanced filtering for connectors, choose that connector and check automatically detect and skip the last IP.

5. Lua's ARC seal as trusted

Lua records, in a signed header (ARC, domain lua.email), the SPF, DKIM and DMARC result it saw on arrival. With the seal marked as trusted, Microsoft accepts that result when the original SPF is lost along the way.

1. In Microsoft Defender, open Email authentication settings → ARC.
2. Add lua.email as a trusted ARC sealer.

6. Domain DKIM

Turn on DKIM for the domain in Microsoft 365, as in chapter 3. Without it, Microsoft accounts only pass DMARC through SPF, and SPF does not survive forwarding.

How to validate

• From a Microsoft 365 account, write to a lua.email colleague: it should arrive, with no 550 5.4.1 or 550 5.1.10 bounce.
• From lua.email to Microsoft 365: it should arrive. If 550 5.1.1 comes back, the alias to the onmicrosoft.com address is missing (chapter 4).
• From outside, write to a made-up address on the domain: the bounce comes from Lua (5.1.1 or 5.2.1), not from Microsoft.

Common errors

• Domain still Authoritative: 550 5.4.1 bounce for the lua.email colleague.
• Account registered in the panel as Microsoft 365 but with no user there: the message bounces back and forth until hop count exceeded (chapter 10).
• Outbound connector without the company domain, or turned off: the message stays stuck in Microsoft 365.

6. Google Workspace settings

Google treats what it does not recognize as "unrecognized accounts". The route below sends those messages to Lua's MX, which is the equivalent of Microsoft's internal relay.

Google's step by step (knowledge.workspace.google.com): split delivery, email routes (hosts) and domain alias.

Who receives first and what happens with an account that does not exist

• Who receives first: Lua's MX. Google only receives what Lua delivers to it through the inbound host in per-account routing (aspmx.l.google.com *).
• Google's rule: each person exists on Google or on lua.email, never both.
• Account that does not exist on Google: without the route, Google rejects it. With the route, it sends the message to Lua's MX. If the address does not exist anywhere, Lua rejects it and notifies the sender.

1. Route (host) to Lua's MX

1. In the Admin console, open Menu → Apps → Google Workspace → (email item) → Hosts and click Add Route.
2. Give it a name (for example, "Lua MX"), choose Single host, enter mx.secure.edgium-dns.net, port 25, and leave the TLS options checked.
3. Salve.

2. Routing rule for unrecognized accounts

1. Open (email item) → Routing and click Configure or Add another rule.
2. Name the rule and, under Apply when, check Inbound and Internal inbound. The second one covers people writing from inside Google.
3. Under Action, choose Modify message, click Change route, and choose the route from step 1.
4. Under Account types, check All inactive and unrecognized accounts and uncheck active user account and group.
5. Save. The change can take up to 24 hours, though it is usually much faster.

3. Domain alias for the technical address

Under Account → Domains → Manage domains, add tecnico.yourcompany.com as a domain alias or secondary domain. Each Google user then gets maria@tecnico.yourcompany.com, and that is the alias address in the Lua admin panel (chapter 4). Google does not require the subdomain to receive email through its MX: Lua delivers straight to the inbound host.

4. Inbound gateway

This tells Google that messages arrive through a filter and that it can use Lua's markings.

1. Under (email item) → Spam, Phishing and Malware → Inbound gateway, enter the IPs from the list at resources.edgium.net/ips_mx.txt.
2. Check Message is considered spam if the following header regexp matches and enter X-Edgium-Spam: Yes.

5. Domain DKIM

Generate and publish the google._domainkey key and start authentication, as in chapter 3.

How to validate

• From Google to a lua.email colleague: it should arrive. If it bounces, check the unrecognized accounts rule and whether it applies to internal messages.
• From lua.email to Google: it should arrive. If you get 550 5.1.1, the alias for the technical address is missing.

7. cPanel and other providers

Bridge does not depend on Google or Microsoft. Any provider that receives email over SMTP can host part of the accounts. On cPanel hosting, you choose between two ways to make the domain work with lua.email, and both depend on a setting you control.

cPanel

In cPanel, the Email Routing item decides what the server does with the domain. With Automatically Detect Configuration, it chooses based on the MX: if the MX points elsewhere, like Lua's, the choice is Remote Mail Exchanger. Check what is selected. cPanel documentation (docs.cpanel.net): Email Routing and Forwarders.

In both options, for the accounts that stay in cPanel

1. In cPanel, create the technical subdomain cpanel.yourcompany.com as an alias domain (Domains → Aliases), so that maria@cpanel.yourcompany.com lands in the maria@yourcompany.com mailbox, and point its MX to the cPanel server.
2. In the Lua admin panel, under Delivery → Per-account routing, route maria@yourcompany.com to the cPanel mail server.
3. Under Aliases, create the alias from maria@yourcompany.com to maria@cpanel.yourcompany.com, which is what makes sending from a lua.email account to her work.

Option A: one forwarder for each lua.email account *

1. In lua.email, register lua.yourcompany.com as an alias domain of the domain (Email → Alias domains tab) and point its MX to mx.secure.edgium-dns.net. That way, joao@lua.yourcompany.com lands in joao@yourcompany.com's mailbox.
2. Under Email Routing, set the domain to Local Mail Exchanger and click Change.
3. In cPanel, under Forwarders, click Add Forwarder. In Address to Forward enter joao, choose the domain, select Forward to Email Address, and enter joao@lua.yourcompany.com.
4. Repeat for each account that is on lua.email. If the address already has a mailbox in cPanel, the server keeps a copy before forwarding: delete the old mailbox when it is no longer used.

This is a manual control: when you create an account on lua.email, create the forwarder in cPanel. If you forget, anyone writing from cPanel to that account gets "no such user" or similar, while senders from outside are not affected, because they come in through Lua's MX.

Option B: send everything to the external MX *

1. Under Email Routing, set the domain to Remote Mail Exchanger and click Change. cPanel stops accepting the domain locally and sends everything to the MX, which is Lua's.
2. Make sure every account that stays in cPanel is registered in the Lua admin panel as routed, with the alias from the previous step. Without it, the message for that account is rejected at Lua's door.

How to validate and common errors

• From a cPanel account, write to a lua.email account: it should arrive. If you get "no such user" or "unrouteable address" on option A, the forwarder is missing.
• From lua.email to a cPanel account: it should arrive. If you get 550 5.1.1, the technical address alias is missing.
• Message that bounces back and forth (hop count exceeded): the domain is set to Remote and the account was routed to cPanel through the main domain. Use the technical subdomain.
• cPanel went back to Remote by itself: the Automatically Detect option was selected. Keep it fixed on Local (option A).

Other providers

Zoho, your own server, a help desk system that receives by email: each has its own settings, but the adjustments are always the same four:

1. Delivery: the provider's server accepts messages from Lua's IPs (official list) for its accounts, without blocking on connection limits or on the original sender's SPF.
2. Accounts it does not know: the provider sends messages for domain addresses that are not on it to mx.secure.edgium-dns.net, instead of bouncing them. Each provider calls this something different: shared domain, internal relay, partial routing, split delivery, or catch-all to an external host.
3. Technical address: each account has an address that Lua uses to deliver messages sent by lua.email accounts (chapter 4).
4. Authentication: the SPF include and the provider's DKIM published in the domain's DNS (chapter 3).

8. Training the filter

You teach the filter yourself, from the admin panel, without opening a ticket. Training applies to the domain's accounts, including those on Microsoft 365, Google, or another provider, as long as the address belongs to the domain. Our team stays by your side when you need it.

How to submit a message

1. In the panel, open the domain and go to Delivery → Train the filter.
2. Under This message is, choose SPAM (scam, unwanted advertising) or TRUSTED (a legitimate message that was flagged).
3. Under How to submit, choose .eml file and select the file, or Paste the message and paste the full message, with headers and body.
4. If the message has no recipient from the domain, enter in Address that received the message which mailbox received it.
5. Click Send to the filter and confirm in the window that opens.

The result

The screen tells you what happened:

• Done: the filter learned this message as SPAM (or as TRUSTED): trained.
• All good: the filter had already learned or already classifies messages like this: this is also a success. The message was already taught, so there is no need to send it again.
• Could not train right now. Try again later: the filter is unavailable at the moment. Try again shortly; if it continues, contact support.
• The other notices say what to fix: an empty message or one that does not look like an email, a recipient outside the domain, hourly limit reached, or a repeated submission.

What was trained

The What was trained button, next to Send to the filter, lists each submission: date, who sent it, domain, type, sender and subject of the message, size, and result. You can filter by date, user, type, result, and domain. The message content does not appear: only the sender and the subject are kept, truncated.

How to get the .eml

• Google account (Workspace or personal): open the message, then ⋮ → Show original → Download original message.
• Outlook on the web and new Outlook: open the message and use the ⋯ menu to download or save it as an .eml file.
• Outlook for Windows (classic): dragging the message to a folder creates an .msg file, which the panel does not accept. Open the message in Outlook on the web and download the .eml from there.
• Thunderbird: File → Save As → File saves the .eml.
• Apple Mail: File → Save As, in the Raw Message Source format.
• lua.email webmail: in the message's More menu, download the .eml file or open the source and copy everything.

Prefer the .eml: it carries the whole message, with the headers the filter uses. If you paste, copy everything, from the first header (From:, Received:) to the end of the body.

Good to know

• The filter learns per destination address, not for the whole domain. The message teaches the filter of the mailbox that received it: the address that appears in the headers (To, Cc, Delivered-To) or the one you enter in the field. To teach more than one mailbox, send the message once for each address.
• Only addresses of the domain itself (and its alias domains) are accepted. This also applies to an account that is on another provider, as long as the address belongs to the domain.
• One message at a time, up to 10 MB. A file with several messages (mbox) is rejected.
• There is a limit on submissions per hour, per person and per domain. The same message sent again right after is rejected, because it does not need to be repeated.
• The Read-only and Helpdesk profiles cannot train: they see the screen and the history, without the form.
• The screen exists for domains with an active Shield or Bridge license.
• The message goes through the filter and is not stored in the panel. Only the record that the submission was made remains.

If your account does not have the screen (read-only or helpdesk profile, or a domain without Shield or Bridge), ask whoever administers the domain, or send the original message as an .eml through support.

Training teaches the filter to decide on the next similar messages. For a sender that must always get through, add it to the allowed list, under Delivery → Access lists.

Mailboxes that are on lua.email keep training through webmail: moving a message to the Spam folder, or taking it out of there, already counts as a correction.

9. Activation tests

Send a message in each direction and check the full header of each one ("show original" or "view source").

With all tests passing, raise DMARC to p=quarantine (chapter 3).

10. Common problems

"550 5.1.1 User unknown" bounce when writing from lua.email

The destination account is outside lua.email but has no technical address registered. Register the onmicrosoft.com address, the Google one, or the other provider's (chapter 4).

"550 5.4.1" or "550 5.1.10 RecipientNotFound" bounce when writing from Microsoft 365

In the domain configuration on Microsoft 365, accounts that do not exist there are not yet going to the external MX: the domain is still Authoritative, or the outbound connector does not cover the domain. See chapter 5.

Message bounces with "hop count exceeded" or "loop detected"

The account was registered in the admin panel with a provider (Microsoft, Google, or another), but it does not exist there. The provider does not find it and returns it to Lua, which sends it to the provider again. Create the account at the provider or change its provider in the panel.

Messages from lua.email accounts land in spam or fail SPF

include:spf.edgium-dns.net is missing from the SPF, or the SPF went over 10 lookups. See chapter 3.

DMARC fails on forwarded messages

The sending provider is not signing with the domain's DKIM. Turn on DKIM at every provider before using p=quarantine or p=reject.

The person receives only part of the messages at each provider

The address exists as a mailbox at two providers. Keep the mailbox at only one and, if you need a copy, use an alias (chapter 4).