Bekräfta omfattningen av Greatmail-tjänsten
Börja med order- och kontoägaren, inte en SPF sträng som finns i en gammal handledning. Fastställ om denna ändring flyttar värdbaserade postlådor till Greatmail eller endast auktoriserar en utgående tjänst. Registrera den berörda domänen, befintlig postlådeleverantör, applikationer som skickas för dess räkning och vem som kan godkänna ändringar av att ta emot e-post. Den här guidens leverantörsspecifika installationsfakta täcker Greatmail e-postvärd; tillämpa inte tyst en inkorgsmigrering på ett SMTP-konto.
Greatmails värdsupportsida säger att dess onboarding-e-post tillhandahåller de nödvändiga DNS inställningarna: MX -routing plus TXT poster för SPF och DKIM. Skaffa den instruktionsuppsättningen från kontoägaren eller Greatmails support innan du publicerar något. Denna guide tillhandahåller medvetet inte ett universellt servernamn, väljare eller offentlig nyckel. DNS krav för Greatmail-värd
Separat ta emot och skicka ändringar
Skapa två delar i ändringsposten. Den mottagande delen identifierar den planerade postlådeplatsen och MX cutover. Den sändande delen identifierar auktoriserade kuvertdomäner och DKIM -signeringsdomäner. En organisation som flyttar alla brevlådor kan behöva båda; ett begränsat utgående projekt får inte ändra mottagande av post utan separat godkännande. Spara befintliga offentliga register och serviceinställningar innan du börjar.
Jämför varje tillhandahållen DNS ägare med dess fullt kvalificerade resultat. En DNS -redaktörs förkortning för zonens apex och dess behandling av bifogade domännamn varierar. Bekräfta det faktiska publicerade svaret. För en DKIM TXT post, behåll det fullständiga public-key-värdet och använd DNS värdens dokumenterade hantering för långa TXT strängar. Trunkera inte en nyckel bara för att passa ett gränssnitt. Den publika nyckeln hör hemma i DNS ; privat signeringsmaterial gör det inte.
SPF kräver en tillämplig policy hos en ägare. Om den policyn redan tillåter andra legitima tjänster, slå samman den godkända Greatmail-auktoriseringen i den istället för att lägga till en konkurrerande policy. Kontrollera hela uppslagskostnaden, inklusive kapslade inkluderar. Hålla ett rekord av vilken avsändare motiverar varje termin så att framtida sanering inte av misstag tar bort en löne-, fakturerings- eller supportapplikation.
Testa båda riktningarna när du migrerar postlådor
Ursprunglig acceptplan: för en postlådemigrering, leverera ett ofarligt meddelande från ett icke-relaterat kontrollerat konto till den värdbaserade postlådan och svara sedan via den vanliga användarklienten. Testa också varje applikation som ingår i sändningsändringen. En lyckad inloggning för webbmail är inte ett bevis på att offentlig MX routing eller ett applikationsrelä har ändrats korrekt.
För utgående meddelanden, registrera det betrodda mottagarsystemets autentiseringsresultat, synligt från domän, SMTP kuvertdomän och varje DKIM -signeringsdomän och väljare. Utvärdera DMARC inriktning mot den synliga From-domänen och dess tillämpliga justeringsläge. Passar SPF för en annan organisatorisk domän upprättar inte ett anpassat SPF resultat. En passning i linje DKIM signatur kan fortfarande uppfylla DMARC när SPF sökvägen inte justeras.
Illustrativt fall: personalposten lyckas efter en brevlådeflyttning, men en äldre applikation skickar fortfarande genom sitt tidigare relä. Att ta bort reläets SPF -auktorisering omedelbart kan bryta applikationen. Identifiera och migrera eller behåll uttryckligen beroendet innan du städar upp policyn. Tolka inte ett framgångsrikt brevlådetest som en komplett sändningsinventering.
Bevara en användbar återställningsväg
Om mottagningen misslyckas, undersök MX omfattningen och postlådans beredskap. Om utgående autentisering misslyckas, undersök den faktiska sändningsrutten och signeringsnyckeln. Återställ den senast godkända ändringen på det felaktiga lagret istället för att ersätta alla DNS poster tillsammans. Koordinera eventuell MX återställning med postlådeägarna för att undvika att dela in inkommande meddelanden över obevakade system.
Dokumentationen granskades den 8 november 2026. Inget Greatmail-konto, angivna onboarding-värden, live DNS post eller levererat meddelande inspekterades. Kontospecifik konfiguration krävs fortfarande innan exekvering; testdesignen och exemplet är illustrativa operativa riktlinjer.
Håll en reläberoendebok för konkreta reläer
Skriftligt fall GM-01 antar att den värdbaserade postlådan user@example.com får ett kontrollerat meddelande och svarar med betrodd DKIM pass, d=example.com och s=host1. En separat äldre applikation använder fortfarande sitt gamla relä med From alerts@example.com , envelope bounce@example.com , och inga observerade mottagarresultat eller signaturer. Den första rutten tillhandahåller exakt DKIM justering endast för det meddelandet; det fastslår ingenting om applikationen. Behåll den gamla behörigheten medan applikationsägaren bekräftar dess godkända ersättning och erhåller ett kontrollerat test. Postlådeadministratören äger återställningen för mottagning och applikationsägaren äger relämigrering. Dessa är stipulerade undervisningsfakta, inte inspekterade brevlådor, onboardinginställningar eller tester.
Bevara verkställighetsgränsen
RFC 9989 Avsnitt 7.4 kräver giltig DKIM , inte enbart SPF , för domänpublicering p=reject, och varnar för interoperabilitet med indirekt e-post och e-postlistor. Ett enda framgångsrikt test för direktmeddelanden är inte ett bevis på att varje legitim väg är redo för en starkare politik. Behåll befintligt godkänt skydd medan du diagnostiserar det faktiska gapet; varje policyändring behöver ett eget beslut.