Kā pareizi konfigurēt SPF, DKIM un DMARC Plesk sistēmā

Šajā rokasgrāmatā es jums soli pa solim parādīšu, kā SPF DKIM un DMARC Plesk, lai e-pasti tiktu droši autentificēti. Jūs saņemsiet skaidras procedūras DNS ierakstiem, Plesk slēdžiem un testēšanas metodēm, ar kurām varat palielināt piegādājamību un bloķēt ļaunprātīgus sūtītājus.

Centrālie punkti

• SPF nosaka, kuras sistēmas ir pilnvarotas sūtīt jūsu domēna e-pastus.
• DKIM paraksta izejošos ziņojumus un aizsargā pret manipulācijām.
• DMARC savieno SPF/DKIM ar vadlīnijām un ziņojumiem.
• Plesk nodrošina vedņus un DNS veidnes ātrai uzsākšanai.
• Uzraudzība DMARC ziņojumi precizē jūsu darbības politiku.

Pārbaudiet priekšnoteikumus Plesk

Pirms veicu jebkādus iestatījumus, pārbaudu pasta serveri, ko izmanto Plesk un DNS pārvaldība. Linux operētājsistēmā es parasti strādāju ar Postfix, bet Windows operētājsistēmā - ar SmarterMail, jo šie pakalpojumi nodrošina SPF, DKIM un DMARC funkcijas. Es arī pārbaudu, vai domēna DNS zonas atrodas Plesk DNS vai pie ārēja pakalpojumu sniedzēja, jo tad es varu pārvaldīt ierakstus ārpus sistēmas. Plesk jāpievieno. Lai nodrošinātu netraucētu darbību, es uzturu tīru resursvietas nosaukumu, reverso DNS un derīgus TLS sertifikātus, jo piegādes serveri pārbauda šos punktus. Tīrs sākumpunkts vēlāk ietaupa daudz laika un stiprina Reputācija.

SPF iestatīšana Plesk - soli pa solim

Lai sāktu, es atveru "Rīki un iestatījumi" → "DNS iestatījumi" un meklēju TXT ierakstu, kas sākas ar v=spf1 sākas. Ja tā trūkst, es to uzlieku, piemēram: v=spf1 a mx include:yourmailprovider.de -alllai autorizētām sistēmām būtu atļauts sūtīt, bet visas pārējās sistēmas tiktu bloķētas. Ja domēns izmanto papildu sūtītājus, piemēram, Microsoft 365, Google Workspace vai jaunumu dienesta pakalpojumus, es pievienoju atbilstošo iekļaut-mehānismi no to dokumentācijas. Pēc saglabāšanas es atvēlu līdz 48 stundām, lai izmaiņas stātos spēkā globāli, un pārbaudu ierakstu ar SPF pārbaudītāju, nosūtot testa e-pastu uz izvēlētu pastkasti. Mehānismu mijiedarbības kompaktu klasifikāciju var atrast vietnē kompakts ceļvediskurā izskaidroti svarīgākie scenāriji.

DKIM aktivizēšana Plesk - šādā veidā jūs varat rīkoties.

Vietnei DKIM Es eju uz "Rīki un iestatījumi" → "Pasta servera iestatījumi" un aktivizēju iespēju parakstīt izejošos e-pastus. Pēc tam atveru "Tīmekļa vietnes un domēni" domēna līmenī → Domēns → "Pasts" → "Iestatījumi" un pārbaudu, vai katram domēnam ir ieslēgta parakstīšana. Ja DNS pārvaldu ārēji, es eksportēju datus no Plesk ģenerētās DKIM publiskās atslēgas un ievadiet tās kā TXT ierakstus ar DNS pakalpojumu sniedzēju (ņemiet vērā selektora nosaukumu). Pēc ne vairāk kā 24-48 stundām saņēmējiem būtu jāapstiprina DKIM paraksti, ko es apstiprinu, nosūtot testa vēstuli uz DKIM pārbaudes pastkasti vai izmantojot galvenes pārbaudi. Derīgs paraksts stiprina Piegādājamība pamanāms.

