Connecting n8n to OVH Hosted Exchange

Questions
1

Hey, been struggling with this for a while and hoping someone has solved it.

Setup:

- OVH Hosted Exchange (ex4.mail.ovh.net)

- n8n Cloud

- Trying to read emails via EWS to build a follow-up automation (weekly trigger, check unanswered threads, generate drafts via Claude)

Problem:

OVH Exchange EWS endpoint only accepts NTLM and Negotiate authentication — no Basic Auth at all. Confirmed via curl:

```

< HTTP/2 401

< www-authenticate: Negotiate

< www-authenticate: NTLM

```

I’ve tried:

- HTTP Request node with Basic Auth credentials

- HTTP Request node with Header Auth (manually built Authorization: Basic header with base64)

- Microsoft Outlook node via Managed OAuth2 (connected fine but reads a different Microsoft account, not the OVH Exchange mailbox)

- IMAP Trigger node (works for new incoming emails but can’t query historical threads or check if we replied)

What I actually need:

- Read inbox threads from the last 13 days

- Check which threads have no reply from us

- Pass unanswered threads to Claude for draft generation

- Trigger: every Monday morning

Question:

Has anyone successfully connected n8n to OVH Hosted Exchange using NTLM auth? Is there a way to implement NTLM handshake in HTTP Request node? Or is there another approach I’m missing entirely?

Migrating to Google Workspace is on the table but would prefer to keep the existing setup if possible.

Thanks

3

I would treat this as a route decision rather than trying more Basic/Header Auth variants.

If the endpoint is only advertising Negotiate / NTLM, a manually built Basic header will not complete the handshake, and n8n Cloud’s normal HTTP Request node is probably the wrong place to solve EWS NTLM directly.

The safer paths I would test are:

  1. IMAP historical query first, if OVH exposes enough capability. A weekly workflow can search the last 13 days, then compare inbox candidates against Sent using Message-ID, In-Reply-To, References, normalized subject, sender, and date windows. The important test is whether the IMAP node or a controlled IMAP request can search existing mail, not only trigger on new mail.

  2. If IMAP cannot expose enough thread state, put a very small mailbox-owned bridge in front of n8n. The bridge handles EWS/NTLM with a library that supports that handshake, then returns only normalized metadata to n8n, for example: thread id, latest inbound date, has outbound reply, subject hash, sender domain, and a redacted snippet flag. n8n then handles the Monday schedule and Claude draft step.

  3. Keep the Claude step behind human review. For a follow-up workflow I would not send directly from the model; I would generate drafts plus a reason code like no_sent_reply_found, ambiguous_thread_match, or needs_manual_check.

Before choosing, I would capture three redacted facts:

  • IMAP CAPABILITY and whether historical SEARCH SINCE works.
  • Whether Sent is readable from the same mailbox/account.
  • One fake or redacted thread showing the headers you can use for matching.

I would avoid sharing mailbox credentials or full email bodies for this first diagnostic. A small metadata-only proof should be enough to decide whether this stays on OVH, needs an NTLM bridge, or is worth migrating.

4

Welcome to the n8n community @Patryk_Kalwas
What issue did you encounter with IMAP?
The ideal approach here is to use IMAP as a fallback and rebuild threads by Message-ID/In-Reply-To/References. If that doesn’t work, I recommend creating a microservice, it can be in Python or Node.js, to handle the EWS and NTLM authentication before n8n so it reaches via the HTTP node.