Scope- en providerspecifieke configuratie
StatusHub heeft documentatie voor verschillende routes van mailproviders. Deze gids volgt de afzender van de e-mail - Postmark - Nieuw artikel; het bewaarde oudere Mailgun artikel mag niet in die opstelling worden gemengd. Controleer of uw Hub de overeenkomende route weergeeft voordat u deze publiceert. Voor een migratie of oudere tenant kunnen andere records nodig zijn.
Open Hub Config, Meldingsinstellingen, E-mailafzender. De gedocumenteerde standaardwaarde is do-not-reply@statushub.io . Voer de beoogde aangepaste afzender in en laat de pagina vernieuwen om de DNS instructies weer te geven. Voor de Postmark is een DKIM TXT record en een retourpad CNAME. Kopieer de naam en waarde rechtstreeks vanuit het configuratiescherm, in plaats van de voorbeeldopenbare sleutel in het Help-artikel te gebruiken.
De retourpad eigenaar is doorgaans een pm-bounces-subdomein, maar de daadwerkelijk aangevraagde naam bepaalt. Plaats deze CNAME nooit op de top van het domein alleen maar omdat dat het domein is in het zichtbare Van-adres. StatusHub waarschuwt specifiek dat een top- CNAME in conflict kan komen met andere records en niet-gerelateerde systemen, inclusief inkomende e-mail, kan schaden. Postbus bewaren MX records gescheiden van deze retourpaddelegatie.
Nadat u beide records heeft gepubliceerd, gebruikt u DNS records opnieuw controleren in StatusHub. Een volledig geverifieerd aangepast verzenddomein staat het opgegeven Van-adres toe. Wanneer een aangepaste afzender niet geverifieerd blijft, kunnen StatusHub-documenten terugvallen op do-not-reply@statushub.io in From terwijl het aangepaste adres in Reply-To wordt geplaatst. Dat onderscheid is handig tijdens de diagnose: een antwoord dat uw team bereikt, bewijst niet dat klanten uw merkafzender hebben gezien.
In het Help-artikel worden ontsnapte en niet-geëscapede puntkomma's voor DKIM TXT waarden besproken. Pas de syntaxis toe die nodig is voor de DNS editor en inspecteer vervolgens de gepubliceerde waarde; plaats geen backslashes in de sleutel als algemene oplossing. Een nieuw record kan snel worden gevalideerd, maar in het artikel worden verschillen tussen providers en TTL vermeld. Stel een diagnose van de exacte eigenaar, het type en de waarde voordat u alle fouten aan de verspreiding toeschrijft.
De beslissing die ertoe doet
Bevestig zowel de actieve mailproviderroute als of fallback de aangepaste identiteit naar Reply-To heeft verplaatst.
Controleer de gepubliceerde records en het echte verzendpad
Registreer de eigenaar van de wijziging, het verzendende product, het domein, de goedgekeurde onderhoudsperiode en eerdere DNS antwoorden voordat u deze bewerkt. Haal de huidige recordwaarden op uit de benoemde account of gedocumenteerde providerworkflow. Scheid waarden die door de provider worden geleverd, van keuzes die uw organisatie beheert, zoals DMARC beleids- en rapportageontvangers. Bestaande mailbox MX , niet-gerelateerde verificatie- TXT records en actieve DKIM selectors zijn geen opschoonkandidaten alleen maar omdat er een nieuwe service wordt toegevoegd.
Vraag na publicatie de gezaghebbende naamservers op voor elke exacte eigenaar en recordtype. Registreer de vraagtijd, de reagerende server en het volledige antwoord. Vergelijk TXT tekenreeksen als één logische waarde, waarbij het DNS antwoord ze opsplitst in tekenreeksen. Controleer CNAME doelen en de startalias. Vergelijk vervolgens een recursief-resolver-antwoord om caching-verschillen te identificeren. Een succesvolle providervalidatie is een nuttig bewijs van de configuratie, maar stelt niet vast wat een daadwerkelijke ontvanger heeft ontvangen.
Stuur alleen een geautoriseerde test naar een gecontroleerde ontvanger via de beoogde productroute. Bewaar het onbewerkte bericht en het vertrouwde ontvangende systeem Authentication-Results. Registreer het zichtbare Van-domein, SMTP MAIL VAN of waargenomen Return-Path domein, elke DKIM d= en s= waarde, SPF en DKIM resultaten, en het DMARC resultaat van de ontvanger. Een passerende SPF of DKIM controle ondersteunt DMARC alleen als het geverifieerde domein overeenkomt met het zichtbare Van-domein onder het toepasselijke beleid. Reply-To en een merkweergavenaam zijn dat niet uitlijning identiteiten. RFC 7208 , RFC 6376 en RFC 9989 bieden de protocolbasis voor dit onderscheid.
Acceptatiewerkblad, herstel- en bewijslimieten
Dit is een origineel acceptatiewerkblad, geen rapport van live testen. Markeer elke poort die in behandeling is totdat er bewijs is: accountomvang bevestigd; vorige DNS vastgelegd; exacte nieuwe eigenaar/type/waarde gepubliceerd; providerverificatie voltooid; voorgenomen route uitgeoefend; ontvangen identiteiten geregistreerd; uitgelijnde authenticatie bevestigd; andere afzenders blijven onaangetast. Wijs aan elke poort een persoons- en bewijsdossier toe. Een rode poort blokkeert de uitrol, zelfs als het providerdashboard groen is.
Als een test mislukt, maak dan eerst onderscheid tussen ontbrekende publicatie, verouderde gegevens in de cache, inactieve providerconfiguratie, verkeerde uitgaande route en niet-uitgelijnde authenticatie. Corrigeer het kleinste aangetoonde defect en test opnieuw. Verzwak DMARC niet en verwijder de gegevens van andere afzenders niet alleen maar om één test te laten slagen. Als een wijziging bestaande e-mail schaadt, gebruik dan het goedgekeurde herstelplan en de vastgelegde configuratie van vóór de wijziging, waarbij u eventuele wijzigingen aan de providerzijde van de afzender en DNS coördineert. Bewaar oude sleutels terwijl berichten in de wachtrij of een goedgekeurde overlap deze nog steeds nodig hebben.
Er was geen klanttenant, gezaghebbend voor/na wijziging of echt ontvangen bericht beschikbaar voor dit manuscript. De bewaarde bronnen ondersteunen de documentaire workflow; ze voldoen niet aan de opdracht voor live-bewijspoort. Onafhankelijke controle door een controleur en goedkeuring door menselijke MKB-bedrijven blijven in behandeling. Beschrijf deze handleiding niet als in het veld gevalideerd en publiceer hem niet als zijnde door deze poorten heen.
Interpreteer terugval als een ander identiteitsresultaat
In de schriftelijke casus SH-01 wordt ervan uitgegaan dat de beoogde afzender status@example.com is, maar het Postmark-routedomein blijft niet geverifieerd. De illustratieve melding gebruikt daarom de gedocumenteerde standaardwaarden From do-not-reply@statushub.io en Reply-To status@example.com . Alle SPF / DKIM resultaten zijn onbekend. Een antwoord dat het aangepaste adres bereikt, zou geen aangepast Van-gebruik of afgestemde authenticatie voor example.com tot stand brengen. De Hub-eigenaar moet de actieve providerroute verifiëren, de nauwkeurig gegenereerde DKIM en Return-Path -eigenaren corrigeren, de status opnieuw controleren en een gecontroleerde melding inspecteren. Verplaats de Return-Path CNAME niet naar de root en importeer geen oude Mailgun instructies. Er heeft zich geen incident, kennisgeving aan de abonnee, DNS query of configuratiewijziging voorgedaan.
Behoud de handhavingsgrens
RFC 9989 Sectie 7.4 vereist geldige DKIM , niet alleen SPF , voor het publiceren van domeinen p=reject, en waarschuwt voor de interoperabiliteit van indirecte e-mail en mailinglijsten. Eén enkele succesvolle test met directe berichten is geen bewijs dat elke legitieme route klaar is voor krachtiger beleid. Behoud de bestaande goedgekeurde bescherming terwijl u de feitelijke kloof diagnosticeert; elke beleidsverandering heeft zijn eigen beslissing nodig.