Keep Google or Microsoft MX, add AzAd mailboxes

Hybrid Google mail (and the same pattern for Microsoft 365) lets you keep Google Workspace or Microsoft 365 as the primary MX while AzAd Mail hosts selected mailboxes on the same domain — for example test@customer.com when that address does not have a Google license. You avoid a full MX cutover and still give some users affordable AzAd webmail, IMAP, and admin.

Split delivery works like this: Google or Microsoft receives mail for recognized suite users; unrecognized or inactive recipients are routed to AzAd's mail host (server.azademail.com, port 25). AzAd does not rely on per-mailbox Google Routing APIs — those Admin Console rules are not exposed via a supported public API — so configuration uses one Google route for unrecognized recipients plus optional Directory checks when Google is connected.

Who hybrid mail is for

• Orgs that must keep Google or Microsoft MX for most users
• Addresses that should not consume a suite license
• Gradual migrations before a full DNS cutover
• Teams comparing Google Workspace alternatives without ripping out existing MX on day one

How it differs from a full cutover

Customer admin setup (Google)

1. In AzAd Admin: Domains → Verify → open the domain → enable Hybrid mail (external primary MX).
2. In Google Admin (one-time): add a host for server.azademail.com (or smtp.azademail.com), port 25, TLS with CA cert and hostname validation. Do not use port 587 for this Google route — Google gets 554 Access denied when SASL is required.
3. Configure Routing (not “Non-Gmail mailbox” at the domain root): Inbound + Internal Sending + Internal Receiving; change route to the AzAd host; account types = inactive/unrecognized only. Non-Gmail mailbox at the root org can break Gmail for existing users — avoid that pattern for split delivery.
4. Confirm “Unrecognized route configured” in AzAd.
5. Optional: Connect Google (Workspace admin OAuth) so new AzAd mailboxes are checked against Directory and do not collide with existing Google users.
6. Ask AzAd platform ops to run the VPS hybrid sender sync so Google users can send to AzAd mailboxes without 550 Sender address rejected.

DNS guidance for hybrid keeps Google MX, merges SPF (include:_spf.google.com plus AzAd), and retains AzAd verification + DKIM. Microsoft 365 hybrid follows the same buying intent — keep suite MX, host selected mailboxes on AzAd — with provider-specific routing configured on the Microsoft side.

Pricing and trial

Hybrid does not change mailbox pricing. AzAd mailboxes still use storage tiers — 15 GB ≈ US$2.86/mo display USD (800 PKR ÷ 280). Start a 14-day card-required trial at /start/, then enable hybrid on the verified domain. See pricing and IMAP/SMTP setup for clients.

Microsoft 365 as primary MX

The buying intent is the same when Microsoft keeps MX: selected addresses live on AzAd while the suite remains primary for everyone else. Configure Microsoft-side routing/connectors according to your tenant’s mail flow rules so unrecognized recipients reach AzAd on port 25. AzAd Admin still needs hybrid enabled, SPF merged, and IMAP clients pointed at server.azademail.com for AzAd users.

Testing plan after enablement

1. Create an AzAd-only address that does not exist as a Google/Microsoft user.
2. Send to it from an external Gmail account — should land in AzAd webmail.
3. Send to it from a Google Workspace user on the same domain — should deliver after sender sync.
4. Send from the AzAd mailbox outbound — confirm SPF/DKIM alignment.
5. Confirm Google users still receive their own Gmail normally (routing must not steal active users).

Operational ownership

Hybrid adds a small ops surface: Google (or Microsoft) routing config, AzAd hybrid flag, and periodic awareness when adding users so Directory collisions are avoided. For most SMBs that is still cheaper than licensing every edge-case address on the suite. Platform ops runs the Mailcow sender sync; customers own Admin Console routing accuracy.

Common hybrid scenarios

• Unlicensed addresses: info@, contractors, or test inboxes that should not consume a Google or Microsoft seat.
• Department pilot: one team on AzAd while executives stay on Gmail or Outlook for a quarter.
• Acquisition overlap: two mail systems temporarily while identities merge — hybrid avoids a single risky MX weekend.
• Cost cap: fixed Google seat count; growth addresses land on AzAd storage tiers instead of new suite licenses.

Each scenario shares the same technical pattern: suite keeps MX; AzAd hosts selected mailboxes; routing sends unrecognized or inactive recipients to AzAd on port 25. Client IMAP for AzAd users always uses server.azademail.com.

Deliverability in hybrid mode

Inbound: Google or Microsoft receives mail for active suite users; unrecognized addresses route to AzAd. Outbound: AzAd mailboxes send through AzAd infrastructure with your domain’s SPF/DKIM. Merge SPF includes so both Google (or Microsoft) and AzAd are authorized while both send. Removing Google from SPF before Google stops sending causes alignment failures.

Internal deliverability often breaks before external: Google users mailing AzAd-only addresses may hit 550 Sender address rejected until hybrid sender sync runs on Mailcow. External Gmail-to-AzAd tests should pass after routing is correct. Run the testing plan in this page after every routing change.

When to exit hybrid

Hybrid can be permanent (ongoing split) or temporary (migration bridge). Exit to full AzAd MX when every address lives on AzAd and Google or Microsoft mail seats are gone — operation is simpler with one inbound path. Exit back to suite-only if the pilot fails: disable hybrid in AzAd Admin, remove Google routing to AzAd, keep suite MX authoritative, deprovision AzAd mailboxes you no longer need.

Do not stay in hybrid by accident. Quarterly review: count AzAd mailboxes, count suite seats, and decide whether the split still saves money versus operational complexity. See also our blog on hybrid MX Google AzAd for a buying checklist condensed for stakeholders.

Treat hybrid documentation like a runbook: who owns Google routing, who owns AzAd hybrid toggle, who requests sender sync, and which addresses are intentionally AzAd-only. When that runbook is missing, hybrid looks “broken” every time a new hire creates a mailbox.

Budget hybrid like any bridge: set a review date (for example 90 days) to decide full AzAd MX, permanent split, or rollback. Bridges without exit criteria become accidental architecture.

Record which addresses are intentionally AzAd-only in admin notes — future you will forget why one inbox bypasses Gmail.

Objections

"Why not route each mailbox via Google's API?" Google Admin routing rules and address lists are not available through a supported public API. One unrecognized-recipient route is the supported pattern AzAd documents.

"Will Google users fail when mailing AzAd addresses?" Without hybrid sender access on Mailcow, Google From-addresses can hit 550 Sender address rejected. Ops runs the sync script after hybrid is enabled.

"Is this free-tier heavy?" Hybrid uses D1 columns and encrypted org Google tokens only; the postmap lives on existing Netcup Mailcow. No new Cloudflare paid products are required for the feature itself.

Ready to try? Start the 14-day card-required trial at /start/, review pricing, and enable hybrid on the verified domain when DNS and Google routing are ready.