Een bedrijf kan via verschillende systemen ondersteuningsantwoorden, ontvangstbewijzen en nieuwsbrieven verzenden, terwijl hetzelfde merk aan de ontvangers wordt gepresenteerd. Een groene indicator op domeinniveau is daarom slechts een startpunt. De praktische taak is om elke zendstroom te verbinden met bewijsmateriaal dat laat zien hoe de berichten zijn opgebouwd en afgeleverd.
Bepaal de bestemming en de gestelde eisen
De vereisten van Google voor persoonlijke Gmail zijn op 1 februari 2024 van kracht geworden. Alle afzenders hebben dit nodig SPF of DKIM, TLS , geldige forward/reverse DNS , RFC 5322 -formattering en weinig gerapporteerde spam. Google raadt aan om onder de 0,1% te blijven en 0,3% of hoger te vermijden; dit laatste is geen gezond doelwit. Bulkverzenders hebben zowel SPF als DKIM nodig, DMARC met tenminste p=none, En uitlijning voor directe berichten. In de FAQ wordt onderscheid gemaakt tussen doorgestuurde berichten en berichten uit de mailinglijst en deze vereiste voor afstemming van direct mail; die een protocolfout niet omzet in een DMARC -pas. Relevant bulkmarketing en geabonneerd verkeer moet ook op headers zijn gebaseerd met één klik afmelden en een zichtbare bodylink. Richtlijnen voor afzenders van Google.
In de veelgestelde vragen van Google wordt de verhoogde handhaving vanaf november 2025 beschreven. Er wordt aanbevolen om afmeldingen binnen 48 uur te honoreren en het missen van dat venster wordt een belemmering voor de beperking van de bezorging. Gebruik als interne operationele regel niet meer dan 48 uur, met een snelle verwerking als doel; dit is geen verklaring dat RFC 8058 die deadline specificeert. Veelgestelde vragen over Google-vereisten.
Gebruik de gekoppelde bronnen als de bijgehouden checklist in plaats van een statisch artikel te behandelen als een handhavingskalender. Leg vast wanneer de bron is gecontroleerd en wie de eigenaar is die deze opnieuw controleert vóór een belangrijke lancering. Bulkclassificatie verdient een eigen inventarisatiestap; het volume van één enkele stroom is niet voldoende bewijs om de organisatie te classificeren.
Bouw één bewijsrij per stream
Referenties: RFC 6376 §3.5.
Leg voor elke toepassing of dienst de bedrijfseigenaar vast, zichtbaar Van domein, envelop afzender domein, DKIM -ondertekeningsdomein en keuzeschakelaar, verzendinfrastructuur, doel van het bericht en bestemming van de ontvanger. Inclusief vergeten systemen zoals factureringsexports, evenementenplatforms en ondersteuningstools. Onderscheid een service die e-mail verzendt van de infrastructuur die de uiteindelijke uitgaande verbinding tot stand brengt.
Voeg een recent geautoriseerd berichtvoorbeeld toe aan de rij. Bekijk het volledige afgeleverde bericht in plaats van alleen het sjabloonvoorbeeld van de toepassing. In een voorbeeld kunnen later toegevoegde headers worden weggelaten, terwijl een downstream-gateway een ondertekend veld kan wijzigen. Houd de gegevens van de ontvanger bij en verwijder tokens uit algemeen gedeelde schermafbeeldingen en tickets.
Verander een beleidsvereiste in een toetsbare controle
Referenties: RFC 8058 §3.1, RFC 8058 §4.
Gebruik aparte kolommen voor geconfigureerd, waargenomen en onopgelost. Een gepubliceerde sleutel is configuratiebewijs; een geldige handtekening op het eindbericht is observatiebewijs. Een leverancier die zegt dat hij een functie ondersteunt, is geen bewijs dat dit account deze heeft ingeschakeld. Wijs voor elke mislukte controle de eigenaar aan die de correctie kan uitvoeren en identificeer de kleinste veilige hertest.
Voor een promotiestream controleert u de uiteindelijke afmeldingskoppen, hun DKIM dekking en de koppeling tussen ontvanger en lijst. Gebruik alleen een gecontroleerde ontvanger om het eindpunt uit te oefenen. Bewaar bij transportproblemen de daadwerkelijke respons en het verbindingsbewijs. Verklaar TLS niet geverifieerd alleen maar omdat de marketingpagina van de provider codering vermeldt.
Pas een illustratieve lanceerpoort toe
Beschouw een fictief bedrijf met drie stromen: accountmeldingen van een applicatie, nieuwsbrieven van een campagnedienst en persoonlijke antwoorden van een mailboxdienst. Op de opstartpagina van de campagneservice wordt vermeld dat authenticatie is ingeschakeld, maar de afgeleverde nieuwsbrief mist de vereiste POST-header voor het afmelden. Het rekeningbericht is voorzien van een geldige handtekening; het persoonlijke antwoord is nog niet bemonsterd.
Het juiste startrecord is niet 'het domein is doorgegeven'. Het is een gecorrigeerde en opnieuw geteste nieuwsbriefactie, een waargenomen resultaat van een accountmelding en een in behandeling zijnd voorbeeld van een persoonlijk antwoord. Dit is een illustratieve beoordelingsoefening en geen bewijs dat een echte huurder deze gebreken heeft. De oefening is reproduceerbaar door drie inventarisrijen te maken en te weigeren onbekende cellen in passen om te zetten.
Controleer opnieuw na wijzigingen en behoud onzekerheid
Referenties: RFC 6376 §6.
Herhaal de betrokken controles na het wijzigen van een afzender, gateway, ondertekeningsconfiguratie of sjabloon. Bewaar het oude monster en het nieuwe monster, zodat een recensent kan zien wat er is veranderd. Vermijd niet-gerelateerde DNS -bewerkingen als de mislukte vereiste betrekking heeft op het maken van berichten of het afhandelen van afmeldingen.
Een gereedheidsrecord moet eindigen met specifieke stroomresultaten en resterende hiaten. Naleving is geen inboxgarantie en deze handleiding claimt geen live Gmail tenanttest. Het resultaat is een praktisch bewijsplan dat kan worden uitgevoerd op basis van de geautoriseerde verzendstromen van de organisatie.