Bekræft Centercode-afsendelsesarrangementet
Centercodes officielle teknisk informationsvejledning mærker sine instruktioner som gældende for alle udgaver. Det står der SPF autorisation er obligatorisk for platformen til at sende på vegne af en kundes e-mail-domæne, mens DKIM er valgfri og tilgængelig på forespørgsel. Bevar denne sondring: Udbyderens valgfrie DKIM workflow fjerner ikke noget separat organisatorisk eller modtagerkrav. Dette manuskript beskriver den dokumenterede servicerute, ikke en observeret lejerkonfiguration eller en gennemført implementering.
Start med at identificere Centercode-implementeringen, domænet beregnet til udgående meddelelser og den ansvarlige domæneejer. Antag ikke, at fællesskabswebstedets værtsnavn, synlig e-mailadresse og faktiske konvolutafsender er identiske. En applikation kan bruge en mærkevareadresse, mens den transmitterer gennem infrastruktur kontrolleret af en anden organisation. Acceptregistreringen skal identificere, hvilket domæne hvert stykke autentificering er beregnet til at dække, før nogen redigerer DNS .
Den offentlige vejledning viser ikke en udgivelsesdato for de tekniske instruktioner i den bevarede artikeltekst. Dets anvendelighed på den løbende konto og infrastruktur forbliver derfor en frigivelsesbetingelse. Bekræft de aktuelle instruktioner med en autoriseret operatør, især hvor en implementering har flyttet infrastruktur eller har arvet indstillinger fra et tidligere fællesskab. Hverken en sidefodsdato eller en gammel succesfuld kampagne fastslår den nuværende tekniske kompatibilitet.
Vælg den dokumenterede SPF godkendelsesmodel bevidst
Udbyderens standardeksempel indeholder include:_spf.centercode.com. Den tilbyder også en smallere model, der bruger en tjenestespecifik IP-adresse eller et område, der er hentet fra support. Disse er forskellige vedligeholdelsesvalg. Den brede omfatter følger udbyderens offentliggjorte godkendelsesafhængighed; en supportudstedt adresse begrænser tilladelsen til den identificerede infrastruktur, men kræver opmærksomhed, når denne infrastruktur ændres. Vejledningen advarer eksplicit om, at en infrastrukturopgradering kan kræve opdatering af den autoriserede adresse. Centercode teknisk information
Udled ikke en implementerings dedikerede adresser fra udbyderens websted, community-URL eller indgående MX poster. Få de faktiske autoriserede værdier gennem den dokumenterede supportproces, når denne model er påkrævet. Denne artikel anmoder ikke om adresser, kontakt support eller offentliggørelse af en gættet IP. En beslutning om at bruge den smallere model bør omfatte en ejer for ændringsmeddelelser og en rekord af den implementering, som de oplyste adresser gælder for.
Før du godkender en af modellerne, skal du opgøre domænets eksisterende legitime afsendere. Centercodes illustrative politik er ikke en fuldstændig erstatning for en virksomheds produktionspolitik. Bevar de nødvendige autorisationer, evaluer bestillings- og terminalkvalifikationen, og dokumenter den nøjagtige ændring. En tjeneste tilføjet til en domænedækkende politik kan påvirke en anden gruppe af meddelelser, end kampagneejeren oprindeligt forventer.
Anvend SPF -protokolregler i stedet for at kopiere et helt eksempel
RFC 7208 , afsnit 3.2 forbyder flere poster, der får SPF til at vælge mere end én politik. Slå den godkendte mekanisme sammen til én sammenhængende TXT politik hos den relevante ejer i stedet for at tilføje en anden konkurrerende politik. Udbyderens eksempel inkluderer også mx og en soft-fail slutning; deres tilstedeværelse i et eksempel fastslår ikke, at begge er passende for alle eksisterende domæner. Bevar politikejerens beslutninger i stedet for at ændre ikke-relateret adfærd som en bivirkning.
Afsnit 4.6.4 begrænser evaluerede DNS-afhængige SPF termer, herunder indlejret evaluering. Det er ikke blot en optælling af synlige inkluderer strenge, DNS pakker eller cache-misser. Tilføjelse af Centercode include kræver gennemgang af de gældende stier gennem hele politikken. En supportudstedt ip4- eller ip6-mekanisme har forskellig opslagsadfærd, men valg af den skaber stadig den vedligeholdelsesafhængighed, der er beskrevet ovenfor. Et lavere opslagstal er ikke nok til at retfærdiggøre kopiering af ubekræftede adresser.
SPF evaluerer identiteter defineret af SMTP transaktionen. RFC 7208 , afsnit 2.4 beskriver MAIL FRA, herunder særlig håndtering af en tom omvendt vej. En post på det synlige From-domæne er ikke et bevis på, at en bestemt meddelelse bruger dette domæne til SPF evaluering. Registrer den faktiske kuvertidentitet under en særskilt godkendt acceptøvelse, og sammenlign den med den politik, der gennemgås.
Anmod om det implementeringsspecifikke DKIM materiale
Centercodes dokumenterede DKIM rute starter med en supportanmodning fra implementeringens chat eller den angivne supportkanal. Dets it-team returnerer en offentlig nøgle til kundens DNS administrator. Vejledningen beskriver en cc. _domainkey ejer under kundens domæne og en DKIM TXT værdi bygget ud fra den leverede offentlige nøgle. Brug de implementeringsspecifikke instruktioner og det nøjagtige tilsigtede domæne; kopier ikke vejledningens pladsholderdomæne eller fremstille nøglemateriale. Anmoder om DKIM support
En offentlig bekræftelsesnøgle er ikke den private signaturnøgle. Denne arbejdsgang kræver ikke, at kunden indhenter eller distribuerer udbyderens private signeringsmateriale. Hold den modtagne offentlige nøgle, ejernavn og kontoreference sammen, så en DNS anmelder kan skelne en anmodet konfiguration fra en ikke-relateret nøgle, der allerede er i zonen. Hvis en eksisterende vælger ejer er i konflikt med den foreslåede værdi, stop for en koordineret overgang i stedet for at overskrive den uden at vurdere aktiv brug.
Vejledningen fastlægger, hvordan man anmoder om og offentliggør det leverede materiale, men den beviser ikke, at signering er blevet aktiveret for en bestemt konto. Registrer enhver bekræftelse af fuldførelse af udbyder separat fra DNS ændringen. RFC 6376 , afsnit 3.5 definerer signaturens domæne- og vælgerfelter. Disse felter i en godkendt prøve af modtaget meddelelse identificerer, hvilken nøgle meddelelsen rent faktisk bruger; en offentliggjort nøgle alene viser ikke, at en underskriver brugte den.
Hold DMARC og leveringsaccept adskilt
Centercode-guiden tildeler DMARC til kundens domæneejer. Gennemgå platformsruten sammen med organisationens andre afsendere, før du ændrer politik. En supportanmodning for en DKIM nøgle godkender ikke nye rapporteringsdestinationer eller en domæneomspændende håndhævelsesændring. Opbevar disse beslutninger hos den relevante ejer og dokumenter deres omfang uafhængigt.
RFC 9989 , afsnit 4.4 forklarer, at DMARC kræver forholdet mellem det synlige forfatterdomæne og en passerende autentificeret identifikator. Et bestået justeret SPF resultat eller et bestået justeret DKIM resultat kan opfylde denne godkendelsesbetingelse. Oversæt ikke Centercodes obligatoriske SPF krav til en protokolpåstand om, at DMARC universelt har brug for begge mekanismer for at bestå. Ligeledes etablerer en ikke-relateret udbydersignatur ikke justering med kundens domæne.
Udbyderen foreslår et offentligt SPF opslag som én kontrol. Det kan hjælpe med at etablere offentliggørelse, men det kan ikke etablere egentlig signering, modtageraccept eller indbakkeplacering. En komplet foreslået acceptgennemgang adskiller offentlig DNS , udbyderkonfiguration og betroede modtagerobservationer. Brug harmløst testindhold i stedet for deltagerfeedback, fortrolige produktbeskrivelser eller fællesskabsmedlemsdata. Ingen ekstern checker-indsendelse, forespørgsel eller besked blev udført for denne vejledning.
Fiktiv diagnose og blankt acceptark
Et fiktivt hardwareteam, Harbor Finch, bruger en supportudstedt adresse til sin Centercode-implementering. Efter en planlagt infrastrukturflytning beholder teamet en gammel godkendelse, fordi fællesskabets websted stadig indlæses normalt. Dens korrekturlæser identificerer den manglende afhængighed: webstedets tilgængelighed er ikke bevis på, at den udgående tjenesteadresse forblev den samme. Den foreslåede løsning er at bekræfte den nye rute med den ansvarlige operatør, gennemgå den autoriserede ændring og indsamle nyt meddelelsesbevis. Dette er en fiktiv sag, ikke en målt hændelse eller en gennemført migration.
- Implementering, udgave og aktuel instruktionsbekræftelse: ______
- Påtænkt forfatterdomæne og observeret kuvertidentitet: ______
- Standard inkluderer eller supportudstedt adressebeslutning og ejer: ______
- Eksisterende TXT politik, godkendt ændring og evalueringsgennemgang: ______
- Underretning om infrastrukturmigrering og vedligeholdelsesansvar: ______
- DKIM anmodningsreference, offentlig ejer, nøgle og underskriftsbekræftelse: ______
- Godkendte meddelelsesidentiteter og justeringsresultater: ______
- DMARC -politikejer, uafklarede afhængigheder og frigivelsesbeslutning: ______
Den nøjagtige katalogimplementeringsbevis, aktuelle anvendelighed, gennemgang af menneskelige emner, produktionsruter, visuel tilgængelighed og ejerudgivelse forbliver åbne. Artiklen er et dokumentarisk udkast, ikke et bevis på, at en lejer, DNS zone eller beskedstrøm er blevet konfigureret eller testet.