Omfattning och leverantörsspecifik konfiguration
Squarespace är DNS publiceringsytan i den här guiden, inte systemet som signerar e-post. En Squarespace-registrering eller webbplats fastställer inte i sig att Squarespace är värd för den auktoritativa zonen. TXT guiden täcker Squarespace-domäner och tredjepartsdomäner som är anslutna via Namnserver Ansluta. Med DNS Connect gör du istället ändringen hos den tredje partens DNS leverantör.
Öppna domänöversikten, välj domänen och sedan DNS och DNS -inställningar. Under Custom Records väljer du Lägg till post och slutför kontoåterautentiseringen som begärts av Squarespace. Välj TXT för en SPF policy, ett TXT-formulär DKIM offentlig nyckel eller en DMARC politik. Fältet Namn är relativt: Squarespace lägger till domänen. Använd @ för spetsen, _dmarc för DMARC ägaren och den medföljande väljaren. _domainkey etikett för en DKIM nyckel. Ett fullständigt ägarenamn som anges i ett relativt fält kan publiceras ett rekord på fel dubblerad domän.
Kopiera sändningstjänstens värde istället för att låna en nyckel eller SPF -policy från ett annat konto. För en tjänst som tillhandahåller en DKIM CNAME, använd CNAME istället för TXT och behåll det exakta angivna målet. A väljare som redan används av en annan avsändare är en konflikt att undersöka, inte tillåtelse att skriva över den. Den här guiden gör inte anspråk på en universell TXT chunking eller återställningsbeteende för redigeraren; inspektera det sparade auktoritativa svaret och behåll de tidigare uppgifterna självständigt.
Beslutet som betyder något
Att publicera det tilltänkta ägarnamnet är det centrala acceptanstestet; Enbart en sparad redigeringsrad är otillräcklig.
Verifiera de publicerade posterna och den verkliga sändningsvägen
Registrera byte av ägare, sändande produkt, domän, godkänt underhållsfönster och tidigare DNS svar innan redigering. Hämta de aktuella postvärdena från det namngivna kontot eller dokumenterade leverantörens arbetsflöde. Separera värden som tillhandahålls av leverantören från val som din organisation kontrollerar, såsom DMARC policy och rapporteringsmottagare. Befintlig postlåda MX , orelaterad verifiering TXT poster och aktiva DKIM väljare är inte rensningskandidater bara för att en ny tjänst läggs till.
Fråga de auktoritativa namnservrarna för varje exakt ägare och posttyp efter publicering. Registrera frågetiden, svarande server och komplett svar. Jämför TXT strängar som ett logiskt värde där DNS svaret delar upp dem i teckensträngar. Kontrollera CNAME mål samt startaliaset. Jämför sedan ett rekursivt resolver-svar för att identifiera skillnader i cachelagring. En framgångsrik leverantörsvalidering är ett användbart bevis på konfiguration, men det fastställer inte vad en faktisk mottagare fick.
Skicka endast ett auktoriserat test till en kontrollerad mottagare med den avsedda produktvägen. Behåll det råa meddelandet och det betrodda mottagande systemet Authentication-Results. Spela in den synliga Från-domänen, SMTP MAIL FRÅN eller observerats Return-Path domän, varje DKIM d= och s= värde, SPF och DKIM resultat och mottagarens DMARC resultat. En godkänd SPF eller DKIM kontroll stöder endast DMARC när dess autentiserade domän överensstämmer med den synliga From-domänen enligt tillämplig policy. Reply-To och ett varumärkesvisningsnamn är det inte inriktning identiteter. RFC 7208 , RFC 6376 och RFC 9989 utgör protokollbasen för dessa distinktioner.
Acceptans arbetsblad, återhämtning och bevisgränser
Detta är ett originalkalkylblad för godkännande, inte en rapport om livetestning. Markera varje gate som väntar tills bevis finns: kontoomfattning bekräftad; tidigare DNS infångad; exakt ny ägare/typ/värde publicerad; leverantörsverifiering slutförd; avsedd rutt utövad; mottagna identiteter registrerade; justerad autentisering bekräftad; andra avsändare opåverkade. Tilldela en person och bevisfil till varje grind. En röd grind blockerar utrullningen även när leverantörens instrumentpanel är grön.
Om ett test misslyckas, särskilj först saknad publicering, inaktuell cachad data, inaktiv leverantörskonfiguration, fel utgående rutt och ojusterad autentisering. Korrigera den minsta påvisade defekten och testa igen. Försvaga inte DMARC eller radera andra avsändares poster bara för att klara ett test. Om en ändring skadar befintlig e-post, använd den godkända återställningsplanen och den inhämtade konfigurationen före ändring, och koordinera eventuella avsändarbyten på leverantörssidan samt DNS . Behåll gamla nycklar medan meddelanden i kö eller en godkänd överlappning fortfarande kräver dem.
Ingen kundhyresgäst, auktoritativ före/efter ändring eller verkligt mottaget meddelande var tillgängligt för detta manuskript. De bevarade källorna stödjer det dokumentära arbetsflödet; de uppfyller inte den beställda live-evidence gate. Denna utbildningsguide är inte fältvaliderad. Innehållsgranskning, liveintegreringskontroller och godkännande från ägaren är separata portar.
Bekräfta leverantörsgränsen
För ett CNAME mål anger du det DNS värdnamn som tillhandahålls av leverantören, inte en https-URL eller sökväg. Den nuvarande editorn tillåter inte en apex CNAME . Om anpassade namnservrar är aktiva, publicera där istället för att återställa delegering som en snabb lösning. Inaktivera inte DNSSEC eller ta inte bort webbplatsstandarder för att lösa ett orelaterade problem med e-postposter. En lång nyckel kräver leverantörskompatibel formatering som fortfarande producerar en logisk DKIM TXT post; be om stöd om redaktören avvisar det.
Arbeta igenom ett fiktivt diagnostiskt fall
Endast fiktivt skrivet fall: SQ-01 antar att auktoritativa namnservrar tillhör en extern DNS leverantör men operatören sparar en DKIM TXT i Squarespace-panelen. En sökning på den auktoritativa servern saknar den förväntade väljaren. Inga meddelandesignaturer eller SPF resultat är kända. DNS ägaren måste publicera den godkända posten hos den aktiva leverantören, utan att flytta namnservrar enbart för att tillfredsställa panelen. Sedan testar postägaren den faktiska avsändaren. Ingen hyresgäst, DNS , serverkommando eller meddelande utövades för detta fall.
Separera ett passerande meddelande från verkställighetsberedskap
RFC 9989 Avsnitt 7.4 kräver giltig DKIM för en domän som publicerar p=reject och varnar för interoperabilitet med indirekt e-post. Ett enda anpassat SPF resultat motiverar inte i sig en utrullning av avvisningspolicy. Granska alla legitima rutter och policyägande separat från denna leverantörskonfiguration.