Ett företag kan skicka supportsvar, kvitton och nyhetsbrev genom olika system samtidigt som det presenterar samma varumärke för mottagarna. En grön indikator på domännivå är därför bara en utgångspunkt. Den praktiska uppgiften är att koppla varje sändande ström till bevis som visar hur dess meddelanden är konstruerade och levererade.
Fastställ destination och kravuppsättning
Googles krav för personlig Gmail trädde i kraft den 1 februari 2024. Alla avsändare behöver SPF eller DKIM, TLS , giltig framåt/bakåt DNS , RFC 5322 formatering och låg rapporterad skräppost. Google rekommenderar att du håller dig under 0,1 % och undviker 0,3 % eller högre; det senare är inte ett hälsosamt mål. Bulksändare behöver både SPF och DKIM , DMARC med åtminstone p=none, och inriktning för direktmeddelanden. FAQen skiljer vidarebefordrade meddelanden och e-postlistor från detta krav på anpassning av direktpost; som inte konverterar ett protokollfel till ett DMARC pass. Relevant massmarknadsföring och prenumererad trafik behöver också header-baserad Avsluta prenumeration med ett klick och en synlig kroppslänk. Googles riktlinjer för avsändare.
Googles vanliga frågor beskriver ökad efterlevnad från november 2025. Den rekommenderar att hedra avanmälan inom 48 timmar och gör att missa det fönstret blir ett hinder för att minska leveransen. Som en intern operativ regel, använd inte mer än 48 timmar, med snabb bearbetning som mål; detta är inte ett påstående om att RFC 8058 anger den deadline. Vanliga frågor om Googles krav.
Använd de länkade källorna som den underhållna checklistan istället för att behandla en statisk artikel som en verkställighetskalender. Registrera när källan kontrollerades och vem som äger kontrollera den igen innan en betydande lansering. Bulkklassificering förtjänar sitt eget inventeringssteg; en enda ströms volym är inte tillräckligt med bevis för att klassificera organisationen.
Bygg en bevisrad per ström
Referenser: RFC 6376 §3.5.
För varje applikation eller tjänst, registrera företagsägaren, synlig från domänen, kuvertsändare domän, DKIM -signeringsdomän och väljare, sändningsinfrastruktur, meddelandesyfte och mottagardestination. Inkludera bortglömda system som faktureringsexport, evenemangsplattformar och supportverktyg. Skilj en tjänst som skickar e-post från den infrastruktur som gör den slutliga utgående anslutningen.
Bifoga ett nyligen auktoriserat meddelandeexempel till raden. Granska hela det levererade meddelandet i stället för bara applikationens mallförhandsgranskning. En förhandsgranskning kan utelämna rubriker som läggs till senare, medan en nedströms gateway kan ändra ett signerat fält. Håll mottagarens information och avregistrera tokens borta från brett delade skärmdumpar och biljetter.
Förvandla ett policykrav till en testbar kontroll
Referenser: RFC 8058 §3.1, RFC 8058 §4.
Använd separata kolumner för konfigurerade, observerade och olösta. En publicerad nyckel är konfigurationsbevis; en giltig signatur på det slutliga meddelandet är observationsbevis. En leverantör som säger att den stöder en funktion är inte ett bevis på att det här kontot har aktiverat det. För varje misslyckad kontroll, tilldela ägaren som kan göra korrigeringen och identifiera det minsta säkra omtestet.
För en kampanjström, inspektera de slutliga avregistreringsrubrikerna, deras DKIM täckning och mottagaren/listans koppling. Använd endast en kontrollerad mottagare för att utöva effektmåttet. För transportproblem, bevara det faktiska svaret och anslutningsbeviset. Förklara inte TLS verifierad bara för att leverantörens marknadsföringssida nämner kryptering.
Applicera en illustrativ lanseringsgrind
Tänk på ett fiktivt företag med tre strömmar: kontoaviseringar från en applikation, nyhetsbrev från en kampanjtjänst och personliga svar från en brevlådetjänst. Kampanjtjänstens inställningssida rapporterar att autentisering är aktiverad, men det levererade nyhetsbrevet saknar den obligatoriska posthuvudet för att avsluta prenumerationen. Kontomeddelandet har en giltig signatur; det personliga svaret har ännu inte tagits fram.
Den korrekta startposten är inte "domänen passerad." Det är en korrigerad och omtestad nyhetsbrevsåtgärd, ett observerat kontoaviseringsresultat och ett väntande personligt svarsprov. Detta är en illustrativ granskning, inte bevis på att någon riktig hyresgäst har dessa defekter. Övningen är reproducerbar genom att göra tre inventeringsrader och vägra förvandla okända celler till pass.
Kontrollera igen efter ändringar och behåll osäkerheten
Referenser: RFC 6376 §6.
Upprepa de berörda kontrollerna efter att ha ändrat en avsändare, gateway, signeringskonfiguration eller mall. Behåll det gamla och det nya exemplet så att en granskare kan se vad som har förändrats. Undvik orelaterade DNS -redigeringar när det misslyckade kravet gäller meddelandekonstruktion eller hantering av avregistrering.
Ett beredskapsrekord bör sluta med specifika strömresultat och återstående luckor. Efterlevnad är inte en garanti för inkorgen, och den här guiden gör inte anspråk på ett livetest Gmail hyresgästen. Dess utdata är en praktisk bevisplan som kan köras mot organisationens auktoriserade sändande strömmar.