Sophos Email Mailflow: reparera Microsoft 365 systematiskt

Om Sophos Email Mailflow slutar fungera i Microsoft 365 ska man inte radera anslutningar eller transportregler på måfå. Kontrollera först domänstatus i Sophos Fusion (tidigare Sophos Central), kör Run a Quick Test och jämför samma meddelande i Microsoft Message Trace och Sophos Message History. Reparera därefter den berörda vägen.

Snabbväg: Connected med grön bock betyder att Mailflow-anslutningen fungerar. Not Connected med rött kryss kräver kontroll av anslutning eller behörighet. Ett utropstecken med View Details visar att en regel eller anslutning har ändrats direkt i Microsoft 365. Vid fel 552 bör man först leta efter dubbla Sophos- och Microsoft-headers; de visar ofta att en signaturtjänst har skickat meddelandet genom Sophos igen.

Runbooken gäller endast Sophos Email i Mailflow-läge (MFR). MX-posterna fortsätter att peka på Microsoft 365, medan Microsofts transportregler och anslutningar skickar meddelanden till Sophos och tillbaka. I Gateway-läge pekar MX på Sophos och diagnostik och borttagning följer en annan process. Använd inte Gateway-anvisningar för en Mailflow-domän. Installation och planerad migrering beskrivs i Konfigurera Sophos Email Mailflow för Microsoft 365.

Förutsättningar och säker utgångspunkt

Det krävs administrativ åtkomst till Sophos Fusion och ett konto som kan godkänna Sophos Email-appen och nödvändiga Exchange Online-behörigheter för mail flow. Microsoft 365-domänerna måste vara lämpade för Mailflow och nödvändiga användare och grupper synkroniserade.

Dokumentera före varje ändring:

domän, avsändare, mottagare, UTC-tid, Internet Message-ID och fullständiga headers;
aktuell Mailflow Connection- och eventuell Post Delivery-status;
namn, status och prioritet för Sophos-, signatur- och övriga regler och anslutningar;
resultat från Microsoft Message Trace och Sophos Message History;
senast fungerande konfiguration och ansvarig för varje ändring.

Ändra bara en faktor per test. Ta inte bort Sophos-domänen xgeconnector.com; det kan störa mail flow och bearbetning. Radera inte heller en till synes övergiven anslutning förrän domäntilldelning och återställningsväg dokumenterats.

1. Kontrollera anslutning och domänstatus

Öppna Global Settings i Sophos Fusion.
Välj Products and Services > Email > M365 Mailflow Domains.
Kontrollera domänen:
- grön bock, Connected: anslutningen finns;
- rött kryss, Not Connected: håll pekaren över och klicka på den gröna bocken för att återansluta;
- utropstecken, View Details: undersök en Microsoft 365-ändring.
Klicka på testikonen. Ange en kontrollerad mottagaradress under Run a Quick Test och välj Proceed. Testet kan ta några minuter.
Vid fel, använd först Run The Test Again och sedan Reconnect om felet kvarstår.

Ett lyckat Quick Test återställer den gröna bocken men bevisar inte leverans hela vägen. Skicka därefter ett kontrollerat inkommande och ett utgående meddelande och följ dem till mottagaren i Microsoft Message Trace och Sophos Message History.

Om Reconnect inte skapar regler eller anslutningar

Kontrollera att Sophos Mailflow-appen har nödvändiga rolltilldelningar i klientorganisationen. Exchange Online-behörigheterna för mail flow måste vara tillgängliga via Exchange-administratörsrollen. Automatisk reparation kräver giltigt godkännande och dessa behörigheter.

Om Reconnect fortfarande misslyckas ska man inte upprepa manuella raderingar. Spara status, Quick Test-resultat, regel- och anslutningsnamn samt Message-ID och eskalera till Sophos Support; manuell rensning kan krävas.

2. Hantera en varning om ändrade Mailflow-objekt

Sophos övervakar inaktivering, radering och ändring av regler och anslutningar som Mailflow behöver. Microsoft 365-granskning måste vara aktiv och Sophos Email-appen måste ha organisationsbehörigheten Read activity data. För domäner som konfigurerats före 12 april 2022 beviljas den genom att koppla från och återansluta; senare konfigurationer bör redan ha den.

