Email gateway

The email gateway is how OpsMerge turns client emails into tickets and sends ticket replies back out — making it look (to your clients) like they're talking to your support email, not to "OpsMerge".

The gateway is built on Haraka, our own self-hosted MTA. It's part of OpsMerge — you don't run it yourself.

Inbound mail (client → ticket)

The flow:

1. Your support email (e.g. [email protected]) is configured to forward to OpsMerge's inbound address.
2. Haraka receives the mail, validates SPF/DKIM/DMARC, and posts the message to the PSA's webhook receiver.
3. PSA matches the sender's domain to a client (or contact directly), creates a ticket, and attaches the email as the ticket's first message.

The whole chain is sub-second from Haraka receipt to ticket creation.

Setting up inbound

Settings → PSA → Email gateway → Inbound.

1. Note your tenant's inbound mailbox address (e.g. [email protected]).
2. Configure your support email host to forward to that address. How depends on your provider:
   • M365: an inbox rule on the shared mailbox that forwards to OpsMerge.
   • Google Workspace: a routing rule that forwards.
   • Generic SMTP: an .forward file or your provider's "forwarding address" setting.
3. Test by emailing your support address and watching for the ticket to appear.

Don't use auto-reply on the forwarded inbox

If your support mailbox has an out-of-office auto-reply, every forwarded email triggers an auto-reply, which then triggers OpsMerge's auto-acknowledgement (see Notifications), which is then auto-replied to. Mail loop. Turn off auto-reply on any inbox that forwards into OpsMerge.

Per-client domain routing

OpsMerge matches inbound mail to a client by sender email domain. Each client has a primary domain and optional alias domains in their client record (see Clients & contacts).

If a sender's domain matches a known client, the ticket is attributed to that client.

If no match, the ticket goes to Unattributed — a special queue. Inspect, then either:

• Set the right client and continue.
• Add an alias domain to the matching client (so future mail from this domain auto-attributes).
• Blocklist (see below).

Outbound mail (ticket reply → client)

When you reply on a ticket, the email goes out:

• From: your client-facing support address (configured per client or globally).
• Reply-To: a unique per-ticket address so the client's reply threads back into the same ticket.
• Message-Id: structured so replies match by In-Reply-To/References.
• DKIM-signed by your domain (assuming you've configured DKIM — see below).

The result: your client sees a normal email from you, not from "OpsMerge". They reply, the reply comes back into the same ticket.

Configuring your sending domain

For OpsMerge to send mail as [email protected], you need to authorise it. Three records, per sending domain:

Record	What it does	Required
SPF	Authorises Haraka's IP to send for the domain	Yes
DKIM	Lets receivers verify the mail came from authorised infra	Yes
DMARC	Policy: what receivers should do with unauthorised mail	Recommended

OpsMerge generates the exact records you need to publish:

1. Settings → PSA → Email gateway → Sending domains.
2. Click + Add domain.
3. Enter the domain (e.g. your-msp.co.uk).
4. Copy the SPF, DKIM, and DMARC records into your DNS.
5. Click Verify. OpsMerge re-queries DNS and confirms the records are in place.

Once verified, you can send "as" that domain. The same flow applies to client domains if you send replies under their identity (some MSPs do, some don't).

MTA-STS and TLS-RPT

OpsMerge publishes:

• MTA-STS policy at mta-sts.opsmerge.cloud — tells senders to your inbox to enforce TLS.
• TLS-RPT for reports on TLS failures.

This is set up for you. No configuration required.

Blocklist

When a sender or domain is sending you junk — spam, mistakenly-CC'd lists, abusive senders — block them.

Settings → PSA → Email gateway → Blocklist.

Add entries by:

• Full email (e.g. [email protected]).
• Domain (e.g. example.com).
• Pattern (e.g. *@spam-domain.co).

Blocked mail is dropped silently before becoming a ticket. The block is logged so you can audit later.

Unblock from the same screen.

Activity log

Settings → PSA → Email gateway → Activity.

Every inbound and outbound email is logged: timestamp, from/to, subject, the ticket it landed on (or didn't), and the outcome (delivered / bounced / dropped).

Use this when:

• A client says "I emailed you and you didn't reply" — check whether their email arrived.
• A bounce comes back — see what the destination's reason was.
• DKIM/SPF failures — see why some mails are being treated as suspicious.

DMARC aggregate reporting

If you set up DMARC on your sending domain with rua=mailto:[email protected], receivers send daily aggregate reports about your mail. This is post-GA territory for OpsMerge — we have it on the roadmap to surface those reports inside the email gateway UI (so you can spot suspicious senders impersonating your domain), but for now, set the rua to an inbox you check.

Common patterns

"We have a CC-everyone culture for important threads"

OpsMerge ticket emails have a unique per-ticket Reply-To so adding CCs doesn't break threading. Anyone CC'd can reply and have their reply land in the ticket. Add their address as a contact at the client for the cleanest experience.

"We want our techs' replies to go out as '[email protected]' not 'support@'"

Per-user "send-as" address: User profile → Email → Default sending address. Their replies use this, regardless of which client/ticket.

"I want a different sending domain per client (they prefer mail from '[email protected]')"

Per-client sending domain: Client → Settings → Email. Override globally-default sending domain for this one client.

Common issues

Inbound mail not becoming tickets. Check Activity log → look for the inbound row. If it's there but dropped, check the dropped reason (usually DMARC/SPF failure or blocklist). If it's not there at all, the forwarding from your inbox isn't reaching us — check your provider.

Outbound mail going to spam. Almost always DKIM/SPF not properly published on your sending domain. Run the verification check in Settings → Email gateway → Sending domains; fix any unmet record. The destination's spam score is in the Activity log's bounce detail.

Reply doesn't thread to the original ticket. The client's mail client stripped the Reply-To header (some do). The new reply will create a new ticket. Merge them via the ticket merge feature.

MTA-STS warnings on our subdomain. Default policy mode is testing — receivers report failures but still deliver. Once you've had a clean week of TLS-RPT, flip to enforce in Settings → PSA → Email gateway → MTA-STS.

Inbound shows DMARC fail despite the sender's domain being legitimate. The DNS TXT record for DMARC may have been chunked across multiple RR strings — many resolvers (and Go's LookupTXT) return each chunk separately, but DMARC verifiers must re-concatenate before parsing. We do this correctly; if a sender is failing, it's their DMARC.

Next

• Tickets — what happens once mail becomes a ticket
• Notifications — controlling outbound mail content