DMARC politikas definēšana un pārskatu izmantošana

Tagad es iestatīju DMARC kā TXT ierakstu _dmarc.yourdomain.tld ar vērtību v=DMARC1; p=karantīna; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Tags p, rua un zvaniet kontroles politiku un ziņošanu, bet adkim/aspf definēt stingro izlīdzināšanu (strict). Praksē es bieži sāku ar p=nonedivas līdz četras nedēļas izvērtē ziņojumus un pēc tam sagatavo karantīna vai noraidīt par. Pārskatos ir redzams, kuras sistēmas sūta e-pastus jūsu vārdā un kur SPF vai DKIM neizdodas, kas ļauj veikt tiešus labojumus. Padziļinātākā soļu secība apraksta. DMARC ieviešana ar konkrētiem piemēriem.

DNS izplatīšana, testi un labākā prakse

Katras DNS izmaiņas prasa laiku, tāpēc globālo DNS izmaiņu veikšanai plānoju līdz 48 stundām. Pavairošana par. Šajā posmā es sūtu testa e-pastus uz ārējām pastkastītēm un pārbaudu autentifikācijas rezultātus galvenē. spf=pass, dkim=pass un dmarc=pass. Ja pasts saņem softfail vai NeitrālsEs pārbaudu SPF mehānismus, DKIM selektorus un envelope-from (atgriešanās ceļu), lai nodrošinātu atbilstību From:. Izmantojot pāradresācijas, es uzraugu DMARC rezultātus, jo SPF tur bieži vien tiek pārkāpti; DKIM parasti to kompensē. Es izvairos no ~all pastāvīgi un produktīvu iestatījumu gadījumā konsekventi paļauties uz -visi.

DMARC tagi un vērtības - kompakta tabula

Es izmantoju šādu pārskatu, lai DMARC ātri un uzticami un lai izvairītos no nepareizas interpretācijas. Es saglabāju konsekventas vērtības galvenajās un apakšdomēnās un dokumentēju izmaiņas izsekojamā veidā. Produktīvām domēnām es nosaku stingru izlīdzināšanu un vienmēr aktivizēju kopsavilkuma pārskatus. Tiesu ekspertīzes ziņojumi (zvaniet) Es plānoju saskaņā ar datu aizsardzības noteikumiem. Skaidru pamatnostādņu noteikšana stabilizē Reputācija ilgtspējīgi pārvaldīt šo jomu.

Diena	Nozīme	Iespējamās vērtības	Ieteikums
p	Galvenā domēna politika	nav, karantīna, noraidīt	Sāciet no nulles, pēc tam palieliniet, lai noraidītu
sp	Apakšdomēnu politika	nav, karantīna, noraidīt	sp = noraidīt produktīviem iestatījumiem
rua	Kopsavilkuma ziņojumi	mailto:adresse	Izmantojiet savu ziņošanas adresi
zvaniet	Tiesu ekspertīzes ziņojumi	mailto:adresse	Aktivizēt tikai tad, ja nepieciešams
adkim	DKIM saskaņošana	r (atviegloti), s (stingri)	adkim=s skaidram piešķiršanai
aspf	SPF saskaņošana	r (atviegloti), s (stingri)	aspf=s, lai samazinātu viltus trauksmju skaitu.
pct	Pieteikuma procentuālā daļa	0-100	Soli pa solim pastiprināšana ar pct

Ārējo sūtītāju integrēšana: Microsoft 365, Google, jaunumu dienesti

Ja domēns izmanto papildu nosūtīšanas ceļus, es pievienoju SPF ietverto Microsoft 365, Google Workspace, Mailgun, SendGrid vai biļetenu rīkiem tieši tā, kā dokumentēts. Katram pakalpojumam pārbaudu, vai ir aktīva atsevišķa DKIM atslēga un vai domēns from ir patiešām parakstīts. Izvairos no dublējošiem vai pārāk daudziem iekļaut-kaskādes, jo SPF ir ierobežots līdz desmit DNS izsaukumiem. Ja uzmeklēšanai paredzētais budžets nav pietiekams, es konsolidēju sūtītājus vai pārvietoju atsevišķas plūsmas uz apakšdomēnām ar savu DMARC politiku. Šādā veidā es uzturu SPF un nodrošinu Paraksti no.