Varningarna är High, Medium eller Low. Alla visas i Sophos Fusion; endast High och Medium skickar dessutom e-post till administratörer och superadministratörer och ändrar domänstatus. Gruppera under Alerts, öppna Mail Flow Rules och använd View Details för att se domän, tid, objekt och ändring.

Känt namnbyte av distributionslista: kontrollera att den nya gruppen synkroniserats, uppdatera den i M365-domäninställningarna och spara.
Avsiktlig ändring: dokumentera den och kör Run a Quick Test; behåll den bara om testet lyckas.
Okänd eller oavsiktlig ändring: identifiera granskningshändelse och ansvarig i Microsoft 365. Återställ en förstådd felaktig ändring och testa igen. Om åtgärden är oklar eller testet misslyckas, använd Reconnect så att Sophos kan återskapa eller aktivera nödvändiga objekt.

En varning ensam bevisar inte ett avbrott. En planerad ändring är inte heller säker bara för att den är känd; Quick Test och leveranstester avgör.

3. Åtgärda SPF-fel efter returen till Microsoft 365

Utgående Mailflow-meddelanden går från Microsoft 365 till Sophos och tillbaka. SPF kan misslyckas om den regionala Sophos-avsändaren inte är auktoriserad i domänens SPF-post.

v=spf1 include:spf.protection.outlook.com -all

Lägg till include-domänen som publiceras för Sophos Fusion-regionen:

v=spf1 include:spf.protection.outlook.com include:<sophos-spf-domain> -all

<sophos-spf-domain> är en platshållare, inte ett värde att publicera. Hämta aktuellt regionalt värde från Sophos Email domain information, behåll en SPF-TXT-post per domän och ändra inte slutmekanismen utan granskning. Kontrollera publicerad TXT efter DNS-propagation och skicka ett utgående test; SPF ska godkännas för den förväntade vägen.

4. Åtgärda vidarebefordran och Microsoft DLP

Externt automatiskt vidarebefordrat meddelande avvisas

Microsoft 365 skriver om envelope-from (P1 From) med SRS. Om Header-From fortfarande är en extern domän som inte finns i Sophos Email kan Sophos avvisa meddelandet. Sophos vidarebefordrar inte generellt externt ursprunglig post, eftersom det skulle skapa en open relay-liknande risk och skada anseendet.

Öppna Policies & rules > Threat policies > Rules > Enhanced filtering i Microsoft 365 Security Center.
Välj anslutningen som tillåter inkommande meddelanden från Sophos Email.
Aktivera Automatically detect and skip the last IP address för organisationen.
Ställ in vidarebefordran så att en lokal brevlåda i den skyddade domänen används som avsändare.
Upprepa med samma källa och mål och jämför headers, Message Trace och Message History.

Lägg inte till godtyckliga externa domäner i Sophos och skapa inte ett brett relay-undantag.

Microsoft DLP skickar dubbla aviseringar

Om en DLP-regel utlöses vid båda Mailflow-passagerna ska endast dokumenterade Sophos Email-avsändar-IP undantas från just den regeln:

Logga in som administratör i Microsoft Purview DLP-portalen.
Redigera policy och regel under Advanced DLP rules > Customize advanced DLP rules.
Välj Add exception > Except if sender IP address is och ange endast aktuella regionala Sophos-IP från domäninformationen.
Spara och upprepa för varje berörd regel.
Bekräfta med ett kontrollerat meddelande att DLP fortfarande utvärderar men bara skickar en avisering.

Bredda inte undantaget till onödiga intervall; då fungerar DLP fortsatt för andra vägar.

5. Undersök fel 552 och signaturtjänster

Typiskt NDR är:

552 5.6.0 Headers too large (32768 max)

Granska fullständiga headers. Dubbla grupper som X-Sophos-Antispam, X-LASED-Hits, X-Microsoft-Antispam-Message-Info eller X-Microsoft-Antispam-Message-Info-Original visar upprepad bearbetning. Med CodeTwo eller Exclaimer ser den felaktiga vägen ofta ut så här:

Microsoft 365 > Sophos > Microsoft 365 > signature service > Microsoft 365 > Sophos > Microsoft 365 > recipient

