OpenEFA™ Integrations

Wherever your mailboxes live, the configuration is ready.

Microsoft 365, Google Workspace, Zimbra, Exchange Server or another hosted provider: OpenEFA sits in front of whichever platform hosts your mailboxes. Your MX record points at us, we filter, and we deliver clean mail to that platform. We have the setup written up for each one. Nothing is installed on your mail platform or your users' computers, your users keep their mailboxes and mail clients, and switching back is a DNS change.

Microsoft 365 Google Workspace Zimbra Exchange Server Postfix / Exim / other servers Zoho, Rackspace, Fastmail
Your Platform Cutover & Rollback
Mail flow after cutover
Internet→ OpenEFA→ Microsoft 365, Google Workspace or your server→ Mailboxes
  • Clean mail is delivered to your mail platform within seconds.
  • Suspicious mail is held in quarantine; users release or report it in the MailGuard portal or from a daily digest.
  • Every delivery to your platform is over TLS.

The same four steps, whichever platform hosts your mail

The settings differ between Microsoft 365, Google Workspace and a server of your own; the shape of the project does not. Most organizations are done in two to three weeks, most of it the shadow run.

Step 1
Tell us your platform

Microsoft 365, Google Workspace, Zimbra, Exchange Server or another provider: we have the configuration ready for each. Send us your list of mailboxes, groups and aliases and we load it; anything not on it is refused at the door, so dictionary attacks never reach your platform.

Step 2
Allow our gateway

Your server or tenant accepts mail from the OpenEFA gateway addresses we give you at onboarding, and is told to trust our authentication results rather than re-checking the sender against our address.

Step 3
Shadow run

A rule on your current platform sends us a copy of inbound mail. We score every copy without touching delivery, learn who writes to you, and compare our verdicts with your current filter before anything changes.

Step 4
Change the MX record

Point MX at mx1.openefa.com. Mail starts arriving through OpenEFA as DNS propagates. Rollback is the same change in reverse.

What your administrator configures, by platform

Written for the person who will do the work. Each item says what to set and why it matters. We walk through all of it with you on the onboarding call.

Microsoft 365 / Exchange Online

Three settings in the Exchange and Defender admin centers, plus the MX change.

What you configure
  • Inbound connector from OpenEFA. In the Exchange admin center, a partner connector that accepts mail from our gateway addresses. Without it, Exchange Online Protection treats us as just another internet sender.
  • Enhanced Filtering for Connectors ("skip listing") on that connector. Exchange evaluates SPF against the server that connected to it. After cutover that server is us, so every sender's SPF would fail. Skip listing tells Exchange to evaluate the hop before us, from the Received header we add, and its own verdicts become correct again.
  • Trusted ARC sealer: openefa.com in the Defender email authentication settings (recommended). We seal our SPF, DKIM and DMARC results into the message with ARC. Listing us as a trusted sealer lets Exchange accept that verdict even for mail that was forwarded or modified on the way.
  • Outbound copy for trust learning (optional but recommended). A journal rule that sends a copy of outbound mail to an address we provide. Knowing who your people write to means replies are trusted from the first day instead of being treated as first contact.
  • MX record to mx1.openefa.com, and your Exchange Online MX hostname given to us so we know where to deliver.
Good to know
  • Users keep Outlook, mobile apps and the web client exactly as they are. OpenEFA adds headers and the quarantine portal; it does not replace Microsoft's mailbox-level protection, which continues to run behind us.
  • Shared tenants with several domains work; each domain gets its own policies and quarantine view.

Google Workspace

Two Gmail settings in the Admin console, a routing rule if you use groups, plus the MX change.

What you configure
  • Inbound gateway. Under Gmail → Spam, phishing and malware, list our gateway addresses as the inbound gateway. This is Google's equivalent of skip listing: Gmail evaluates the original sender instead of us and does not re-score mail we have already filtered.
  • Group routing rule if you use Google Groups as distribution lists or shared inboxes. Gmail expands a group into its members and sends each copy back out through the inbound gateway. Without a rule that keeps expanded group mail inside Google, members receive duplicates.
  • Outbound copy for trust learning (optional but recommended). A compliance rule that sends a copy of outbound mail to an address we provide. Same purpose as on Microsoft 365: your replies are trusted from day one.
  • MX record to mx1.openefa.com. We deliver to Google's inbound SMTP service for your domain.
