Identificeer gehoste e-mail voordat u de standaardinstellingen wijzigt
Deze handleiding behandelt e-mail die wordt verzonden door de gehoste e-mailservers van SiteGround. Er wordt niet van uitgegaan dat SiteGround Email Marketing, een website-plug-in die een externe SMTP service gebruikt, of een elders gehoste mailbox dezelfde route volgt. Registreer de verzendende mailbox, de geselecteerde site, het domein en de gezaghebbende DNS host. Sla een basislijnbericht en een zone-export op voordat u de standaardinstellingen wijzigt.
SiteGround-documenten worden automatisch gemaakt SPF En DKIM records. De authenticatiecontroles bevinden zich onder Sitetools > E-mail > Authenticatie; DMARC wordt beheerd in de DNS Zone Editor. Een standaardinstelling in dat paneel is een startconfiguratie, geen bewijs van een afgeleverd uitgelijnd bericht. SiteGround-verificatiecontroles.
Inspecteer bestaande waarden in plaats van ze te vervangen
Open de DNS Zone Editor van het domein en inspecteer de huidige TXT records. Het recordcontroleartikel van SiteGround documenteert een standaard DKIM eigenaar. _domainkey onder uw domein. Gebruik de daadwerkelijke sleutel en hostnaam van uw eigen account. Identificeer eventuele aanpassingen en hun eigenaren voordat u een resetactie kiest. Inspecteer SPF en DKIM.
Als DNS elders wordt gehost, kopieert u de benodigde openbare records via de beheerder naar die gezaghebbende service. Vraag de naamservers gebruikt door ontvangers om publicatie te bevestigen. Migreer DNS niet louter en alleen omdat het hostingpaneel een handige editor bevat. Houd de A-records van de website en de werkende inkomende MX routering buiten het bereik van deze authenticatiewijziging.
Als SPF al andere systemen autoriseert, behoudt u hun geverifieerde machtigingen in het enige toepasselijke SPF beleid. Een reset naar de standaardhostingstandaard zou een salaris- of CRM-route stilletjes kunnen negeren. Controleer de syntaxis en de opzoekkosten na het samenvoegen, en maak onderscheid tussen het domein SPF daadwerkelijk evalueert en het zichtbare Van-domein. SPF protocol.
Beschouw DKIM regeneratie als een belangrijke verandering
De provider documenteert het deactiveren en reactiveren DKIM om opnieuw te genereren een record. Gebruik regeneratie niet als eerste diagnostische stap voor een tijdelijk toedieningsprobleem. Leg de stroom vast keuzeschakelaar en publieke sleutel, identificeer e-mail die in de wachtrij staat en plan publicatie bij de DNS eigenaar voordat u een werkende sleutel vervangt. SiteGround-besturingselementen.
Een nieuwe DNS waarde kan zich op een andere manier voortplanten tussen de solvers, dus een ogenschijnlijk onmiddellijke paneelwijziging bewijst niet dat elke ontvanger de nieuwe handtekening kan verifiëren. Gebruik een gecontroleerd bericht na de wijziging en controleer de selector in dat bericht met de openbare sleutel waarnaar het daadwerkelijk verwijst. Houd het operationele rollback-plan gescheiden van een belofte dat een oude privésleutel kan worden hersteld; bevestig die mogelijkheid eerst bij de provider.
Bouw een routespecifiek acceptatierecord op
De tabel is een synthetisch testplan. Voor deze handleiding is geen SiteGround-tenant of afgeleverd bericht geïnspecteerd.
- Route: Gehoste mailbox via normale client; Bewijs dat bewaard moet blijven: Originele headers en client SMTP doel; Acceptatiebeslissing: Bevestig de beoogde SiteGround-verzendroute
- Route: Websitemelding; Bewijs om te bewaren: Plugin-transport en ontvangerresultaten; Acceptatiebesluit: Stel vast of het daadwerkelijk die route deelt
- Route: Aparte marketingdienst; Bewijs om te bewaren: servicespecifieke instellingen en origineel bericht; Acceptatiebeslissing: neem het pass-resultaat van de mailbox niet over
- Voor elk bericht, registreer zichtbaar Van, SMTP envelopdomein, DKIM d= en s=, en de resultaten van de vertrouwde ontvanger. Een gevalideerde d=example.com -handtekening met Van user@example.com is een exact domein uitlijning voorbeeld; het is geen claim over de waargenomen output van SiteGround. Als SPF slaagt voor een ander domein, evalueer dan de uitgelijnde DKIM voordat u DMARC gebroken verklaart. DMARC uitlijning.
Herstel zonder het incident te vergroten
Wanneer records verschijnen in Site Tools maar niet in openbare DNS , onderzoek dan de autoriteit van de naamserver en de constructie van de hostnaam. Als de e-mail niet is ondertekend, bevestigt u het product en SMTP pad voordat u de sleutels wijzigt. Wanneer handtekeningverificatie mislukt, vergelijk dan de selector-lookup en een eventuele gateway voor het wijzigen van berichten. Wanneer alleen websitemail mislukt, inspecteer dan de transportconfiguratie van de website in plaats van de mailboxverificatie opnieuw in te stellen.
Als een wijziging een andere afzender verstoort, herstel dan het opgeslagen SPF of DMARC -beleid en test die afzender en de gehoste mailbox opnieuw. Bewaar de voor-en-na-gegevens, tijdstempels, goedgekeurde reikwijdte en ontvangen originelen. Controleer de standaardinstellingen na een hostingmigratie, toevoeging van een aangepast domein of DNS verhuizing. Het succes van authenticatie bepaalt niet de plaatsing in de inbox, en dit documentaire concept claimt geen live validatie.
Scheid het werkende postvak van de mislukte websiteroute
Schriftelijk geval SG-01 bepaalt een gehost e-mailbericht met From help@example.org en een vertrouwde DKIM -pas met d=example.org, s=default. Een website-plug-in verzendt in plaats daarvan via een niet-gerelateerde externe SMTP service en heeft geen verzamelde authenticatieresultaten. Het gehoste bericht levert alleen exacte DKIM uitlijning voor zijn eigen route. De website-eigenaar moet de daadwerkelijke envelop- en ondertekeningsconfiguratie van die plug-in identificeren voordat SiteGround opnieuw wordt ingesteld. Houd de mailboxsleutel en andere SPF afzenders intact. Dit zijn fictieve identiteiten en uitkomsten; er is geen tenant, plug-in, DNS query of bericht geïnspecteerd.
Behoud de handhavingsgrens
RFC 9989 Sectie 7.4 vereist geldige DKIM , en 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.