Gebruik de accountconfiguratie als uitgangspunt
Sendloop biedt een accountworkflow voor authenticatie van afzender en domein, terwijl de openbare authenticatiewizard ook speciale vermeldingen vermeldt DKIM En uitlijning instellingen. Deze pagina's stellen vast dat authenticatie beschikbaar is, maar stellen niet de exacte recordset, handtekeningidentiteit of envelopcontroles voor een bepaald account vast. Deze gids neemt u mee door de gedocumenteerde accountworkflow en een gecontroleerd verificatieplan. Een speciale DKIM regeling of aangepaste envelopvereiste blijft een bevestigingspunt van de provider. Sendloop-authenticatiewizard, DKIM en instellingen voor domeinuitlijning.
Identificeer eerst het account, goedgekeurde Van-domeinen en de campagnes of automatiseringen die elk account gebruiken. Leg vast of er voor het account een speciale bezorgafspraak geldt en wie deze kan bevestigen. Leid geen specifieke infrastructuur af op basis van een prijskaartje, een oude onboarding-e-mail of een lijst met verzendende IP-adressen van derden. Wijs een Sendloop-beheerder, een DNS eigenaar en een reviewer aan voor de organisatie DMARC beleid.
Voordat u wijzigingen aanbrengt, exporteert u de huidige DNS gegevens voor de relevante eigenaren. Bewaar één door een vertegenwoordiger ontvangen bericht van de bestaande goedgekeurde route, indien beschikbaar. Een inventarisatie van wat al werkt voorkomt dat een nieuw authenticatieproject per ongeluk een andere afzender uitschakelt. Het doel is een geverifieerde en afgestemde Sendloop-route, en geen grootschalige vervanging van de e-mailconfiguratie van het domein.
Open het afzenderdomeinconfiguratiescherm
De handleiding van de provider leidt u door Instellingen > Verificatie van afzenderdomein > Verifieer afzenderdomein en vervolgens Domein toevoegen. Het resulterende Domeinconfiguratiescherm levert accountrelevante waarden en een actie DNS records controleren. Leg die uitvoer vast voordat DNS bewerkt. Als de huidige interface verschilt, gebruik dan de instructies of ondersteuning van de huidige provider in plaats van gelijkwaardige knoppen te raden. Handleiding voor Sendloop, de wizard E-mailautorisatie gebruiken en uw authenticatie-instellingen controleren.
Leg elke volledige eigenaar, DNS type, waarde en TTL vast met het doel ervan. Bewaar de weergegeven recordset bij het wijzigingsticket. Als het paneel een ontbrekend record vertoont, bepaal dan of dit ontbreekt, bij de verkeerde eigenaar is gepubliceerd of met een andere waarde aanwezig is. Een domein dat al is geconfigureerd voor een ander Sendloop-account heeft mogelijk providercoördinatie nodig in plaats van vervanging.
De openbare gids heeft een SPF voorbeeld en een wijziging in bestaande records die niet identiek zijn, bevatten. Het beschrijft ook het voorbereiden van tekstbestanden. Maak van geen van beide details een automatisch productierecept. DNS moet het huidige, toepasselijke beleid bevatten; een tekstbestand dat op een werkstation is opgeslagen, publiceert het niet. Los vóór de implementatie eventuele verschillen op tussen het accountpaneel en de openbare pagina. Sendloop-gids, Stel de SPF record in.
Controleer SPF zonder niet-gerelateerde machtigingen uit te breiden
Bepaal welk envelopdomein het echte Sendloop-bericht gebruikt. Dat is de identiteit die voor SPF moet worden onderzocht, in plaats van aan te nemen dat het zichtbare Van-domein de evaluatie-eigenaar moet zijn. Als er een geautoriseerde aangepaste enveloparrangement bestaat, leg dan de uitgegeven instellingen en reikwijdte ervan vast. Als dit niet het geval is, noteert u de waargenomen envelopidentiteit van de provider en evalueert u DKIM uitlijning afzonderlijk.
Wanneer u van eigenaar verandert, dient u één SPF beleid te behouden en de autorisaties te behouden die vereist zijn door andere actieve afzenders. Controleer geneste DNS zoekopdrachten voordat u nieuwe termen toevoegt. De limiet van tien termijnen van SPF is van toepassing op mechanismen en modifiers die tijdens de evaluatie DNS lookups veroorzaken, niet op het aantal zichtbare woorden in het record. Bestaande permissieve mechanismen zijn ook de moeite waard om te herzien, maar het verwijderen ervan is een afzonderlijke afhankelijkheidsbeslissing. RFC 7208 , secties 4.5 en 4.6.4.
Kopieer geen breed voorbeeldbeleid ter vervanging van de bestaande record. Als u dit wel doet, kunnen ongewenste hosts worden geautoriseerd, de foutkwalificatie worden gewijzigd of een andere provider worden verwijderd. Wanneer de vereiste autorisatie niet veilig past, stop dan en vraag de posteigenaar om een ondersteund ontwerp te kiezen. Los het probleem niet op door nog een SPF -beleid te publiceren of door onbekende services te verwijderen.
Publiceer alleen het uitgegeven openbare DKIM materiaal
Gebruik de eigenaar en de openbare waarde die voor dit account zijn opgegeven. De openbare gids toont een DKIM TXT opstelling, maar de demonstratiesleutel is niet de sleutel van de klant. Als het panel of de ondersteuning een ander ondersteund registratieformulier levert, bewaar dan die instructie in plaats van deze zonder bewijs om te zetten. Sendloop-gids, Stel het DKIM record in.
Alleen de publieke verificatiesleutel hoort thuis in DNS . DKIM creëert een cryptografische handtekening met een privésleutel; het integreert de privésleutel niet in het uitgaande bericht. De informele uitleg van de openbare gids mag niet worden gelezen als een verzoek om ondertekeningsgeheimen te delen. Het bericht is voorzien van een handtekening en de verificateur gebruikt de openbare sleutel die wordt geïdentificeerd door het ondertekeningsdomein en keuzeschakelaar. RFC 6376 , secties 3.5 en 6.1.
Controleer de voorgestelde eigenaar op een actieve sleutel die bij een andere route hoort. Een botsing vereist coördinatie; het is niet veilig om een werkende selector te overschrijven alleen maar om een rode status te wissen. Controleer de volledig gekwalificeerde naam na publicatie, inclusief het domeinachtervoegsel dat door de DNS editor is toegevoegd. Bewaar tijdstempels en queryresultaten, zodat latere rapporten een verouderde cache kunnen onderscheiden van een onjuiste eigenaar of sleutel.
Houd linkbranding buiten de conclusie van de afstemming
De handleiding van de aanbieder beschrijft een optioneel CNAME voor aliasberichtlinks. Het doel ervan is linkbranding, en niet het bewijs dat SPF of DKIM op één lijn liggen. Implementeer dit alleen als de relevante trackingwijziging is goedgekeurd en het account het exacte doel oplevert. Sendloop-gids, OPTIONEEL: Stel de CNAME record in.
Controleer de bestaande website of volg het gebruik voordat u de voorgestelde eigenaar claimt. Wijs de hoofdwebsite of de hostnaam van een live applicatie niet naar een trackingdoel. Bewaar een onschadelijke testlink in de gecontroleerde campagne, zodat de recensent zowel de bestemming als de weergegeven hostnaam kan verifiëren. Authenticatie en linkfunctie zijn afzonderlijke acceptatiecontroles; een merklink die werkt, vormt geen geldige handtekening.
Keer na publicatie terug naar de DNS controle van het account. Vergelijk elk weergegeven resultaat met een onafhankelijke openbare zoekopdracht. Registreer openstaande staten eerlijk. Als een account geverifieerd blijkt terwijl de externe test nog steeds mislukt, laat u de wijziging open en gebruikt u het berichtbewijs om de resterende grens te lokaliseren.
Verzamel een ontvangen berichtidentiteitsrecord
Verzend de daadwerkelijke campagneworkflow naar gecontroleerde externe mailboxen zonder dat er klantgegevens nodig zijn. Herhaal dit voor wezenlijk verschillende Van-domeinen of leveringsconfiguraties. Behoud het originele bericht en de resultaten van de vertrouwde ontvanger, samen met een bericht-ID en UTC-tijdstempel. Registreer alle DKIM handtekeningen in plaats van te stoppen bij de eerste handtekening die passeert.
Het bewijsrecord moet het zichtbare Van-domein, de geauthenticeerde envelopidentiteit, Return-Path, DKIM d= en s= waarden, SPF en DKIM -resultaten en het DMARC resultaat van de ontvanger. Bepaal welk doorgeefmechanisme aansluit bij het Van-domein. Een ontspannen en strikte afstemming legt verschillende domeinvergelijkingen op; registreer de gebruikte modus. RFC 9989 , Uitlijning van identificatie uitgelegd.
Als de enige passerende handtekening een niet-gerelateerd providerdomein gebruikt, vraag dan de ondersteunde optie voor ondertekening van het klantdomein en de bijbehorende activeringsvoorwaarden aan. De speciale DKIM-contactnotitie van de openbare wizard bewijst niet dat de optie is ingeschakeld, gratis, beschikbaar is voor elk abonnement of automatisch wordt geconfigureerd. Verkrijg die antwoorden voor het exacte account. Geef een trackingalias niet weer als alternatief envelopdomein.
Gebruik de fout om de volgende cheque te selecteren
Voor een vermissing DKIM -handtekening, bevestig het account, selecteer Van identiteit en provideractivering. Als er sprake is van een handtekeningfout, vergelijkt u de waargenomen selector en de openbare sleutel voordat u downstream-wijzigingen in ondertekende inhoud onderzoekt. Een test met een ander afzenderadres kan slagen terwijl de betreffende campagne nog steeds mislukt. Houd de workflow tijdens de diagnose dus constant.
Voor SPF fouten identificeert u het geëvalueerde domein en de uiteindelijke verzendbron. Voor SPF passage met DMARC fout, inspecteer de uitlijning in plaats van meer SPF insluitingen toe te voegen. Als de provider de vereiste identiteitsoptie niet kan documenteren, laat die vereiste dan geblokkeerd en beoordeel een ander ondersteund traject met de bedrijfseigenaar. Verlaag niet het beleid van een heel domein simpelweg om de test van één provider te laten mislukken.
Bereid een ondersteuningsbundel voor met daarin de accountidentificatie, het betrokken domein, uitgegeven openbare registers, waargenomen DNS antwoorden, bericht-ID, tijd en relevante ontvangerresultaten. Sluit wachtwoorden, API-sleutels, ontvangerslijsten en niet-gerelateerde berichtinhoud uit. Een beknopte, reproduceerbare fout is nuttiger dan meerdere niet-gecorreleerde schermafbeeldingen van DNS bewerkingen.
Werkblad herstel en acceptatie
Gebruik het Sendloop-authenticatiewerkblad (maak een afzonderlijk beoordelingsrecord met de hier beschreven velden) om de beoordeling van recordverschillen, bevestiging van specifieke functies en uiteindelijke identiteitsvergelijking bij te houden. Een antwoord op de ontbrekende envelopmogelijkheid kan expliciet onopgelost blijven, zelfs als gewone uitgelijnde DKIM werkt. Definieer acceptatie aan de hand van de zakelijke vereisten in plaats van elke lege plek op te vullen met een aanname.
Als de wijziging mislukt, onderbreekt u de getroffen verzendingen en herstelt u de eerder goedgekeurde configuratie via het vastgelegde wijzigingsplan. Coördineer DKIM wijzigingen met activering van de provider; Als u een openbare sleutel verwijdert terwijl de service er nog mee tekent, ontstaat er een nieuwe fout. Wanneer u Sendloop buiten gebruik stelt, controleer dan of alle campagnes en automatiseringen zijn gestopt en controleer de gedeelde SPF afhankelijkheden voordat u vertrouwens- of trackingrecords verwijdert.
Fictief uitgewerkt voorbeeld van een SPF discrepantie
Alleen fictieve schriftelijke casus: SLP-01 gaat ervan uit dat het bedoeld is Van offers@workshop.example . Het openbare voorbeeld bevat twee provider-includes, terwijl de bestaande beleidsinstructie er één noemt; huidige accountautorisatie, envelopidentiteit en DKIM / SPF resultaten zijn onbekend. De DNS eigenaar bewaart de wijziging en vraagt de accounteigenaar om routespecifieke bevestiging. Een tekstbestand en een merklink zorgen niet voor authenticatie. Na opheldering zou het team één beleid herzien en een gecontroleerde campagneboodschap verzamelen. Er is geen account-, DNS of verzendtest uitgevoerd.
Documentaire dekking en resterende poorten
Dit concept heeft betrekking op de workflow voor openbare accounts en veilige verificatie. Er wordt geen universele speciale DKIM of aangepaste Return-Path -installatie tot stand gebracht, en er wordt niet beweerd dat een live uitgelijnd Sendloop-bericht is geïnspecteerd. Deze accountafhankelijke details, live DNS en headerbewijs, onafhankelijke beoordeling, visuele beoordeling en menselijke MKB-goedkeuring blijven hangende. Houd de oorspronkelijke volledige implementatiescope in de wacht totdat het vereiste accountbewijs de gaten dichtt.
Scheid een voorbijgaand bericht van de gereedheid voor handhaving
RFC 9989 Sectie 7.4 vereist een geldige DKIM voor domeinpublicatie p=reject en waarschuwt voor de interoperabiliteit van indirecte post. Eén enkel afgestemd SPF resultaat rechtvaardigt op zichzelf geen uitrol van het afwijzingsbeleid. Bekijk alle legitieme routes en beleidseigendom afzonderlijk van deze providerconfiguratie.