Good to know
  • Gmail's own spam folder keeps working behind us. In practice almost everything we deliver lands in the inbox, because the mail that would have gone to spam was held in quarantine instead, where the user can see why.

Zimbra, Exchange Server and other on-premises mail servers

Postfix, Exim, Sendmail, Dovecot-based stacks, Xeams and hosted Exchange all follow the same pattern.

What you configure
  • Firewall and MTA accept-from rule. Allow SMTP from our gateway addresses, and add them to your server's trusted-network or originating-IP list. Trusted-network status stops your server from re-running its own spam checks against our address and, on servers that do so, from treating us as a relay source.
  • Recipient list. Give us the valid addresses, or allow us to verify them against your server. We refuse unknown recipients at SMTP time, so your server stops receiving dictionary attacks and stops generating bounces for them.
  • Require TLS on inbound connections from us if your server supports it. We deliver over TLS only and never fall back to plain text, so requiring it costs nothing.
  • MX record to mx1.openefa.com, and the address or hostname of your server for delivery. A non-standard port is fine.
Good to know
  • If your server is on a dynamic or residential connection, OpenEFA can also act as your outbound smarthost so your mail leaves from a reputable address. See outbound mail below.
  • For regulated environments the same service can run on an appliance or virtual machine at your site. See hosted on your premises.

Zoho Mail, Rackspace, Fastmail and other hosted providers

Any provider that lets you set your own MX record works.

What you configure
  • MX record to mx1.openefa.com, and the provider's inbound SMTP hostname for your domain given to us.
  • Inbound gateway or trusted-IP setting where the provider offers one (Zoho and Rackspace do). It stops the provider from re-filtering mail we have already cleared and keeps its authentication checks pointed at the original sender.
  • Recipient list, as above.

Outbound mail through OpenEFA (optional)

Inbound filtering never needs any change to how your mail leaves. If you want OpenEFA as your outbound gateway as well, your server or tenant relays through us with authentication, we sign your mail with DKIM for your domain, and your SPF record adds include:_spf.openefa.com. This suits servers on dynamic addresses, organizations consolidating several senders, and anyone who wants outbound content policy. It is set up as a separate project and priced separately. Ask us about it.

The outbound copy used for trust learning is not the same thing: that is a copy of your mail sent to us by your own platform's journaling or compliance rule, and your mail still leaves the way it does today.

Cutover and rollback

  • Lower the MX record's TTL a day or two before cutover, so both the change and any rollback take effect in minutes rather than hours.
  • Change the MX record when the shadow run has settled and the recipient list is complete. Mail arrives through OpenEFA as resolvers pick up the change, typically within an hour.
  • Keep the old filter running through its next renewal. It no longer sees inbound mail, but it costs nothing to leave in place while you decide.
  • Rollback is the MX record changed back. Nothing on your server was altered, so there is nothing else to undo. Mail already in our quarantine stays available for its retention period.

What your users will notice

  • Less in the spam folder, more in quarantine. Held mail appears in the MailGuard portal and in a daily digest, each message with the reasons it was held. Users release, report or trust a sender in one click.
  • Links are rewritten to pass through our Time-of-Click service, so a page that turns malicious after delivery is still blocked. The text of the link is left exactly as the sender wrote it.
  • Headers are added with the score, the modules that fired and our authentication results, for anyone who wants to look.
  • A short notice marks mail from a sender your organization has never corresponded with before.
  • The portal speaks their language: English, Czech, Dutch, French, German, Italian, Polish, Portuguese, Slovak and Spanish.

Replacing another gateway?

The migration guide covers the timeline, what carries over from Barracuda, Mimecast and Proofpoint, and the discovery call. This page is the platform-side detail that goes with it.

Request a Demo Talk to Us