Padziļinātas pārbaudes un servera izvēle

Ienākošajiem e-pastiem es aktivizēju Plesk SPF, DKIM un DMARC pārbaude, lai serveris jau agrīnā posmā filtrētu surogātpasta vēstules. Linux operētājsistēmā šīs pārbaudes ir pieejamas pēc noklusējuma, savukārt Windows operētājsistēmā tās tiek īstenotas ar SmarterMail. Pārliecinos, ka pasta serveris tiek pienācīgi atjaunināts, lai parakstu rutīnas un analizatori būtu aktuāli. Ja rodas problēmas ar viltus pozitīviem gadījumiem, es koriģēju vērtēšanas sliekšņus, bet nekad. Politika savā domēnā. Šādā veidā es nodrošinu augstu aizsardzības līmeni un garantēju piegādi no likumīgiem sūtītājiem.

Biežāk sastopamās kļūdas un ātrie risinājumi

Iepazīstas "SPF permerror", parasti ir sintakses kļūda vai ir pārsniegts meklēšanas ierobežojums. Ja DKIM neizdodas, pārbaudu selektoru, publiskās atslēgas ierakstu un TXT vērtības pabeigšanu ar pareiziem komatiem. Ja DMARC neizdodas neizdodasVispirms pārbaudu izlīdzināšanu: From-Domain, Return-Path un DKIM-d= ir pilnīgi jāsakrīt. Ja SPF tiek pārtraukta ar novirzēm, es paļaujos uz DKIM un saglabāt stabilu paraksta statusu. Es izmantoju šo secību, lai atrisinātu lielāko daļu piegādes problēmu bez ilgas meklēšanas.

DNS veidnes un automatizācija programmā Plesk

Ja pārvaldu daudzus domēnus, iestatu DNS veidne Plesk un saglabājiet tajā SPF, DKIM un DMARC standarta ierakstus. Jauni domēni uzreiz saņem stabilus noklusējuma iestatījumus, kurus man atliek tikai precizēt. Es ieviešu arī plānotās izmaiņas, piemēram, stingrāku DMARC visā domēnā, izmantojot veidnes un skriptus. Attiecībā uz DKIM atslēgu rotāciju es strādāju ar diviem selektoriem, lai varētu veikt pakāpeniskas izmaiņas. Tas nodrošina darbības konsekvenci desmitiem domēnu un uzturams.

DMARC ziņojumu izvērtēšana un politikas pastiprināšana

Pēc darbības uzsākšanas es katru dienu analizēju apkopotos pārskatus un identificēju. Avotikas sūta domēna vārdā bez atļaujas. Pirms politikas pastiprināšanas bloķēju negaidītus IP un attīru novecojušos rīkus. Izmaiņas no p=none vietnē karantīna un vēlāk noraidīt Es veicu ar pct pa posmiem, lai varētu kontrolēti izmērīt ietekmi. Ja neveiksmīgajā ziņojumā parādās leģitīmi sūtītāji, es koriģēju SPF vai aktivizēju savu DKIM atslēgu. Šī procedūra stiprina Reputācija redzams un samazina spoofing.

Pareiza izlīdzināšanas izpratne

Tātad, ka DMARC Es konsekventi nodrošinu pareizu izlīdzināšanu. Ar SPF ir aploksnes domēns no (atgriešanās ceļš) vai HELO/EHLO identitāte, kurai jāatbilst redzamajam domēnam no (stingra: identisks, atvieglota: tās pašas organizācijas domēns). Ar DKIM Es pārbaudu d=-paraksta atribūts: tam jānorāda uz to pašu domēnu (stingrais) vai uz to pašu organizatorisko domēnu (atvieglotais). Praksē es pārliecinos, ka:

