En bedrift kan sende støttesvar, kvitteringer og nyhetsbrev gjennom forskjellige systemer samtidig som den presenterer samme merke for mottakerne. En grønn indikator på domenenivå er derfor bare et utgangspunkt. Den praktiske oppgaven er å koble hver sendestrøm til bevis som viser hvordan meldingene er konstruert og levert.
Etabler destinasjonen og kravsettet
Googles krav til personlig Gmail trådte i kraft 1. februar 2024. Alle avsendere trenger SPF eller DKIM, TLS , gyldig forover/bakover DNS , RFC 5322 -formatering og lavt rapportert spam. Google anbefaler å holde seg under 0,1 % og unngå 0,3 % eller høyere; sistnevnte er ikke et sunt mål. Bulk avsendere trenger både SPF og DKIM , DMARC med minst p=none, og justering for direktemeldinger. Vanlige spørsmål skiller videresendte meldinger og e-postlistemeldinger fra dette kravet til justering av direktepost; som ikke konverterer en protokollfeil til et DMARC pass. Relevant bulkmarkedsføring og abonnert trafikk trenger også header-basert avslutt abonnement med ett klikk og en synlig kroppskobling. Googles retningslinjer for avsender.
Googles vanlige spørsmål beskriver økt håndhevelse fra november 2025. Den anbefaler å respektere avmeldinger innen 48 timer og gjør det å gå glipp av dette vinduet til en hindring for leveringsreduksjon. Som en intern driftsregel, bruk ikke mer enn 48 timer, med rask behandling som mål; dette er ikke en erklæring om at RFC 8058 spesifiserer den fristen. Vanlige spørsmål om Google-krav.
Bruk de koblede kildene som den vedlikeholdte sjekklisten i stedet for å behandle en statisk artikkel som en håndhevelseskalender. Registrer når kilden ble sjekket og hvem som eier, kontroller den igjen før en betydelig lansering. Bulkklassifisering fortjener sitt eget lagertrinn; en enkelt strøms volum er ikke nok bevis til å klassifisere organisasjonen.
Bygg én bevisrad per strøm
Referanser: RFC 6376 §3.5.
For hver applikasjon eller tjeneste, registrer bedriftseieren, synlig fra domene, konvoluttavsender domene, DKIM -signeringsdomene og velger, sendeinfrastruktur, meldingsformål og mottakerdestinasjon. Inkluder glemte systemer som faktureringseksport, eventplattformer og støtteverktøy. Skille en tjeneste som sender e-post fra infrastrukturen som gjør den endelige utgående tilkoblingen.
Legg ved et nylig godkjent meldingseksempel til raden. Undersøk hele den leverte meldingen i stedet for bare forhåndsvisningen av applikasjonens mal. En forhåndsvisning kan utelate overskrifter som legges til senere, mens en nedstrøms gateway kan endre et signert felt. Hold mottakerinformasjon og avregistrer tokens utenfor bredt delte skjermbilder og billetter.
Gjør et policykrav til en testbar sjekk
Referanser: RFC 8058 §3.1, RFC 8058 §4.
Bruk separate kolonner for konfigurerte, observerte og uløste. En publisert nøkkel er konfigurasjonsbevis; en gyldig signatur på den endelige meldingen er observasjonsbevis. En leverandør som sier at den støtter en funksjon er ikke et bevis på at denne kontoen har aktivert den. For hver mislykket kontroll, tilordne eieren som er i stand til å foreta korrigeringen og identifisere den minste sikre retesten.
For en kampanjestrøm, inspiser de endelige avmeldingsoverskriftene, deres DKIM dekning og mottaker-/listetilknytningen. Bruk kun en kontrollert mottaker for å utøve endepunktet. For et transportproblem, ta vare på det faktiske svaret og koblingsbeviset. Ikke erklær TLS bekreftet bare fordi leverandørens markedsføringsside nevner kryptering.
Bruk en illustrativ utskytningsport
Tenk på et fiktivt selskap med tre strømmer: kontomeldinger fra en applikasjon, nyhetsbrev fra en kampanjetjeneste og personlige svar fra en postbokstjeneste. Kampanjetjenestens oppsettside rapporterer at autentisering er aktivert, men det leverte nyhetsbrevet mangler POST-overskriften for avmelding. Kontovarselet har gyldig signatur; det personlige svaret er ennå ikke samplet.
Den riktige lanseringsposten er ikke «domenet som er bestått». Det er en korrigert og testet nyhetsbrevhandling, et observert kontovarselresultat og en ventende personlig svarprøve. Dette er en illustrativ gjennomgangsøvelse, ikke bevis på at noen ekte leietaker har disse manglene. Øvelsen er reproduserbar ved å lage tre inventarrader og nekte å gjøre ukjente celler om til pasninger.
Sjekk på nytt etter endringer og behold usikkerheten
Referanser: RFC 6376 §6.
Gjenta de berørte kontrollene etter å ha endret en avsender, gateway, signeringskonfigurasjon eller mal. Behold den gamle prøven og den nye prøven slik at en anmelder kan se hva som er endret. Unngå urelaterte DNS -redigeringer når det mislykkede kravet gjelder meldingskonstruksjon eller håndtering av avmelding.
En beredskapsrekord bør avsluttes med spesifikke strømutfall og gjenværende hull. Samsvar er ikke en innboksgaranti, og denne veiledningen krever ikke en live Gmail leiertest. Resultatet er en praktisk bevisplan som kan utføres mot organisasjonens autoriserte sendestrømmer.