Den permanenta målvägen behandlar meddelandet en gång per tjänst:

Microsoft 365 > signature service > Microsoft 365 > Sophos > recipient

Granska anslutningar och regler för signaturtjänsten och Sophos. CodeTwo eller Exclaimer ska köras före Sophos utgående väg; ta bort eller begränsa överlappande regler som skickar tillbaka meddelandet till Sophos. Konfigurera tredjepartsregeln enligt leverantörens aktuella råd. Message Trace och headers ska visa en passage per tjänst.

Begränsad lösning utan routingloop

Om ingen dubbel väg finns men en stor Microsoft-diagnosheader ändå överskrider gränsen, skapa i Exchange Admin Center under Mail flow > Rules:

Apply this rule if: A message header > includes any of these words; header X-Sophos-Email-ID, ord True.
Do the following: Modify the message properties > remove a message header; header X-Microsoft-Exchange-Diagnostics-untrusted.
Behåll övriga standardvärden. Placera regeln efter Sophos Email-reglerna för prefilter och redirect; om de har standardprioritet 0, 1 och 2, använd prioritet 3.

Exportera eller dokumentera ordningen först. Testa sedan ett berört och ett normalt meddelande. Regeln minskar headerdata men rättar inte en loop. Att ta bort Microsoft-headers i Sophos med .* är också tillfälligt; vid dubbla Sophos-headers ska routingen repareras.

Förväntat beteende: två känslighetsetiketter

Microsoft 365 kan tillämpa samma sensitivity label två gånger på utgående post: före sändning till Sophos och efter retur. Om Message Trace visar denna väg utan loop är det förväntat Mailflow-beteende och inget bevis på en andra Sophos-skanning. Ändra inte anslutningarna enbart av detta skäl.

Validering, återställning och eskalering

Reparationen är klar när:

domänen visar Connected under M365 Mailflow Domains och Quick Test lyckas;
ett inkommande och ett utgående meddelande stämmer i Microsoft Message Trace och Sophos Message History och levereras;
headers visar endast förväntade Sophos-, Microsoft- och signaturpassager;
SPF lyckas och vidarebefordrings- eller DLP-test ger exakt väntat resultat;
inga nya High- eller Medium-Mailflowvarningar visas.

För en avsiktlig manuell återställning kopplas domänen från via krysset bredvid Connected i M365 Mailflow Domains. Sophos tar bort appar, anslutningar och regler som skapats för domänen; det kan ta några minuter. Kontrollera före återanslutning att de tagits bort under App registrations i Microsoft Entra Admin Center och Mail flow > Rules samt Mail flow > Connectors i Exchange Admin Center. Återanslut sedan med giltigt godkännande.

Skilj en Gateway-RBL-blockering före Mailflow-identifiering

Om ett inkommande meddelande avvisas, Sophos Gateway-loggarna visar en RBL-blockering men Sophos Message History saknar motsvarande Mailflow-händelse, kan den fortfarande aktiva Gateway-anslutningen ha tillämpat sin blocklista i realtid innan Sophos hann identifiera Mailflow-anslutningen och vidarebefordra meddelandet. Korrelera samma meddelande och samma UTC-tid i Gateway-loggarna, Microsoft Message Trace och Mailflow Message History. I detta mönster bevisar den saknade Mailflow-händelsen inte att Mailflow-anslutningen har slutat fungera.

Gör därför inget brett undantag från en RBL och inaktivera den inte globalt. Förläng inte heller parallell bearbetning: ta skyndsamt bort den gamla Gateway-anslutningen enligt migreringsplanen när Mailflow har validerats i båda riktningarna.

Detta är kontrollerad reparation, inte spontan rensning. Definiera i produktion först underhållsfönster, alternativ väg och avbrottskriterium. Vid migrering från Gateway till Mailflow behålls den dokumenterade Gateway-vägen endast som planerad återställning; Gateway och Mailflow får inte samtidigt dirigera samma produktionsdomän genom Sophos, eftersom dubbla skanningar eller loopar kan uppstå. Om objekt finns kvar, ansvarig är okänd eller Reconnect misslyckas trots rätt behörigheter, stoppa ändringar och lämna domän, Message-ID, UTC-tider, headers, traces, Quick Test och objektlista till Sophos Support.