SMTP AUTH og SPF, DKIM og DMARC er ikke utskiftbare måter å logge på. SMTP AUTH autentiserer en klient til en SMTP server. SPF evaluerer en avsendervert mot et domenes konvoluttpolicy, DKIM verifiserer en meldingssignatur, og DMARC evaluerer justert domeneautentisering i forhold til synlig Fra. En vellykket kontopålogging kan eksistere side om side med en nedstrøms DMARC feil, og innkommende Internett-e-post trenger ikke autentiseres til innsendingskontoen din.
Finn klient-server-relasjonen
RFC 4954 definerer AUTH-utvidelsen og dens bruk av SASL-mekanismer. Serverens autorisasjonspolicy bestemmer hva den autentiserte klienten kan gjøre. Å kjenne til et autentisert kontonavn godkjenner ikke automatisk alle mulige konvolutter eller synlige fra-adresser. Innsendingstjenester bruker vanligvis ekstra avsender-, relé- og organisatoriske begrensninger.
RFC 6409 skiller meldingsinnsending fra relé. Bestem hvilken tjeneste applikasjonen bruker før du endrer legitimasjon eller DNS . En enhet som kobler til en leverandørs autentiserte innsendingstjeneste har et annet forhold enn en ekstern e-postserver som leverer Internett-post til domenets MX . Ikke prøv å fikse vanlige innkommende autentiseringsfeil ved å gi eksterne avsendere et postbokspassord.
Følg domenebeviset nedstrøms
SPF sjekker den tilkoblede verten og den relevante konvoluttidentiteten under RFC 7208 . DKIM -verifisering bruker velger og signering av domene i en signatur for å finne materiale med offentlig nøkkel og verifisere dekket innhold under RFC 6376 . DMARC krever riktig forhold mellom et bestått domene og det synlige Fra-domenet under RFC 9989.
En applikasjon kan autentisere seg til en leverandørkonto, og deretter sende med et ujustert returdomene og et ujustert DKIM signeringsdomene. Nedstrøms SPF og DKIM kan begge bestå mens DMARC mislykkes. Omvendt kan et riktig konfigurert domene sende DMARC på e-post levert mellom servere uten SMTP AUTH på det mottakervendte hoppet. Kontolegitimasjon og domeneautorisasjon må undersøkes ved deres respektive grenser.
Bruk bevisene uten å avsløre hemmeligheter
For en påloggingsfeil, registrer tjenesteendepunktet, sikker transporttilstand, annonserte metoder og fullstendig feil, unntatt legitimasjon og tokens. For avvisning av avsender etter pålogging, fange opp retningslinjene for tillatt avsender og den avviste kommandoen. For nedstrømsfeil, innhent pålitelige mottakerresultater, konvoluttinformasjon, DKIM d- og s-verdier og det synlige Fra-domenet. Unngå å kopiere autentiseringsnyttelast til billetter eller artikkeleksempler.
Sammenlign to hypotetiske utfall
Tilfelle A: en klient autentiserer til en innsendingstjeneste og har tillatelse til å sende, men den endelige mottakeren rapporterer SPF pass for vendor.example og DKIM pass med d=vendor.example mens From bruker brand.example . Forutsatt en gjeldende DMARC -policy og ingen uløst evalueringsfeil, justeres ingen av domenene og meldingen mislykkes DMARC . Et annet passord kan ikke endre disse domeneforholdene.
Tilfelle B: en server leverer vanlig innkommende post til mottakerens MX uten SMTP AUTH på det hoppet. En pålitelig mottaker rapporterer en gyldig DKIM signatur med d=brand.example samsvarende Fra= brand.example . Med en gjeldende policy og ingen uløst evalueringsfeil, kan den justerte signaturen levere et DMARC pass. Dette etablerer ikke trygt innhold, innboksplassering eller tillatelse til å utføre en forespurt forretningshandling. Begge tilfellene er oppfunne sammenligninger; ingen legitimasjon, leverandørpålogging eller kryptografisk test ble brukt.
Reparer den ansvarlige konfigurasjonen
Hvis AUTH mislykkes, følg leverandørens gjeldende støttede autentiseringsmetode og transportkrav. Ikke aktiver en foreldet mekanisme bare fordi en gammel artikkel nevner den. Hvis den autentiserte kontoen mangler tillatelse til å bruke en adresse, reparer den autoriserte avsenderkonfigurasjonen gjennom den vanlige administrative prosessen. Hvis nedstrøms justering mislykkes, konfigurer den legitime avsenderens støttede konvolutt eller DKIM domene i stedet for å anta at et annet passord vil hjelpe.
Etter reparasjon, test både innsending og endelig mottakerevaluering ved å bruke ufarlige meldinger. Behold de distinkte resultatene: klientautentisert, avsender tillatt, melding akseptert, domenemekanismer evaluert og endelig disposisjon observert. En enkelt suksessetikett skjuler for mye. Gjennomgangen lærer hvordan man skiller disse resultatene; den krever ikke utført protokollhåndtering, DKIM verifisering eller leietakerkonfigurasjon.
Hold separate akseptresultater
- Klient autentisert: registrer endepunktet, støttet mekanisme og resultat, aldri hemmeligheten.
- Avsender tillatt: bekreft at kontoen er autorisert for denne konvolutten og synlig avsender.
- Melding akseptert: behold svaret etter innholdsoverføring og mottaksserveren.
- Domenevalidert: Registrer pålitelige SPF / DKIM resultater og DMARC justering uavhengig.
- Levering observert: behold resultatet på mottakersiden uten å konvertere transportaksept til en innboksgaranti.