Ett program som skickar via Microsoft 365 behöver en e-postrutt som stöds samt korrekt autentisering. Klient SMTP inlämning, anslutningsbaserat SMTP relä och Direct Send använder olika förtroende- och mottagarmodeller.
Identifiera rutten innan du byter SPF, DKIM eller DMARC. DNS kan beskriva ett sändningsberoende, men det kan inte förvandla en rutt som inte stöds till ett auktoriserat relä eller få Direct Send att leverera till externa mottagare.
Anteckna vad applikationen behöver göra
Identifiera applikationens värdplats, avsändaridentitet, avsedda mottagare och stödda autentiserings- och transportfunktioner. Anteckna ansvarig företagstjänst och administratör.
Skilj en enhet inom organisationen från en värdbaserad app från tredje part. Kontrollera den aktuella Microsoft-guiden för den värdmodellen istället för att anta att varje produkt kan använda samma anslutning.
Inkludera ett separat test för externa mottagare när de är en del av verksamhetens arbetsflöde. En framgång endast internt skapar inte en extern leveransväg.
Jämför de rutter som stöds
Microsofts nuvarande installationsguide särskiljer följande tillvägagångssätt:
Klient SMTP inlämning använder en autentiserad molnpostlåda och stöder interna och externa mottagare.
SMTP relä använder en inkommande anslutning och kan reläa externt när dess förutsättningar är uppfyllda.
Direktsändning är intern mottagarens leverans, inte Internetrelä.
High Volume Email är en separat intern mottagartjänst som använder ett HVE-konto, inte ett externt leveransalternativ.
Behandla denna jämförelse som ett urvalshjälpmedel, inte den fullständiga konfigurationen eller licensspecifikationen. Kontrollera om tillämpligt autentiseringsstöd, nätverksåtkomst, begränsningar och förutsättningar i de aktuella instruktionerna från första part.
Aktivera inte en föråldrad eller olämplig autentiseringsmetod bara för att en äldre enhetsguide visar det. Välj en rutt som applikationen och den aktuella tjänsten faktiskt stöder.
Förstå kontaktförtroende innan du använder SMTP -relä
Microsoft dokumenterar certifikatbaserad eller offentlig IP-baserad autentisering för dess SMTP reläarrangemang. Nätverks- och värdkraven spelar roll.
En certifikatbaserad rutt behöver en lämplig accepterad domänrelation i certifikatkonfigurationen. En IP-baserad rutt beror på den offentliga adressen som är synlig för Microsoft, inte en privat adress som visas på enheten.
Microsofts nuvarande guide utesluter tredjepartsbaserade applikationer, såsom Azure-värdbaserade tjänster, från detta SMTP reläarrangemang. Där IP-autentisering används måste adressen vara statisk och inte delas med en annan organisation. Granska delade adress- och värdbegränsningar noggrant. Att skapa en IP-anslutning för infrastruktur som delas utanför organisationen kan skapa ett annat förtroendeomfång än det som administratören avsåg.
Använd Microsofts genererade eller verifierade MX ändpunkt och nuvarande anslutningsprocedur. Uppfinn inte en slutpunkt från ett förkortat domännamn eller kopiera en annan hyresgästs inställningar.
Blanda inte ihop Direct Send med externt relä
Direct Send tillhandahåller inte leverans till mottagare utanför den molnbaserade organisationen. Microsofts vägledning behandlar det som ett alternativ för avancerade kunder med relevant e-postserveransvar och lämpliga begränsningar.
I ett syntetiskt exempel skickar en skanner framgångsrikt till en anställd men misslyckas när arbetsflödet lägger till en kunds externa adress. Det symtomet överensstämmer med en rutt vars mottagaromfattning inte inkluderar externt relä.
Att lägga till en SPF inkludering kan inte ändra det mottagaromfånget. Omvärdera rutten och applikationskraven innan du redigerar orelaterade poster.
Verifiera identiteten efter den valda rutten
Referenser: RFC 9989 §4.4.
När den stödda rutten har konfigurerats, inspektera mottagna meddelanden från den faktiska applikationen. Registrera den synliga From, utvärderad SPF identitet, relevanta DKIM signaturer och betrodda DMARC resultat.
En anslutnings acceptans av en anslutning och en mottagares anpassade autentiseringsresultat skapar olika saker. En utgående gateway eller ytterligare relä kan också påverka slutresultatet.
Använd Microsoft 365 -autentiseringsguiden för domänens inställningar och inriktning diagnos för en raw-pass mismatch.
Behåll en ruttspecifik acceptanspost
Behåll den valda metoden, värdmodell, förtroendemekanism, mottagaromfattning, ägare och representantresultat. Inkludera exakta leverantörsinstruktioner och konfigurationsdatum så att senare administratörer kan identifiera ändrade krav.
Registrera autentisering och leveransfel separat. En avvisad anslutning, en mottagarväg som inte stöds och ett mottaget meddelande som misslyckas med justering kan kräva olika korrigeringar.
Det fullständiga resultatet är en applikationsväg som stöds med ansvarsfullt förtroende och verifierade meddelanden, inte bara en giltig TXT post eller ett framgångsrikt internt test.