En kontrollpanel för efterlevnad är användbar eftersom den sammanfattar en stor ström av observationer. Det blir missvisande när sammanfattningen behandlas som ett realtidstest av ett meddelande. Använda Google Postmaster Tools för att identifiera en fråga, samla sedan in de snävare bevis som behövs för att besvara den.
Spela in vyn du tolkar
Googles dokumentation omfattar dessa instrumentpaneler till personlig Gmail trafik. Överensstämmelse rapporteras även för den primära domänen som använder underdomänaktivitet. Postmaster använder UTC. Data är försenade och lågvolymdata kan utelämnas för sekretess. Registrera vald domän, krav, observationsdatum och skärmdumpstid innan du jämför resultat. Postmaster instrumentbrädor.
Håll konfigurationstiden åtskild från meddelandetiden. En DNS post som hämtas idag bevisar inte vilken post en mottagare observerade igår. Om ett team byter avsändare på måndag och kontrollerar instrumentpanelen direkt efteråt, kan den uppenbara oenigheten återspegla olika bevisfönster. Bevara ändringsposten och representativa meddelanden efter ändring i stället för att upprepade gånger redigera DNS tills en status ändras.
Kartlägg kravet till en observerbar artefakt
Referenser: RFC 6376 §3.5, RFC 8601 §5.
Skapa en recensionsrad med fyra fält: krav, observerat problem, bevis som behövs och ansvarig ägare. För autentisering behåller du ett slutgiltigt meddelandeprov och det betrodda mottagande systemets resultat, tillsammans med de domäner som faktiskt utvärderas. För DNS , behåll det exakta ägarens namn, typ, svar och frågetid. För prenumerationsbehandling, fånga den kontrollerade begäran och dess resulterande undertryckande tillstånd.
DKIM signaturer associerar meddelanden med signeringsdomäner; de är inte bevis för att varje tjänst som använder det synliga varumärket är identiskt konfigurerad. Inspektera signaturen på varje relevant rutt istället för att extrapolera från ett fungerande nyhetsbrev. RFC 6376.
Denna granskningsmatris är en operativ metod, inte ett ytterligare krav från Google. Dess syfte är att stoppa en tvetydig status från att bli en vag biljett som "fixa autentisering." Biljetten ska namnge tjänsten, meddelandet och identiteten som behöver uppmärksammas.
Stämma av en arbetad ändringstidslinje
Det privata granskningspaketets lokala undervisningsupplägg registrerar en illustrativ DNS korrigering kl. 10:00 UTC, ett framgångsrikt inspekterat meddelande kl. 10:15 och en instrumentpanelsobservation kl. 10:20 som fortfarande säger Behöver arbete. Dess regel behåller det aktuella meddelandebeviset medan instrumentpanelen klassificeras som väntar på senare utvärdering. Den konverterar inte instrumentpanelen till ett pass eller förklarar korrigeringen ineffektiv.
Detta är ett syntetiskt bevis-avstämningsexempel, inte ett Google-kontotest. I ett verkligt fall skulle administratören bevara det nya provet, bekräfta att alla berörda strömmar fick korrigeringen och kontrollera instrumentpanelen efter dess dokumenterade uppdateringsintervall. Ett enda framgångsrikt prov stöder endast den testade rutten.
Undersök oenighet innan du vidgar förändringen
Jämför liknande omfattningar. En överensstämmelsevy för primär domän kan innehålla en underdomän som utelämnats från teamets lokala test. En autentiseringsvy och en efterlevnadsvy kan också använda olika datamängder. Googles guide förklarar dessa skillnader och noterar att efterlevnadsändringar kan ta upp till sju dagar innan de visas. Tolka inte det intervallet som en leveransgaranti eller en anledning att ignorera aktiva fel.
Om nuvarande meddelanden fortfarande misslyckas, reparera det konkreta problemet nu. Om meddelanden passerar och bara den samlade vyn släpar efter, fortsätt att övervaka det relevanta fönstret. Om bevis saknas, tilldela dess insamling uttryckligen. Stäng uppgiften endast med verifierade ruttresultat, olöst omfattning och daterad instrumentpanelstatus. Detta ger nästa granskare ett försvarbart svar snarare än en oförklarlig grön skärmdump.
Använd en befolkad observationsordbok
Följande kompakta ordbok kombinerar Googles dokumenterade omfattning med en lokal undersökningsmetod. Krav betyder den namngivna efterlevnadskontrollen; i detta exempel är det autentisering. Population betyder personlig Gmail trafik som representeras av den primära domänvyn, inklusive underdomäner. Identitet är example.test för den vyn, medan ett meddelandeexempel också måste registrera sina faktiska signerings- och kuvertdomäner. Fönster betyder perioden som representeras av instrumentpanelen, skild från hämtningstid. Sekretessgräns innebär att saknade lågvolymobservationer förblir okända. Nästa åtgärd innebär bevisen som behövs för att lösa raden, inte en DNS redigering vald från enbart en färg.
Den reviderade fixturen har fyra explicita grenar över påhittade daterade observationer. Ett passerande scope-matchat prov behåller sitt godkänt medan Behöver arbete kvarstår. Ett news.example .test-exempel jämfört med en example.test-vy efterfrågar ett bredare räckviddsmatchat bevis. Ett okänt resultat begär det saknade meddelandeexemplet. Ett misslyckat aktuellt prov begär ruttreparation. Armaturen beräknar dessa beslut; den simulerar inte Googles uppdateringsalgoritm eller tilldelar ett pass för leverantörsefterlevnad.