• izmantotais atteikuma ceļš (atgriešanās ceļš) izmanto domēnu, kas atbilst domēnam from, vai ir apzināti nodots apakšdomēnam ar savu DMARC politiku,
• visiem trešo pušu pakalpojumu sniedzējiem domēns From zīme (DKIM), ne tikai savu piegādes domēnu,
• pārsūtīšanas laikā DKIM paraksts paliek neskarts, lai kompensētu SPF pārtraukumus.

Ja trūkst izlīdzināšanas, DMARC uztvērēji ziņo par kļūdu, neskatoties uz derīgu SPF/DKIM. dmarc=fail. Tāpēc es pārbaudu laukus e-pasta galvenēs. Autentifikācijas rezultāti, Atgriešanās ceļš un DKIM parametrus. Tas ļauj man ātri atpazīt, vai SPF vai DKIM nodrošina izlīdzināšanu un kur man jāveic uzlabojumi.

Atslēgu pārvaldība un DNS parametri

Izturīgam DKIM-iestatījumus, es izmantoju 2048 bitu atslēgas. Vietnē Plesk Es varu iestatīt atslēgas garumu katram domēnam; es nekavējoties ieslēdzu vecākas 1024 bitu atslēgas. Ja nepieciešams, es sadalu garus DKIM TXT ierakstus vairākos komata segmentos, lai DNS serveris tos pareizi piegādātu. Es arī definēju jēgpilnus TTL-vērtības: Izvēršanas fāzēs es eju uz 300-900 sekundēm, produktīvi es izmantoju 1-4 stundas. Tas ļauj man elastīgi reaģēt uz izmaiņām, nepārslogojot kešatmiņas.

Portāls Rotācija Es to daru bez kļūdām, izmantojot divus selektorus:

1. Izveidojiet jaunu selektoru Plesk un publicējiet publisko atslēgu kā TXT DNS.
2. Mainīt sūtītāju uz jauno selektoru un novērot uzraudzību (parādīt galvenes) s=jauns selektors).
3. Kad visas plūsmas ir pārveidotas, noņemiet veco selektoru DNS un deaktivizējiet to Plesk.

Ja iespējams, es izmantoju trešo pušu pakalpojumu sniedzējus, deleģēts DKIM ieraksti (piemēram, CNAME uz pakalpojumu sniedzēja selektoru). Tas ļauj man saglabāt kontroli savā zonā un rotēt atslēgas, neriskējot ar darbības pārtraukumiem.

Īpaši gadījumi: Pārsūtīšana, adresātu saraksti un vārti

Reālajā vidē es regulāri redzu pāradresācijas, pasta sarakstus vai drošības vārtejas, kas pārraksta e-pasta vēstules. Īpašu uzmanību pievēršu sekām šajā jomā:

• PārsūtīšanaSPF bieži tiek pārtraukta, jo pārsūtīšanas IP nav iekļauts sūtītāja domēna SPF. Šajā gadījumā es paļaujos uz DKIMkas nodrošina satura aizsardzību. Ja paraksts paliek nemainīgs, DMARC pastāv, izmantojot DKIM izlīdzināšanu.
• Pasta sarakstiDaudzos sarakstos tiek mainīti temati vai zemsvītras un tādējādi tiek pārkāpts DKIM paraksts. Šādos gadījumos es plānoju atvieglotu izlīdzināšanu un pārbaudi, vai saraksts izmanto SRS/ARC vai savus parakstus. Ja iespējams, es izmantoju subdomēnu ar savu DMARC politiku sarakstiem.
• Drošības vārtiVārtejiem, kas atkārtoti paraksta ziņojumus vai pārraksta aploksni "no", jābūt pareizi saskaņotiem ar sūtītāja domēnu. Es dokumentēju to lomu un iestrādāju tos SPF (ip4/ip6) vai iekļauju, lai saskaņošana tiktu saglabāta.

Meet mails ar spf=fail izmantojot pārsūtīšanu, tas nav automātiski kritiski, ja vien dkim=pass ir un DKIM izlīdzināšana ir pareiza. Es vērtēju visus autentifikācijas rezultātus kopumā, nevis atsevišķus signālus atsevišķi.

Koplietoti IP, HELO/EHLO un rDNS

