Identifiser hver vei domenet sender
Simply.com kan være vert for en postboks, et nettsted og DNS , men disse rollene får ikke alle applikasjoner som bruker domenet til å følge samme e-poststi. Begynn med en rutebeholdning: webmail, en konfigurert e-postklient, et kontaktskjema på nettsiden, en bestillingsvarsling og enhver ekstern tjeneste. Legg merke til hvor applikasjonen kjører, hvilken server den sender til og den synlige avsenderen virksomheten forventer.
Denne veiledningen dekker rutene som er nevnt i Simply.coms offentlige postdokumentasjon. Det utvider ikke leverandørens signeringsløfte til en ikke-relatert nyhetsbrevplattform, en server som er vert andre steder eller et skript som bruker en annen transport. Eksisterende kontoer trenger også inspeksjon; en dokumentert standard for nye vertsplaner er ikke bevis på at en eldre eller eksternt administrert sone har de samme postene.
Gjennomgå de dokumenterte postene uten å overskrive sonen
Simply.com sin autentiseringsguide lister opp SPF autorisasjonen include:spf.simply.com og to DKIM CNAMEs: simplycom1. _domainkey til dkim1.simply.com , og simplycom2. _domainkey til dkim2.simply.com . SPF eksemplet antar at e-post kun sendes gjennom Simply.com. Den navngir webmail, websmtp.simply.com og smtp.simply.com på port 587 som signerte ruter.
Behandle disse som dokumenterte offentlige verdier, ikke observerte poster for domenet ditt. Eksporter gjeldende sone før du gjør en autorisert endring. Identifiser den autoritative DNS leverandøren og bekreft eierformatet grensesnittet forventer. Hvis den legger til domenet automatisk, forhindre et doblet suffiks. Sammenlign det publiserte resultatet med det nødvendige fullt kvalifiserte navnet i stedet for å stole på det visuelle utseendet til et skjema.
For SPF må du lagre andre legitime tjenester før du endrer retningslinjene. RFC 7208 beskriver utvelgelsesreglene for én politikk og DNS oppslagsgrense. Gjennomgå den kombinerte evalueringen, inkludert nestede inkluderer, i stedet for å telle bare termene som er synlige på toppnivået. Behold eksisterende tjenestetillatelser med mindre eierne deres har bekreftet pensjonering.
Få nettsidepost til å bruke den tiltenkte transporten
De script-mail guide beskriver autentisert innsending til websmtp.simply.com på port 587, med STARTTLS støtte, for skript på Simply.coms webservere. Den skiller ruten fra PHP mail() og begrenser tjenesten fra bruk som en generell klient eller eksternt vertsrelé. Den advarer også mot å behandle den som en plattform med stort volum.
Sjekk hva den kjørende applikasjonen faktisk gjør. En e-postplugin kan installeres, men deaktiveres, overstyres av en annen plugin eller omgås av et bestemt skjema. Registrer søknaden, effektiv transport og ansvarlig vedlikeholder. Et vellykket varsel om tilbakestilling av passord validerer ikke nødvendigvis en handelsutvidelse som sender gjennom et annet bibliotek.
Bruk organisasjonens godkjente prosess for administrasjon av legitimasjon for senere konfigurasjoner. Ikke legg inn passord i regnearket, DNS , skjermbilder eller støtteeksempler. Dette utkastet logger ikke på, installerer plugins, endrer applikasjonsinnstillinger eller overfører legitimasjon.
Gå gjennom DMARC -retningslinjene som er vertsbasert som en egen avgjørelse
Simply.com dokumenterer en standard _dmarc CNAME til dmarc.simply.com og beskriver avvisning som standardpolicy. Inspiser den nåværende eieren og dens effektive svar før du bestemmer deg for om organisasjonen skal beholde leverandørstyrt policy eller administrere sin egen. En eksternt vert sone kan variere, og en eksisterende tilpasset policy kan inkludere rapportering eller justering innstillinger virksomheten trenger.
Ikke legg til en TXT post ved siden av en eksisterende CNAME hos samme eier. Hvis en godkjent endring erstatter aliaset, registrerer du det gamle svaret, den tiltenkte nye policyen, rapporteringsdestinasjonen og gjenopprettingsprosedyren. Bekreft rapporteringsmottakeren og eventuell nødvendig autorisasjon før du sender rapporter til en ny destinasjon. Dette er domenepolicyarbeid, ikke en nødvendig bieffekt av å sjekke to signeringsposter.
DKIM autentiserer ansvar ved et signeringsdomene, ikke identiteten eller autoriteten til den individuelle menneskelige forfatteren. Leverandørforklaringer komprimerer noen ganger policy og levering til enkle løfter. Bruk RFC 9989 for protokolltolkningen: justering er viktig, og mottakerhåndtering er ikke en garanti for at hver legitim melding når en innboks eller at hver phishing meldingen forsvinner. Behold autentiseringsgodkjenning og mottakerplassering som separate tiltak.
Bekreft begge velgerne og den aktive signaturen
En leverandør kan publisere mer enn én velger av driftsmessige årsaker. Bekreft at begge de dokumenterte CNAME-ene eksisterer som forventet, uten å anta hvilken en bestemt melding må bruke. Fra en kontrollert mottatt melding, fange opp hvert DKIM signeringsdomene og -velger. RFC 6376 definerer hvordan disse feltene identifiserer bekreftelsesnøkkelen.
Hvis en signatur mislykkes, separat DNS oppløsning, uventet signeringsidentitet og meldingsendring. Hvis ingen forventet signatur vises, undersøk innsendingsruten før du bytter ut nøkler. Et skjema som bruker en utilsiktet transport vil ikke bli den dokumenterte signerte banen bare fordi domenet har gyldige CNAME-er.
Fang den konvoluttavsender også. De gjennomgåtte Simply.com-kildene etablerer ikke en universell brukerkonfigurerbar tilpasset Return-Path trekk. Ikke utlede en fra en postboksadresse eller en svardestinasjon. Registrer den observerte identiteten og mekanismen som gir justering.
Behold videresendte meldinger i en annen testgruppe
Simply.com sine videresendingsguide advarer om at ekstern videresending kan være upålitelig fordi den videre banen kan påvirke SPF eller DKIM . En videresendt melding kan derfor ikke brukes som den eneste testen av den opprinnelige utgående ruten.
Test først direkte levering fra webmail og applikasjonsstiene. Hvis videresending er et forretningskrav, legg det til som en egen rad med både originale og endelige mottakerobservasjoner. Undersøk om den aktuelle signaturen overlever og hvilken identitet den endelige mottakeren vurderer. Ikke utvide den opprinnelige avsenderens SPF tillatelser ganske enkelt fordi en senere videresending endrer avsenderserveren.
Bruk arbeidsarket for rutedekning
Simply.com-postboksen og arbeidsarket (opprett en egen gjennomgangspost med feltene beskrevet her) inkluderer en rad for hver transport, den effektive DNS policyen, gjeldende signeringsvelgere og de endelige mottakerresultatene. Hold kontrollerte meldingsidentifikatorer og observasjonstider med DNS beviset. Registrer et eget resultat for hver applikasjon i stedet for å skrive "nettstedspost bestått" etter en prøve.
En rute er klar for godkjenning når bedriftseieren gjenkjenner avsender- og svaratferden, e-postadministratoren kan identifisere den justerte overføringsmekanismen, og gjenopprettingseieren kan forklare hvordan den spesifikke endringen kan reverseres. Uobserverte felt forblir ventende.
Fiktiv diagnostisk sak som involverer et kontaktskjema
Kun fiktiv skriftlig sak: SCOM-01 fastsetter webmail Fra help@repair.example med bestått d=repair.example. Kontaktskjemaet har til hensikt det samme From, men kjører PHP mail() i stedet for den dokumenterte autentiserte skriptinnsendingsruten; DKIM og SPF resultatene er ukjente. Applikasjonsvedlikeholderen må inspisere den effektive transporten, foreslå en støttet rettelse og teste skjemaet separat. Bestillingsvarsler forblir en tredje uprøvd rute. Ingen applikasjonsinnstillinger, legitimasjon, DNS eller meldinger ble åpnet.
Gjenopprett og vedlikehold rutespesifikke bevis
Før en utrulling, bevar de tidligere DNS og applikasjonsinnstillingene og avtal hvem som kan gjenopprette dem. Hvis et endret skjema mister e-post, stans denne programendringen i stedet for å svekke domenepolicyen for hver avsender. Unngå å slette en velger mens eksisterende meldinger eller en annen konfigurert rute fortsatt kan bruke den.
Test på nytt etter vertsflytting, endringer i e-postplugin, SMTP endringer, nye eksterne avsendere og endringer i DMARC-policy. Dette er et upublisert dokumentarutkast. Kontoinspeksjon, live DNS , bevis for mottatt melding, aksept av originalomfang, visuell gjennomgang og avmelding av SMB-er forblir under behandling.
Skille en bestått melding fra håndhevingsberedskap
RFC 9989 Seksjon 7.4 krever gyldig DKIM for et domene som publiserer p=reject og advarer om interoperabilitet med indirekte e-post. Et enkelt justert SPF resultat rettferdiggjør ikke i seg selv en utrulling av avvisningspolicy. Gå gjennom alle legitime ruter og policyeierskap separat fra dette leverandøroppsettet.