En domeneautentiseringspolicy tillater ikke et program å bruke e-postreléet ditt. Reléautorisasjon kontrollerer hvem som kan sende inn e-post og hvor den kan gå; SPF, DKIM og DMARC hjelpe mottakere med å evaluere de resulterende meldingsidentitetene. Begge trengs. En rute som skilter vakkert, men aksepterer vilkårlige avsendere, er fortsatt en operasjons- og misbruksrisiko.
Velg en støttet rute
Registrer applikasjon, leietaker, innsendingsendepunkt, autentiseringsmetode, beregnet Fra identitets- og mottakerklasser. Microsoft skiller klient SMTP innsending, koblingsautentisert SMTP relé og Direct Send. Dens dokumenterte Direct Send-rute videresender ikke til Internett-mottakere gjennom Microsoft 365 , mens støttet SMTP relé kan. Dette er produktspesifikke distinksjoner, ikke universell SMTP terminologi. E-postveiledning for Microsoft-applikasjoner.
Velg gjeldende støttede metode for den faktiske arbeidsbelastningen. Unngå å kopiere en gammel enhetskonfigurasjon til en annen leietaker eller behandle en IP-tillatelsestilstand som permanent bevis på applikasjonsidentitet. Registrer hvem som eier legitimasjon, sertifikater, nettverksrestriksjoner og koblingsendringer. Ikke avslør hemmeligheter i testbeviset eller utvid den vedvarende tilgangen bare for å forenkle feilsøkingen.
Separat innsending fra endelig autentisering
SMTP transaksjonen viser hvilket stadium som godtok eller nektet en kommando. Et avslag ved RCPT TO skiller seg fra en feil etter meldingsdata, og et endelig vellykket DATA-svar betyr at mottakeren aksepterte ansvaret for meldingen i stedet for å bevise innboksplassering. RFC 5321. Ta vare på den komplette svarkoden, den forbedrede koden der den er til stede, tekst og tidsstempel i stedet for å redusere alle feil til blokkering.
Inspiser deretter en autorisert mottatt melding for dens faktiske konvolutt og signeringsdomener. Et relé kan omskrive en identitet eller bruke en signatur som endrer justering resultat. SPF vurderer den aktuelle tilknytningsruten, ikke brukerens tro på at en avsender tilhører selskapet. Ikke anta at en innleveringssuksess er et DMARC pass eller at et pass er bevis på mottakerens samtykke.
Sammenlign tre hypotetiske faseutfall
Bruk en skriftlig godkjenningsbok med tre uavhengige saker: en ikke-godkjent ekstern mottakerforespørsel forventes å bli avvist ved RCPT TO; en godkjent ekstern rute forventes å nå et akseptert endelig DATA-svar; og godkjent intern rute sjekkes separat. Illustrerende svar kan være 550 5.7.1 ved mottakeravslag, eller 250 ved RCPT TIL, 354 for DATA og 250 etter den siste prikken på en akseptert transaksjon. Dette er hypotetiske svarsekvenser, ikke fanget loopback eller Microsoft-transkripsjoner.
En klients EHLO navn er ikke bevis på autorisasjon. Reelle relétillatelser må bruke støttede autentiserings- og koblingskontroller for den distribusjonen. Ingen legitimasjonsvalidering, koblingsoppslag, lokal socket, TLS økt eller leverandørsending ble utført her. Registrer faktiske svarkoder og kontekst i en fremtidig autorisert test i stedet for å behandle disse forventede eksemplene som observerte resultater.
Test både tillatte og nektede saker
For en godkjent distribusjon, bruk kontrollerte mottakere for å teste de tiltenkte interne og eksterne banene. Inkluder en eksplisitt autorisert negativ test fra en klient som ikke skal videresendes, uten å undersøke urelaterte systemer. Ta vare på desinfiserte transkripsjoner og leverandørlogger mens du holder originale bevis under tilgangskontroll. Bekreft at avslag skjer der det er forventet og ikke kan omgås gjennom en alternativ applikasjonsrute.
Sjekk struping, køadferd og prøv eierskap på nytt før en kritisk arbeidsflyt avhenger av reléet. Et forbigående avslag bør ikke føre til en rask storm på nytt, mens en permanent konfigurasjonsfeil trenger en ansvarlig reparasjon. Dokumenter reservekrav uten å godkjenne en ubegrenset bypass.
Lukk endringen med separate resultater for relétilgang, støttet mottakeromfang, endelig meldingsautentisering og applikasjonssuksess. Merk manglende observasjoner som uløste. Dette forhindrer et team i å erklære at applikasjonen fungerer bare fordi DNS ser riktig ut eller en SMTP kommando returnerte en vellykket kode.
Kilde og utførelsesgrense
RFC 9989 avsnitt 4.4, 5.3.5 og 5.4 skille autentisering, justering og håndtering; et pass godkjenner ikke meldingsinnhold. De operasjonelle beslutningene her er anbefalinger med omfang og eksplisitt hypotetiske eksempler, ikke nye tester av en kunde, leverandør eller historisk inventar. Enhver reell endring krever sitt eget autoriserte omfang, beholdt bevis og ansvarlig beslutning.