Ja vairākiem domēniem ir viens un tas pats izejošais IP, es paļaujos uz tīru rDNS un konsekventus HELO/EHLO nosaukumus. Reversais rādītājs norāda uz FQDN (piem. mail.hosting-example.tld), kura A ieraksts norāda uz to pašu IP. MTA ziņo tieši ar šādu nosaukumu. Es pārliecinos, ka SMTP TLS sertifikāts atbilst HELO nosaukumam (SNI, ja tiek apkalpoti vairāki nosaukumi). Katram sūtītāja domēnam es arī nodrošinu, ka SPF/DKIM/DMARC ir pilnībā un pareizi saskaņoti - kopīgais IP vien neietekmē DMARC, ja vien autentifikācija ir efektīva.

Specializētajiem sūtītājiem (piemēram, darījumu un mārketinga pasta sūtījumiem) man patīk tos nodalīt, izmantojot apakšdomēnus un pēc izvēles arī savus IP. Tas palīdz Reputācijas pārvaldībavienkāršo DMARC ziņojumu novērtēšanu un samazina savstarpējo traucējumu rašanos.

Uzraudzība un ieviešana praksē

Lai nodrošinātu vienmērīgu darbību, es apvienoju nepārtrauktu DMARC analīze ar skaidriem ieviešanas posmiem:

• Pamatlīnija: 2-4 nedēļas p=noneapkopot visus kopsavilkuma ziņojumus (rua), identificēt kļūdu avotus.
• TīrīšanaNoņemiet neautorizētus sūtītājus, iztīriet SPF, aktivizējiet DKIM visās likumīgajās sistēmās.
• TērpsAr pct pakāpeniski uz karantīna, vēlāk noraidīt palielinājums, novērtējiet ietekmi procentos.
• BrīdināšanaNosakiet robežvērtības (jauni IP adresāti, kļūdu biežums katram pakalpojumu sniedzējam, jauni no domēniem) un iestatiet paziņojumus.
• DokumentācijaSelektori, TTL, atslēgu izpildes laiki, SPF budžets un pienākumi tiek turēti versiju kontrolē.

Es pārbaudu SPF meklēšanas budžets (ne vairāk kā 10 mehānismi ar DNS vaicājumiem) un konsolidēt ietver. Kritiski svarīgi mehānismi, piemēram ptr vai + visi Es parasti tos neizmantoju; ip4/ip6, a, mx un mērķtiecīgi iekļaut joprojām ir izvēles līdzeklis. Šādā veidā es uzturu iestatījumu stabilu un pārbaudāmu.

Ātra pārbaude katram domēnam

Katras instalēšanas beigās es palaidu fiksēto Pārbaudiet caur: SPF ieraksts pieejams, meklēšanas budžets zem desmit, mehānismi pareizi sakārtoti, -visi Aktīvs. DKIM paraksts derīgs, selektors dokumentēts, atslēgas garums pietiekams, plānota rotācija. DMARC ar derīgu TXT ierakstu, stingra izlīdzināšana, pieejamas un arhivētas ziņošanas pastkastītes. Rādīt testa e-pastus spf=pass, dkim=pass un dmarc=pass galvenē. Es izmantoju šo secību, lai iestatījumi būtu reproducējami un Zema kļūda.

Praktisks kopsavilkums ātrai panākumu gūšanai

Katru projektu es sāku ar skaidru StandartiSaglabājiet SPF, aktivizējiet DKIM katram sūtītājam un ievietojiet DMARC ar ziņošanu. Pēc tam divas līdz četras nedēļas veiciet uzraudzību, lai novērstu "aklos punktus" un pastiprinātu vadlīnijas. Es kontrolēti integrēju ārējos pakalpojumus, dokumentēju tos un kontrolēju meklēšanas budžetu. Es izmantoju DNS veidnes vairākiem domēniem un plānoju DKIM atslēgu rotāciju, lai saglabātu parakstu svaigumu. Es apkopoju noderīgas praktiskas idejas un traucējumu novēršanas padomus savos Plesk padomi 2025 kopā, lai jūs varētu uzturēt spēcīgu Piegādājamība sasniegt.