Aparte Concep SEND-domeinkeuze van ondertekeningsactivatie
Conceps ambtenaar domeinselectiegids, bijgewerkt op 18 september 2020, maakt onderscheid tussen bedrijfsverzenddomeinen en subdomeinen. Zijn Ondertekenen met DKIM gids, bijgewerkt op 2 juli 2020, beschrijft een door ondersteuning ondersteunde sleutel- en activeringsworkflow. Deze gedateerde instructies bieden een concreet uitgangspunt, maar de huidige toepasbaarheid van het product blijft open. Dit artikel beweert niet dat elk hedendaags Concep SEND-account dezelfde infrastructuur of bedieningselementen gebruikt.
De eerste beslissing is welk domein de campagne als afzenderadres zal gebruiken en of er een aparte merknaam nodig is voor gehoste links. De domeingids zegt dat zowel bedrijfsdomeinen als subdomeinen kunnen worden gebruikt voor verzending, terwijl alleen subdomeinen campagnelinks kunnen hosten in de gedocumenteerde indeling. Zonder die subdomeinkeuze worden links gehost op emailcc.com . Beschouw een succesvolle merklink niet als bewijs dat het afzenderdomein is geverifieerd.
Maak een inventarisatie met het beoogde verzendende domein, koppeldomein, account en verantwoordelijke DNS beheerder. Identificeer het bestaande gebruik van de voorgestelde naam voordat u zich hieraan vastlegt. Een domein dat wordt gedeeld met medewerkersmail of een ander marketingsysteem vereist coördinatie; het mag niet opnieuw worden geconfigureerd simpelweg omdat een campagne-eigenaar een Van-adres kan bewerken. Er zijn geen account- of DNS instellingen gebruikt voor dit manuscript.
Bekijk de historische instructies voor het subdomein en het bedrijfsdomein
Voor de subdomeinindeling specificeert de gids van 2020 a CNAME verwijzend naar emailcc.com . Voor een bedrijfsverzenddomein wordt dit gespecificeerd SPF autorisatie via include:emailcc.com. Behoud het onderscheid in plaats van de subdomeinalias op de zonetop van de organisatie te plaatsen of ervan uit te gaan dat dezelfde record beide doelen dient. Bevestig de huidige door de provider uitgegeven configuratie voordat u een productiewijziging doorvoert. Concep-domeinselectiegids
De formulering in de handleiding over het toevoegen van een compleet SPF -voorbeeld mag niet letterlijk worden gelezen als een instructie om twee v=spf1 beleidsregels aan elkaar te koppelen. Onder RFC 7208 , sectie 3.2mag een domein niet meerdere records publiceren die ervoor zorgen dat meer dan één SPF beleid wordt geselecteerd. Voeg de goedgekeurde autorisatie samen met het bestaande beleid en behoud andere legitieme afzenders. Voeg geen tweede versiemarkering in en vervang niet stilzwijgend de terminalkwalificatie.
Een CNAME eigenaar heeft ook een conflictbeoordeling nodig. Het voorgestelde record geeft geen toestemming om bestaande e-mail-, website- of verificatie-afhankelijkheden te overschrijven. Noteer de volledige eigenaar en het doel en vergelijk deze met de naamgevingsconventie van de DNS editor. Een editor die de zonenaam toevoegt, kan onbedoeld een dubbel achtervoegsel produceren als de invoer wordt gekopieerd zonder de interpretatie ervan te controleren.
Bevestig het verzendende domein voordat u DKIM aanvraagt
De DKIM guide zegt dat er vóór de DKIM aanvraag al een subdomein of bedrijfsdomein bij Concep moet zijn ingesteld. Ondersteuning coördineert vervolgens met IT om een sleutel te genereren, die het DNS team van de klant publiceert als een TXT record. Het artikel is niet herbruikbaar keuzeschakelaar of publieke sleutel voor alle klanten. Gebruik de feitelijk opgegeven eigenaar en waarde voor het beoogde domein, en laat de verzoekreferentie bij die wijziging horen. Concep-ondertekening met DKIM
Een verstandige voorgestelde overdracht identificeert het verzendende domein, de accountomvang, DNS operator en het verwachte voltooiingsbewijs. Het hoeft geen campagneontvangers, vertrouwelijke inhoud of inloggegevens te bevatten. Het verzenden van een ondersteuningsverzoek is een externe communicatie en vereist een geautoriseerde operator; deze gids creëert geen ticket en impliceert ook niet dat er een is ingediend. De huidige geschiktheid van het domein voor het gedocumenteerde proces blijft onopgelost totdat dit is bevestigd.
Controleer bestaande gegevens bij de gevraagde selector vóór publicatie. Een oudere sleutel kan nog steeds actief verkeer bedienen en voor een vervanging kan coördinatie nodig zijn. De openbare DNS sleutel is geen verzoek om de privé-ondertekeningssleutel van de provider. Houd het onderscheid expliciet zodat een overdracht van ondersteuning geen onnodig delen van referenties of een niet-beoordeelde verandering in de ondertekeningsverantwoordelijkheid wordt.
Bewaar de activeringsstap aan de providerzijde
De historische DKIM workflow eindigt niet wanneer het TXT record wordt opgeslagen. Er staat dat de klant de ondersteuning na publicatie informeert; Concep verifieert de verspreiding en schakelt de relevante accounts over naar zijn speciale DKIM mailserverconfiguratie. Vervolgens wordt een providertestbericht van een account beschreven en een controle op dkim=pass. Beschouw dit als de gedocumenteerde volgorde en niet als bewijs dat een lopende rekening deze acties heeft voltooid. Concep-ondertekening met DKIM
Bevestiging van voltooiing van de recordprovider afzonderlijk van DNS publicatie. Het onderscheid is van belang omdat een correct gepubliceerde sleutel er niet voor kan zorgen dat een niet-gerelateerd verzendend systeem ermee tekent. Als de provider zegt dat de huidige workflow verschilt, update dan het implementatieplan aan de hand van dat accountspecifieke bewijsmateriaal in plaats van de historische volgorde naar een nieuwe productversie te forceren. Bedenk geen Enable Signing-besturingselement dat de aangehaalde workflow niet documenteert.
De testbeschrijving van de provider biedt een nuttig DKIM controlepunt, maar dkim=pass alleen bewijst dit niet uitlijning met het zichtbare auteursdomein van de campagne. RFC 6376 , sectie 3.5 identificeert het d= ondertekeningsdomein en de s= selector van de handtekening. Leg deze waarden vast via een geautoriseerd bewijsproces en relateer ze aan de goedgekeurde configuratie. Een succesvolle handtekening die bij een andere service-identiteit hoort, is een ander resultaat.
Controleer SPF en DMARC op de daadwerkelijke route
SPF evalueert de SMTP identiteit, niet alleen het adres dat wordt weergegeven door de campagne-editor. RFC 7208 , sectie 2.4 beschrijft de MAIL VAN identiteit, terwijl paragraaf 4.6.4 limieten stelt aan geëvalueerde DNS-afhankelijke termen. Controleer het daadwerkelijke envelopdomein en het volledige beleid, inclusief geneste afhankelijkheden. Een zichtbare include-string is geen bewijs dat een ontvanger dat beleid toepast, noch een volledige beoordeling van het evaluatiebudget.
RFC 9989 , sectie 4.4 voegt afstemming toe tussen het auteurdomein en een passerende geverifieerde identiteit. Het doorgeven van uitgelijnde SPF of het doorgeven van uitgelijnde DKIM kan aan die authenticatievoorwaarde voldoen. Beweer niet dat de historische providertest van Concep elke keer sluit DMARC vereiste of dat alle domeinen in een multi-brand-account hetzelfde resultaat delen. Elke beoogde identiteit heeft zijn eigen bewijsgrens nodig.
De brede geruststelling van de bron over het niet-spambezorgen is geen garantie. Authenticatie, SMTP acceptatie, mapplaatsing en betrokkenheid zijn verschillende observaties. Een campagne zonder geregistreerde views is daarmee niet niet-geauthenticeerd of geblokkeerd gebleken. Gebruik daadwerkelijk diagnostisch bewijs en vermijd verzoeken om een brede acceptatielijst van ontvangers als vervanging voor het identificeren van de fout. Een dergelijk verzoek of test is hier niet gedaan.
Fictieve diagnose: gepubliceerde sleutel, onafgemaakte providertransitie
Een fictieve beroepsvereniging, Alder Council, ontvangt een DKIM waarde van ondersteuning en vraagt haar DNS team om deze te publiceren. De campagne-eigenaar markeert het project als voltooid zodra het wijzigingsticket sluit. Uit een latere beoordeling van de gereedheid blijkt dat er geen bevestiging is gevonden dat de accountovergang aan de providerzijde of de beschreven test heeft plaatsgevonden. Het team registreert daarom DNS publicatie als volledig bewijs binnen de fictieve zaak, maar laat de verzendgereedheid onopgelost.
De voorgestelde volgende stap is het verkrijgen van een bevestiging van de geautoriseerde provider en het inspecteren van onschadelijk berichtbewijs voor de beoogde identiteit van de afzender. Het is niet de bedoeling om de sleutel herhaaldelijk te vervangen of om aan te nemen dat alleen wachten het ondertekenen activeert. Dit voorbeeld is fictief: het vertegenwoordigt geen echt ticket, DNS observatie, accountmigratie of ontvangen bericht.
Leeg acceptatiewerkblad en vrijgavegrens
- Lopende rekening, productroute en toepasbaarheid van de gedateerde gidsen: ______
- Verzenddomein versus linkhostingdomein en bestaande afhankelijkheden: ______
- Goedgekeurde SPF -autorisatie samengevoegd tot één samenhangend beleid: ______
- Referentie voor ondersteuningsverzoek en vereiste voor domeinconfiguratie: ______
- Uitgegeven DKIM eigenaar, publieke waarde en DNS publicatiebewijs: ______
- Bevestiging van activering of transitie van provider: ______
- Geautoriseerd bericht d=, s=, envelopdomein en vertrouwde resultaten: ______
- DMARC uitlijningsbeoordeling, resterende uitzonderingen en beslissing van de eigenaar: ______
Het oorspronkelijke implementatiebewijs van de catalogus, menselijke beoordeling, toepasbaarheid van de bron, productieroutes, visuele toegankelijkheid en vrijgave door de eigenaar blijven open. De historische publieke workflow ondersteunt dit documentaireontwerp; het stelt de huidige uitvoering van de tenant niet vast en autoriseert publicatie, ondersteuningsoutreach of DNS wijzigingen niet.