Säg godnatt
till din sista
Exchange Server.
SMTP-reläet för Microsoft 365. Dina skrivare, skannrar och appar fortsätter att skicka, och servern får äntligen sova.
Inte släppt ännu, förhandsversion kommer snart.
Sendman är det policystyrda SMTP-reläet för Microsoft 365, byggt för varje skrivare, skanner och applikation som bara talar ren SMTP. Det autentiserar dem mot Microsoft Entra ID, avgränsar dem med IP-adress och avsändarpolicy och lämnar över mejlen till Exchange Online eller den leveranstjänst du redan använder — den sista lokala Exchange Server har därmed inget kvar att göra.
PROBLEMETServern som bara finns för skrivarnas skull
I nästan varje organisation finns det en Exchange Server kvar. Ingen läser mejl på den. Den körs fortfarande för att en skanner, en nattlig ERP-export och en larmpanel behöver skicka, och det enda någon av dem kan är att öppna en port och autentisera sig.
Fyra återvändsgränder
Alla har provat minst en av dem. Ingen håller.
- 01
Behålla Exchange Server i drift
Du patchar en mejlserver för att en skanner ska kunna mejla en PDF. Varje säkerhetsbulletin för Exchange är nu din helg.
Återvändsgränd: Servern blir kvar - 02
Öppna ett oautentiserat internt relä
Allt som kan nå connectorn kan skicka som vem som helst i din domän. Ingen identitet, ingen avsändarkontroll, inget att granska i efterhand.
Återvändsgränd: Kontrollen är borta - 03
Lägga ett postlådelösenord på 200 enheter
Det kan inte roteras utan att besöka varje enhet, och en kopia av det sitter på en lapp i kopieringsrummet.
Återvändsgränd: Kontrollen är borta - 04
Peka allt mot en massutskickstjänst
Leveransen fungerar. Inget på vägen kontrollerar vem som skickar som vem, eller till vem, och den delade API-nyckeln är lika god som en sändningsbehörighet för hela domänen.
Återvändsgränd: Kontrollen är borta - 05 · Utvägen
Alla fyra är samma byteshandel. Antingen håller du en mejlserver vid liv för enheternas skull, eller så ger du upp kontrollen över vem som får skicka som vem. Sendman är alternativet som vägrar byteshandeln.
Utväg: Servern borta, kontrollen kvar
Ersätt reläfunktionen i lokal Exchange
Dirigera till Exchange Online eller externa leveranstjänster
Äldre SMTP-inloggningar, moderna identiteter
Separat dirigering per domän
Behåll din befintliga uppsättning
En session, från början till slut
Sendman sitter i själva SMTP-konversationen, inte bredvid den. Det finns fem tillfällen där det fattar ett beslut. Välj ett och se vilken del av utbytet det styr.
Tre policyer. Ändra vem som knackar på.
Det här är den verkliga utvärderingsordningen, körd live: tillåtelselistan, sedan de policyer som gäller för den här identiteten och den här adressen, sedan avsändaren, sedan varje mottagare för sig. Ändra vilken som helst av de fyra och se vad reläet svarar.
Policy 10 är avgränsad till svc-scan@contoso.com från 198.51.100.24. scan@contoso.com matchar dess tillåtna avsändare och accounting@contoso.com matchar dess tillåtna mottagare, så Sendman öppnar en egen session mot backenden och lämnar över meddelandet oförändrat.
Policyerna som utvärderas
Global tillåtelselista: 198.51.100.16 – 198.51.100.31, 192.0.2.128 – 192.0.2.143
svc-scan@contoso.com, från huvudkontoret
senders: scan@contoso\.com
receivers: .*@contoso\.com
mfp-3f, från var som helst på tillåtelselistan
senders: .*@contoso\.com
receivers: .*@contoso\.com
Vilken enhet som helst på huvudkontoret, ingen inloggning
senders: noreply@contoso\.com
receivers: .*@contoso\.com
Policyer väljs efter omfattning och reduceras sedan till det lägsta prioritetsnummer som gäller. Policyer med samma prioritet slås samman, så en enhet kan få rättigheter från flera regler samtidigt.
Exchanges sista uppgift, plus kontroll
Äldre enheter behöver tre saker för att fortsätta fungera: en port att tala med, en autentiseringsmekanism de förstår och en behörighet. Sendman ger dem alla tre och lägger den tredje under din kontroll.
Entra ID-autentisering
Användarnamn och lösenord fortsätter att fungera som de är, validerade mot Microsoft Entra ID, utan appregistrering, utan medgivande, utan att något behöver ändras i din tenant och utan någon katalog att synkronisera.
Hybridinloggningar fungerar som de är
En enhet som konfigurerades för flera år sedan med
CONTOSO\svc-scanfortsätter att fungera. Sendman matchar domäninloggningen mot rätt Entra-användare, så inget behöver skrivas om på enheten och ingen behöver besöka skrivaren.
Ett eget valv för inloggningsuppgifter
För enheter som inte bör ha en katalogidentitet utfärdar du i stället inloggningsuppgifter i Sendman. De lagras med AES-256-GCM, jämförs i konstant tid och visas aldrig igen, och detsamma gäller lösenordet till din backend.
LOGIN, PLAIN och NTLM
De tre mekanismer som gammal hårdvara faktiskt implementerar, inklusive NTLM, som nästan inget annat framför Microsoft 365 fortfarande talar. Var och en kan stängas av för sig.
En global IP-tillåtelselista
Intervallen utvärderas i samma ögonblick som en anslutning accepteras, före SMTP-hälsningen, och på port 465 till och med före TLS-handskakningen. Allt annat når aldrig konversationen, än mindre autentiseringen.
Policyer med prioriteter
Avgränsa en regel till ett användarnamn, ett IP-intervall eller båda. Det lägsta prioritetsnummer som gäller vinner; regler med samma prioritet slås samman, så en enhet kan ärva rättigheter från fler än en.
Avsändar- och mottagarkontroll
Reguljära uttryck på båda sidor, tillämpade vid
MAIL FROMoch vid varjeRCPT TO. Ingen skickar som vd:n, och inget blir ett öppet relä av misstag.
Anonymt relä, med avsikt
Vissa enheter kan helt enkelt inte autentisera sig. De får en smal fil som måste aktiveras medvetet, är avgränsad till ett IP-intervall och fortfarande omfattas av avsändar- och mottagarregler.
TLS på varje port
Implicit TLS på 465, STARTTLS på 25 och 587, med ett certifikat som utfärdas åt dig eller ett du tar med själv, förnyat utan omstart. Vidare mot backenden är sessionen krypterad överallt där backenden stöder det.
Vilken backend du än skickar genom
Exchange Online utan SMTP AUTH, opåverkat av Microsofts avveckling av Basic Authentication, eller Azure Communication Services och andra transporttjänster. Att byta är en inställning, inte en ny utrullning.
Gäller från nästa anslutning
Konfigurationen läses in på nytt för varje session som öppnas. Redigera en policy, så styrs nästa enhet som ansluter redan av den. Ingen omstart, inget ändringsfönster, ingen cache att vänta ut.
Mätvärden du kan larma på
Varje session lämnar spår, autentiseringar, leveranser, sessionstider, sökbara i portalen och redo att larma på. En enhet som har slutat skicka är en sökning bort, inte ett supportärende.
Roller som betyder det de säger
Läsare ser varje regel och ändrar ingen; administratörer ändrar konfigurationen. Det upprätthålls av tjänsten vid varje anrop, och varje post registrerar vem som skapade den. Policyer registrerar också vem som senast ändrade dem.
Sökbar händelselogg
Varje misslyckad autentisering och policyöverträdelse, filtrerbar på användare, adress, avsändare och mottagare, med regeln som avvisade den namngiven i posten. ”Varför studsade det där” tar en sökning.
På färdplanenSniff Mode
Öppna ett insamlingsfönster och se exakt vad en enhet presenterar: källadressen, användarnamnet den anger, avsändaren den gör anspråk på. För skrivaren som ingen har lösenordet till och som ingen leverantör längre stöder.
Specifikationer
Namnen och siffrorna en administratör frågar efter innan det första testmejlet.
Anslutning
- Portar
- 25 och 587 med STARTTLS, 465 med implicit TLS
- Certifikat
- Utfärdas åt dig eller ta med ditt eget, förnyas utan omstart
- Tillåtelselista
- IPv4-adressintervall, upp till 16 384 adresser vardera
Autentisering
- Mekanismer
- LOGIN, PLAIN, NTLM
- Identitetskällor
- Microsoft Entra ID (inklusive hybridinloggningar av typen DOMAIN\user), Sendmans valv för inloggningsuppgifter
- Valvkryptering
- AES-256-GCM
Policyer
- Omfattning
- Användarnamn, IP-intervall eller båda
- Prioriteter
- Lägsta nummer vinner, lika prioritet slås samman
- Avsändar- och mottagarregler
- Reguljära uttryck, tillämpade vid MAIL FROM och varje RCPT TO
- Anonymt relä
- Per policy, bundet till ett IP-intervall
Leverans
- Backender
- Exchange Online (utan SMTP AUTH), Azure Communication Services, andra SMTP-transporttjänster
- Meddelandestorlek
- Upp till 25 MB per meddelande (din backend kan tillåta mindre)
- Hantering
- Skickas vidare oförändrat, ingen kö, ingen kopia sparas
Drift
- Konfiguration
- Platform Portal, gäller från nästa anslutning
- Roller
- Läsare, administratör
- Telemetri
- Sökbar i portalen
- Ingår
- Alla uppdateringar, incidentsupport
- Certifiering
- Våra utvecklings- och driftteam är certifierade enligt ISO 27001
Varför avveckla den sista Exchange Server
När Sendman har tagit över reläet kan servern gå. Det här är vad du vinner.
En mindre attackyta
Lokal Exchange är en av de mest angripna arbetsbelastningarna som finns. När den sista servern är borta finns det ingen Exchange-CVE kvar att patcha en helg och ingen zero-day riktad mot din perimeter.
Inget kvar på internet
OWA, ECP, Autodiscover och Exchange-webbtjänsterna försvinner från din kant mot internet. En ingång mindre för initial åtkomst, ett mål mindre för fjärrkörning av kod.
Ingen mer Exchange-patchning
Inga kumulativa uppdateringar och säkerhetsuppdateringar att testa, installera och övervaka, inga underhållsfönster för dem, och ingen Exchange Server kvar som hamnar på efterkälken när nästa kritiska fix kommer.
Ingen nästa migrering
Exchange 2016 och 2019 förlorade sitt stöd i oktober 2025, och Subscription Edition är nästa uppgradering i kalendern. Utan server finns det ingen nästa migrering att planera, finansiera eller överleva.
Ett privilegierat system mindre
Exchange är djupt invävt i AD och har höga privilegier. Att ta bort det tar ett förstklassigt mål för stöld av inloggningsuppgifter av bordet, och efter SOA-överföringen lämnar större delen av dess avtryck också AD.
Mindre att driva
Ingen övervakning, backup, certifikat, lagring eller virtuella maskiner att köra för Exchange, och inget separat koncept för katastrofåterställning att skriva, testa och hålla aktuellt. En arbetsbelastning mindre på varje checklista.
En renare arkitektur
Meddelandehantering är Exchange Online, punkt. Inget hybridspecialfall, och färre komponenter att kontrollera när mejlflöde, Autodiscover, mottagare eller autentisering krånglar.
Mindre kompetens att behålla
Kompetens om lokal Exchange blir allt ovanligare och dyrare. Utan en server att sköta behöver du inte längre behålla den, eller köpa in den när den enda som har den är på semester.
Tydligare roller, lägre kostnad
Mindre infrastruktur, drift, backup, övervakning och administration. Microsoft driver plattformen, du administrerar Exchange Online, och gränsen mellan de två är äntligen tydlig.
Tre steg, och en server du kan stänga av
- Peka Sendman mot din backendPeka Sendman mot din backendVälj Exchange Online, Azure Communication Services eller den värd du redan skickar genom, och ange det den behöver. Ett formulär i portalen, och ingen ny utrullning när det ändras.
- Släpp in enheterna och säg vad de får göraSläpp in enheterna och säg vad de får göraLägg till intervallen de ansluter från, utfärda valvinloggningar till enheter som inte bör ha en katalogidentitet, och skriv sedan policyerna för vem som får skicka som vad, och till vem.
- Peka om DNS, avveckla servernPeka om DNS, avveckla servernPeka värdnamnet som dina enheter skickar till mot Sendman i stället för Exchange Server. I bästa fall är det allt som krävs. Inte en enda enhet rörs, och Exchange Server har inget kvar att göra.
Frågorna som kommer först
Vad administratörer frågar innan det första testmejlet går igenom.
01Lagrar Sendman vår e-post?
Nej. Det proxar SMTP-sessionen och vidarebefordrar den som den kommer in. Det finns ingen postlåda, ingen kö, ingen spool och inget arkiv, och själva meddelandet skickas vidare oförändrat, inklusive rubriker. Det enda Sendman behåller är din konfiguration.
02Måste vi registrera något i vår Entra-tenant?
Nej. Sendman validerar enheternas inloggningsuppgifter mot Microsoft Entra ID utan appregistrering, utan medgivande och utan att något behöver ändras i din tenant. Hybridinloggningar som CONTOSO\svc-scan fungerar som de är.
03Hur blir det med multifaktorautentisering på de kontona?
Ingetdera står i vägen. En valvinloggning rör aldrig din katalog, så det finns inget att fråga efter. Entra ID-konton fungerar också: multifaktorautentisering och Conditional Access står inte i vägen, inte ens med strikta policyer, och enheten ser aldrig någon uppmaning. Vad ett konto får skicka som, och till vem, är inte en postlådebehörighet i Exchange Online utan en Sendman-policy: avsändar- och mottagarregler avgör, för valvinloggningar och Entra ID-konton lika.
04Tänk om en enhet inte klarar TLS alls?
Den kan fortfarande ansluta på en okrypterad port, och identitet, IP och policy tillämpas på exakt samma sätt. Om du accepterar ett okrypterat första hopp från den enheten är ditt beslut; tillåtelselistan begränsar det till dina egna utgående adresser, och från Sendman och vidare är sessionen krypterad överallt där backenden stöder det.
05Vad händer med SPF, DKIM och DMARC?
De hör till domänen du skickar från och hanteras av den backend som faktiskt levererar, Exchange Online eller Azure Communication Services. Sendman skriver inte om ditt kuvert eller dina rubriker, så det du har konfigurerat för den backenden fortsätter att fungera precis som i dag.
06Vad händer om Sendman inte kan nå sin konfiguration?
Anslutningar avvisas med ett tillfälligt ”tjänsten inte tillgänglig”-svar som säger åt en välartad avsändare att hålla kvar meddelandet och försöka igen, så att ett lagringshickup fördröjer mejlen i stället för att förlora dem.
07Kan vi behålla Exchange Online som backend?
Ja. Många organisationer behåller Exchange Online som leveransväg och använder Sendman för det autentiserings- och policylager som deras enheter behöver. Backenden kan bytas senare utan att en enda enhet rörs.
08Var finns vår konfiguration, och vem kan se den?
I lagring isolerad till din tenant. Inloggningsuppgifter krypteras innan de skrivs. Åtkomst till portalen kommer från din plattformstenant, läsare ser varje regel och ändrar ingen, administratörer ändrar konfigurationen, och varje post på tillåtelselistan, varje policy och varje inloggningsuppgift registrerar vem som skapade den.
09Hur tar vi reda på vad en enhet faktiskt skickar?
Varje misslyckad autentisering och policyöverträdelse hamnar i den sökbara händelseloggen, med regeln som avvisade den namngiven i posten, och svaret enheten får talar om vilken grind som avvisade den. Sniff Mode, ett insamlingsfönster som visar exakt vad en enhet presenterar, dess källadress, användarnamnet den anger och avsändaren den gör anspråk på, finns på färdplanen.
Träffa oss på plats
Sendman är ute på vägarna i höst. Kom förbi, ta med din skrivarhistoria och se reläet i aktion.
Workplace Ninja Summit
Communitykonferens i Baden om Microsoft Endpoint Management och säkerhet
it-sa
Träffa oss även i år på Europas ledande mässa för IT-säkerhet
Molnbaserad RADIUS-tjänst RADIUSaaS
Molnnativ certifikatutfärdare SCEPman
