Identifiera Rackspace-produkten innan du följer en DKIM guide
Rackspace tillhandahåller flera tjänster som kan förekomma i samma organisations postinventering. En Rackspace-värd DNS zon, en Rackspace-e-postlåda, Hosted Exchange, Microsoft 365 och en applikation som körs på en molnserver är inte utbytbara autentiseringsvägar. Den här guiden täcker domäner som stöds av det dokumenterade Cloud Office Sender Authentication-arbetsflödet. Bekräfta den faktiska produkten och tillgängliga domänkontroller innan du använder den.
Rackspaces separata Skapa en DKIM TXT post Artikeln säger uttryckligen att dess generiska Cloud DNS metod skiljer sig från konfigurationen för Rackspace Email, Hosted Exchange och Office 365 -kunder och dirigerar dessa kunder till Cloud Office-hjälp. Använd inte den allmänna nyckelgenereringsproceduren som bevis på att värdpost kommer att signera med en manuellt skapad nyckel. Rackspace DKIM produktomfattning notering
Skriv ner postlådeprodukten, kontoadministratören, synliga från-domäner, inlämningsslutpunkter och eventuella utgående reläer. För en webbplats eller affärsapplikation, fastställa om den skickar via den värdbaserade postlådetjänsten eller skickar oberoende. En webbplats som är värd för Rackspace fastställer inte att dess utgående meddelanden använder Cloud Office-signering.
Denna produktidentifiering är en acceptansgrind. Om den begärda domänen inte exponerar den dokumenterade avsändarautentiseringskontrollen, stoppa och skaffa aktuella produktspecifika instruktioner. Kompensera inte genom att skapa en godtycklig väljare i DNS , byter brevlåda MX poster, eller förutsatt att en annan Rackspace-produkts inställningar gäller.
Aktivera inloggning i flödet för värddomän som stöds
Det dokumenterade Cloud Office-arbetsflödet startar i kontrollpanelens avsnitt Domäner vid Sender Authentication ( DKIM ). Välj domänen och aktivera DKIM . DNS som hanteras via den panelen hanteras automatiskt av det dokumenterade flödet; externt värd DNS kräver publicering av instruktionerna för offentliga TXT poster. Använd Verify TXT Record för att kontrollera den offentliga posten och granska eventuella valideringsfel. Rackspace anger att nya utgående meddelanden signeras efter att DKIM har aktiverats. Rackspace Cloud Office DKIM
Fånga den faktiska genererade ägaren och det offentliga värdet för den valda domänen. Om det aktuella gränssnittet inte visar tillräckligt med information, fråga Cloud Office-supporten om domänens stödda instruktioner istället för att gissa en nyckel. DNS värden publicerar offentlig information; den väljer inte självständigt en privat signeringsnyckel för en värdbaserad e-posttjänst.
Bekräfta den aktiva auktoritativa namnservrar även när kunden använder Rackspace för vissa tjänster. Ett rekord synlig i en kontrollpanel kanske inte är postmottagarens fråga. För extern DNS , kontrollera den fullt kvalificerade väljarägaren efter publicering och se till att redigeraren inte har lagt till zonen två gånger. Bevara den tidigare posten där en finns och lös en väljarkollision innan du skriver över den.
Verifieringsknappen och en mottagen signatur svarar på olika frågor. Verifiering kontrollerar en offentlig DNS förutsättning. Ett kontrollerat utgående meddelande visar om den verkliga rutten använde den avsedda signeringsdomänen och väljaren. Inget av stegen ska i tysthet ersätta det andra i bytesbiljetten.
Auktorisera den riktiga SMTP rutten med SPF
Rackspaces molnkontor SPF policyexempel på användningsområden include:emailsrvr.com. Tillämpa den behörigheten först efter att ha identifierat den värdbaserade e-postrutt den är avsedd att täcka. Om organisationen redan har en SPF rekord, bevara dess legitima avsändare och slå samman den nödvändiga mekanismen snarare än att ersätta hela policyn med ett exempel på en enda tjänst. Rackspace SPF policyvägledning
Samma domän kan också skicka via en CRM, en faktureringsplattform eller en separat webbtjänst. Spela in varje rutt och dess autentiseringskonfiguration som stöds. Auktorisera inte en orelaterade molnserveradress bara för att servern och brevlådorna delar Rackspace-varumärket. Omvänt, aktivering av värdbaserad postlåda DKIM konfigurerar inte en separat applikation som kringgår den värdbaserade tjänsten.
SPF tillåter en tillämplig policy hos en postägare och begränsar DNS-beroende utvärdering. Använd lämpliga mekanismer för den faktiska auktoriseringen; an include refererar till en annan SPF -policy och är inte en generisk behållare för en godtycklig IP-adress. Kontrollera hela den resulterande policyn och identiteten som utvärderas på mottagna meddelanden. SPF RFC 7208
Behåll eventuella ändringar av policyns slutliga kvalificering i sitt eget granskade beslut. Att lägga till en tjänst är inte automatiskt godkännande för att skärpa tillsynen för alla befintliga avsändare. Spara det ursprungliga värdet och en återställningsplan, inklusive vem som kan återställa det och hur man verifierar det resulterande offentliga svaret.
Testa brevlåda och programmeddelanden separat
Skicka kontrollerade meddelanden från den faktiska webbmail- eller e-postklientrutten i omfattning, sedan från varje separat konfigurerad applikation. Behåll en säker testidentifierare, tidsstämpel, mottagare, synlig från, kuvertdomän och den betrodda Authentication-Results. Fånga varje DKIM d= och s= par och fråga efter den matchande offentliga posten.
DKIM binder signaturen till sin signeringsdomän; att bara hitta en publik nyckel någonstans under organisationens domän bevisar inte att det observerade meddelandet använde den. Bekräfta att den avsedda signaturen skickades till mottagaren. För en misslyckad signatur, särskilj en saknad nyckel, en felaktig nyckel och meddelandeändring innan du ersätter poster. DKIM RFC 6376
DMARC kräver en godkänd SPF eller DKIM mekanism som är anpassad till den synliga From-domänen. Ett leverantörsdomänautentiseringspass kan vara ojusterat. Bevara den exakta inriktning läge, domänförhållande och tillämplig policy i bevisningen. Kräv inte att båda mekanismerna passerar som definitionen av DMARC , även om bibehållande av båda kan förbättra motståndskraften över olika leveransförhållanden. DMARC RFC 9989
Vidarebefordran bör vara en separat observation om det är viktigt för verksamheten. Ändringar i SMTP sökvägen kan påverka SPF , och ändringar av signerat innehåll kan påverka DKIM . En framgång med direktreklam är inte en garanti för varje vidarebefordran. Försvaga inte organisationens policy bara för att få ett oförklarat vidarebefordrat meddelande att verka framgångsrikt.
Behåll separata e-postströmmar efter lanseringen
Rackspaces ryktevägledning rekommenderar att man särskiljer post efter syfte och använder separata signeringsnycklar för olika sändningstjänster. Använd den principen för att hålla den värdbaserade e-postrutten för anställda särskiljbar från marknadsförings- eller transaktionssystem. Dess exempel på policyval är inte ett substitut för en organisationsspecifik tillsynsgranskning. Rackspace domän rykte vägledning
Upprätthålla ett register över domäner, tjänster, väljare, SPF auktoriseringar och ägare. När en tjänst är avdragen, verifiera att dess trafik har avslutats och ordna en godkänd borttagning istället för att samla permanent oanvänd auktorisation. När en avsändare läggs till, kräv bevis för den nya rutten innan du behandlar den som täckt av ett tidigare brevlådetest.
Rackspace acceptans arbetsblad
Fyll i detta föreslagna arbetsblad separat för varje produkt och utgående rutt. Den innehåller inga live kundobservationer.
- Produktomfattning: Rackspace-tjänst, hyresgäst, domän som stöds, kontrollpanelåtkomst, administratör och eventuell produktspecifik supportbekräftelse.
- Sändningsväg: brevlådeklient, webbmail, applikation, inlämningsslutpunkt, relä, avsedd Från och kuvertidentitet.
- DKIM inställning: aktiveringsstatus, nuvarande genererad ägare och offentligt värde, DNS hanteringsplats, verifieringsresultat och exakt fel om något.
- DNS bevis: auktoritativa namnservrar, fullständig postägare, publicerad nyckel eller mål som stöds, SPF policy, TTL:er och fångsttid.
- Meddelandebevis: säker testidentifierare, mottagare, tidsstämpel, DKIM domäner och väljare, pålitliga resultat och mekanismen som tillhandahåller justering.
- Beroenden: andra tjänster som använder samma domän, separata applikationsvägar, vidarebefordringsfall och oprövade produkter.
- Utgivningsbeslut: spärrar i produktomfattning, återställningsägare, ändringsgodkännande, granskning av små och medelstora företag och publiceringsstatus.
Fiktiv diagnos av en nyckel i fel produkt
Detta exempel är fiktivt. En administratör följer en allmän Rackspace Cloud DNS artikel, skapar en post med offentlig nyckel och förväntar sig att värdbaserade postlådemeddelanden använder den. Nästa test är osignerat med den väljaren, så administratören överväger att generera en annan nyckel.
Den föreslagna undersökningen identifierar först den värdbaserade produkten och kontrollerar dess Cloud Office-signeringskontroll som stöds. Teamet skaffar de faktiska värddomäninstruktionerna, publicerar motsvarande offentliga värde vid behov och testar nya brevlådemeddelanden. En webbplats som är värd på en separat molnserver behöver fortfarande sin egen ruttbedömning. Enbart publicering av en nyckel kan inte göra att ett icke-relaterat system besitter eller använder den matchande privata nyckeln. Det här scenariot är en diagnostisk illustration, inte en färdig konfiguration.
Produktomfattning och utlösningsgrindar
Den exakta kundprodukten, domänberättigande, hyresgästgenererade värden, auktoritativ DNS och mottagna autentiseringsresultat förblir overifierade. Hosted Exchange, Microsoft 365 och självhanterade molnserverkonfigurationer påstås inte följa denna procedur utan produktspecifik bekräftelse. Granskning av mänskliga små och medelstora företag, visuell granskning, live-postlåde- och applikationstester och godkännande av publicering kvarstår. Kandidaten måste förbli opublicerad tills dess omfångade bevis är fullständiga.
Håll värdproduktbeslutet tydligt
Det fiktiva fallet stipulerar endast att det observerade meddelandet inte använde den manuellt valda väljaren. Dess faktiska DKIM och SPF resultat förblir ospecificerade. En annan giltig signatur kan finnas, så inspektera alla signaturer innan du diagnostiserar ett signeringsavbrott. Spela in den stödda postlådeprodukten och kontrollpanelsinstruktionerna innan du föreslår en ersättningsnyckel.
Separat meddelandeacceptans från policyimplementering
Ett passande justerat SPF resultat kan tillfredsställa en meddelandeutvärdering, men motiverar inte ensamt att flytta en hel domän för att avvisa. RFC 9989 Avsnitt 7.4 kräver giltig DKIM för domäner som publicerar p=reject och varnar för interoperabilitet med indirekt e-post. Inventera alla legitima avsändare och indirekta rutter innan policyägaren godkänner verkställighet. Ingen DNS ändring, klientdrift eller test av mottagna meddelanden utfördes för den här artikeln.