Een domeinverificatiebeleid geeft een toepassing geen toestemming om uw e-mailrelay te gebruiken. Relay-autorisatie controleert wie e-mail kan verzenden en waar deze naartoe kan gaan; SPF, DKIM En DMARC help ontvangers de resulterende berichtidentiteiten te evalueren. Beide zijn nodig. Een route die mooi bewegwijzerd is maar willekeurige afzenders accepteert, is nog steeds een operationeel risico en misbruikrisico.
Selecteer een ondersteunde route
Registreer de applicatie, tenant, indieningseindpunt, authenticatiemethode, bedoelde identiteit en ontvangerklassen. Microsoft maakt onderscheid tussen client SMTP indiening, connector-geverifieerde SMTP relay en Direct Send. De gedocumenteerde Direct Send-route stuurt niet door naar internetontvangers via Microsoft 365 , terwijl ondersteunde SMTP relay dat wel kan. Dit zijn productspecifieke verschillen, geen universele SMTP terminologie. E-mailrichtlijnen voor Microsoft-toepassingen.
Kies de huidige ondersteunde methode voor de werkelijke werklast. Vermijd het kopiëren van een oude apparaatconfiguratie naar een andere tenant of het behandelen van een IP-toegestane voorwaarde als permanent bewijs van de identiteit van de applicatie. Leg vast wie de eigenaar is van inloggegevens, certificaten, netwerkbeperkingen en connectorwijzigingen. Maak geen geheimen in het testbewijs bekend en breid de permanente toegang niet uit alleen maar om het oplossen van problemen te vereenvoudigen.
Afzonderlijke indiening van de definitieve authenticatie
De SMTP transactie laat zien welke fase een opdracht heeft geaccepteerd of geweigerd. Een afwijzing bij RCPT TO verschilt van een mislukking na berichtgegevens, en een uiteindelijke succesvolle DATA-reactie betekent dat de ontvanger de verantwoordelijkheid voor het bericht aanvaardt in plaats van de plaatsing in de inbox te bewijzen. RFC 5321. Behoud de volledige antwoordcode, eventuele verbeterde code, tekst en tijdstempel, in plaats van dat elke fout wordt geblokkeerd.
Inspecteer vervolgens een geautoriseerd ontvangen bericht op de daadwerkelijke envelop- en ondertekeningsdomeinen. Een relay kan een identiteit herschrijven of een handtekening aanbrengen die de identiteit verandert uitlijning resultaat. SPF beoordeelt de relevante verbindingsroute, niet de overtuiging van de gebruiker dat een afzender bij het bedrijf hoort. Ga er niet vanuit dat een geslaagde indiening een DMARC -pas is of dat een pas een bewijs is van toestemming van de ontvanger.
Vergelijk drie hypothetische faseresultaten
Gebruik een schriftelijk acceptatiegrootboek met drie onafhankelijke gevallen: een niet-goedgekeurd verzoek van een externe ontvanger zal naar verwachting worden afgewezen bij RCPT TO; van een goedgekeurde externe route wordt verwacht dat deze tot een geaccepteerd definitief DATA-antwoord leidt; en een goedgekeurde interne route wordt afzonderlijk gecontroleerd. Illustratieve antwoorden kunnen zijn: 550 5.7.1 bij weigering van de ontvanger, of 250 bij RCPT TO, 354 voor DATA en 250 na de laatste punt van een geaccepteerde transactie. Dit zijn hypothetische antwoordreeksen, geen vastgelegde loopback- of Microsoft-transcripties.
Van een klant EHLO naam is geen bewijs van autorisatie. Echte relay-machtigingen moeten de ondersteunde verificatie- en connectorbesturingselementen voor die implementatie gebruiken. Er is hier geen verificatie van de inloggegevens, het opzoeken van connectoren, lokale socket, TLS sessie of providerverzending uitgevoerd. Registreer feitelijke responscodes en context in een toekomstige geautoriseerde test in plaats van deze verwachte voorbeelden als waargenomen resultaten te behandelen.
Test zowel toegestane als geweigerde gevallen
Voor een goedgekeurde implementatie gebruikt u gecontroleerde ontvangers om de beoogde interne en externe paden te testen. Voeg een expliciet geautoriseerde negatieve test toe van een klant die niet mag worden doorgegeven, zonder niet-gerelateerde systemen te onderzoeken. Bewaar opgeschoonde transcripties en providerlogboeken terwijl origineel bewijsmateriaal onder toegangscontrole blijft. Bevestig dat de weigering plaatsvindt waar dit verwacht wordt en dat deze niet kan worden omzeild via een alternatieve aanvraagroute.
Controleer de beperking, het wachtrijgedrag en probeer het eigendom opnieuw voordat een kritieke workflow afhankelijk is van het relais. Een tijdelijke weigering mag geen snelle nieuwe poging veroorzaken, terwijl een permanente configuratiefout een verantwoorde reparatie vereist. Documenteer de fallback-vereisten zonder een onbeperkte bypass toe te staan.
Sluit de wijziging af met afzonderlijke resultaten voor relay-toegang, het bereik van de ondersteunde ontvangers, de authenticatie van het uiteindelijke bericht en het succes van de toepassing. Markeer ontbrekende observaties als onopgelost. Dit voorkomt dat een team de applicatie werkend verklaart alleen maar omdat DNS er correct uitziet of één SMTP commando een succesvolle code retourneert.
Bron- en uitvoeringsgrens
RFC 9989 paragrafen 4.4, 5.3.5 en 5.4 onderscheid maken tussen authenticatie, afstemming en afhandeling; een pas onderschrijft de inhoud van het bericht niet. De operationele beslissingen hier zijn gerichte aanbevelingen en expliciet hypothetische voorbeelden, geen nieuwe tests van een klant, aanbieder of historische armatuur. Elke echte verandering vereist een eigen geautoriseerde reikwijdte, behouden bewijsmateriaal en een verantwoorde beslissing.