Kies een afzenderdomein met een expliciete grens
Copernica documenteert afzenderdomeinen als een verplicht onderdeel van de verzendconfiguratie. De korte handleiding maakt gebruik van Marketing Suite om een mailingdomein te selecteren en een gegenereerde lijst met DNS records te verkrijgen. Begin met de exacte account- en mailroute, en niet met een algemene lijst met records die aan de naam van de leverancier zijn gekoppeld. In de documentatie wordt ook uitgelegd dat de afzender-domeininstellingen van Marketing Suite voorrang krijgen wanneer Publisher wordt gebruikt, zodat het team moet bepalen welke configuratie de beoogde e-mail regelt.
Bepaal of de route het hoofddomein van de organisatie of een speciaal subdomein zal gebruiken. De geavanceerde gids voor het afzenderdomein bespreekt beide keuzes en benadrukt de extra zorg die nodig is rond de bestaande hoofddomeininstellingen. Een subdomein kan de overlap met de bestaande infrastructuur verminderen, maar is niet automatisch ongebruikt, risicovrij of vrijgesteld van overgenomen beleid. Controleer bestaande afhankelijkheden voordat u deze als een schone grens behandelt. Snelle afzender-domeingids; Afzenderdomeinen
Lees het gegenereerde DNS -plan per functie
Wanneer een afzenderdomein wordt aangemaakt, documenteert Copernica het genereren van records op de infrastructuur en het vermelden van de vereiste DNS configuratie aan de klantzijde in Marketing Suite. De gids beschrijft functies zoals het volgen van klikken en openen, het afhandelen van bounces, DKIM handtekeningen, SPF toestemming en DMARC rapportage. Dit zijn verschillende afhankelijkheden, zelfs als de interface ze samen presenteert.
Bewaar voor elk voorgesteld record de naam van de eigenaar, het type, het doel of de waarde, en de beoogde functie ervan. Bepaal welke waarden aliassen zijn voor door de provider beheerde records en welke TXT beleidsinhoud zijn. Concludeer niet dat elke vermelde functie een identiek recordtype gebruikt. De afzonderlijke SPF documentatie is belangrijk omdat deze een TXT -insluitingsmechanisme beschrijft in plaats van SPF te behandelen als slechts een verwisselbare alias.
Vermijd het kopiëren van waarden uit een ander afzenderdomein of account. Het gegenereerde plan moet gekoppeld blijven aan het bronaccount en de beoordelingsdatum. De openbare documentatie ondersteunt de workflow, maar is geen vervanging voor het specifieke plan dat de organisatie daadwerkelijk zal autoriseren. De DNS records; SPF
Begrijp de door de provider beheerde afhankelijkheid
Copernica legt uit dat aliassen aan de klantzijde verwijzen naar records die het beheert, waardoor wijzigingen aan de providerzijde, zoals DKIM rotatie of updates van de verzendinfrastructuur, mogelijk zijn zonder dat elke klant de bijbehorende alias hoeft te wijzigen. Dit is een afhankelijkheidsmodel, geen overdracht van controle over de hele klantenzone. Registreer precies welke DNS namen afhankelijk zijn van de provider en wie eigenaar is van hun levenscyclus.
Het praktische voordeel brengt een voortdurende verantwoordelijkheid met zich mee: inventariseer de aliassen, behoud de accountrelatie en controleer deze wanneer de service wordt vervangen of het verzendende domein buiten gebruik wordt gesteld. Verwijder een DKIM alias niet uitsluitend omdat een campagne is onderbroken; actieve routes of e-mail in de wachtrij kunnen nog steeds afhankelijk zijn van de configuratie. Omgekeerd moet u de afhankelijkheden van leveranciers niet voor onbepaalde tijd onbeheerd laten na het offboarden.
Een door de leverancier beheerd doel garandeert niet dat elke toekomstige DNS status correct blijft. Monitoring, wijzigingsbeoordeling en een gedocumenteerd pensioenplan zijn nog steeds organisatorische verantwoordelijkheden. Dit manuscript stelt deze controles voor zonder te beweren dat de gegevens van een klant zijn geïnspecteerd of gewijzigd. Door de provider beheerde DNS uitleg
Plaats SPF op de juiste identiteit
In de SPF documentatie wordt onderscheid gemaakt tussen het door Copernica gebruikte bounce-subdomein en het hoofddomein van de organisatie. Het beschrijft het gebruik van een include in een TXT SPF beleid voor de relevante configuratie. Voeg een verondersteld Copernica-mechanisme niet automatisch samen met het hoofddomein, simpelweg omdat het zichtbare Van-adres dat domein gebruikt. Identificeer eerst de daadwerkelijke envelop-identiteit en het door het account uitgegeven DNS plan.
SPF evalueert SMTP identiteiten volgens zijn eigen regels. Een include-mechanisme roept tijdens de evaluatie een ander SPF -beleid op; A CNAME is een DNS alias. Het zijn niet dezelfde protocolbewerkingen, ook al creëren beide een externe afhankelijkheid. Het onderscheid is van belang voor het oplossen van problemen, het naast elkaar bestaan van records en de evaluatielimieten SPF .
Als er al een beleid bestaat onder de relevante naam van de eigenaar, bekijk het dan als één volledig beleid in plaats van een tweede concurrerend beleid toe te voegen SPF record. Bewaar andere geautoriseerde bronnen en evalueer de toepasselijke DNS-afhankelijke voorwaarden. De bewaarde providerpagina bevat illustratieve namen, dus gebruik daadwerkelijk gegenereerde waarden in plaats van een kopieerbare configuratie af te leiden uit een voorbeeld. Copernica SPF; RFC 7208 , sectie 2.4; RFC 7208 , sectie 3.2; RFC 7208 , sectie 4.6.4
Controleer DMARC voordat u een gebundelde wijziging accepteert
De geavanceerde gids vestigt specifiek de aandacht op mogelijke DMARC conflicten wanneer een hoofddomein al over een e-mailinfrastructuur beschikt. Behandel een bestaand DMARC beleid en rapportageregeling als een organisatiebrede afhankelijkheid. Een nieuw afzenderdomeinpakket mag gevestigde rapportagebestemmingen niet stilletjes vervangen of het beleid voor niet-verwante afzenders wijzigen.
De voorgestelde herziening is om het beoogde zichtbare Van-domein, het verwachte ondertekeningsdomein en de envelopidentiteit te vergelijken met de toepasselijke uitlijning instellingen. Een door de provider beheerde sleutel kan succesvol worden gevalideerd, terwijl een Van-domein met een andere merknaam niet op één lijn ligt. Evenzo bewijst een werkend DKIM pad niet dat een nieuw geïntroduceerd SPF pad op de juiste eigenaarnaam is geconfigureerd.
Als het gegenereerde plan en het bestaande beleid niet veilig op elkaar kunnen worden afgestemd, kunt u de wijziging bewaren zodat de domeineigenaar en de provider dit kunnen verduidelijken. Los het conflict niet op door het beleid te verzwakken zonder een goedgekeurd besluit. Authenticatieresultaten bevestigen ook niet de legitimiteit van het bericht, de toestemming van de ontvanger of een gegarandeerde bezorging. Subdomein of het hoofddomein?; RFC 9989 , sectie 4.4
Acceptatiewerkblad voor het beheerde afzenderdomein
Gebruik dit voorgestelde werkblad om de gegenereerde configuratie gedurende de hele levenscyclus verantwoordelijk te houden.
- Reikwijdte: identificeer het Marketing Suite-account, de uitgeversafhankelijkheid indien relevant, het afzenderdomein en de mailingcategorieën.
- Bestaand gebruik: registreer huidige DNS eigenaren, actieve e-mailroutes en eventueel gedeeld domeinbeleid voordat u wijzigingen voorstelt.
- Gegenereerd plan: bewaar elk exact record met zijn functie, accountkoppeling en door de provider beheerde afhankelijkheid.
- SPF identiteit: leg onder die naam het beoogde envelop- of bouncedomein en de volledige beleidsreview vast.
- DMARC compatibiliteit: identificeer de bestaande beleidseigenaar, rapporteer afhankelijkheden en uitlijningsaannames.
- Verificatie: behoud de providerstatus afzonderlijk van gezaghebbend DNS bewijs en een geautoriseerd voorbeeld van ontvangen berichten.
- Pensioen: noem de service-eigenaar die verantwoordelijk is voor de beoordeling van in de wachtrij geplaatste e-mail, het verwijderen van alias en de validatie na offboarding.
Dit werkblad is een origineel operationeel voorstel. Het is geen uitgevoerde DNS inspectie, een voltooide afzender-domeinconfiguratie of bewijs dat een gegenereerd record is geaccepteerd.
Fictieve diagnose: een fundamentele beleidsverandering die niet hielp
Een fictieve detailhandelaar maakt een afzenderdomein voor een nieuwsbrief aan in Marketing Suite. De DNS beheerder ziet een SPF referentie in de documentatie en stelt voor om het hoofddomein te wijzigen, hoewel het gegenereerde plan een afzonderlijk bounce-subdomein identificeert. Ondertussen ondersteunt het hoofddomein al verschillende niet-gerelateerde bedrijfsapplicaties.
De recensent pauzeert de rootwijziging en wijst elk gegenereerd record toe aan zijn functie. Het voorgestelde onderzoek controleert de daadwerkelijke identiteit van de envelop en het relevante TXT beleid in plaats van het zichtbare Van-adres te behandelen als de SPF opzoeknaam. Het behoudt ook de bestaande DMARC -rapportageregeling terwijl de uitlijning van de nieuwe route wordt beoordeeld. Het team heeft niet alleen succes bewezen door het plan te corrigeren; het heeft nog steeds geautoriseerde publicatie en berichtbewijs nodig. Dit fictieve voorbeeld illustreert een grensfout en rapporteert niet over een echt Copernica-incident.