Cum să configurați corect SPF, DKIM și DMARC în Plesk

În acest ghid, vă voi arăta pas cu pas cum să SPF DKIM și DMARC în Plesk, astfel încât e-mailurile dvs. să fie autentificate în mod fiabil. Veți primi proceduri clare pentru intrările DNS, comutatoarele Plesk și metodele de testare cu ajutorul cărora puteți crește capacitatea de livrare și puteți bloca expeditorii abuzivi.

Puncte centrale

• SPF determină ce sisteme sunt autorizate să trimită e-mailuri pentru domeniul dvs.
• DKIM semnează mesajele de ieșire și protejează împotriva manipulării.
• DMARC conectează SPF/DKIM cu orientări și rapoarte.
• Plesk oferă asistenți și șabloane DNS pentru un start rapid.
• Monitorizare a rapoartelor DMARC vă ascute politica în funcționare.

Verificați premisele în Plesk

Înainte de a face orice setări, verific serverul de e-mail utilizat în Plesk și gestionarea DNS. Pe Linux lucrez de obicei cu Postfix, iar pe Windows cu SmarterMail, deoarece aceste servicii oferă funcții SPF, DKIM și DMARC. Verific, de asemenea, dacă domeniul are zonele DNS în Plesk DNS sau la un furnizor extern, deoarece astfel pot gestiona intrările în afara Plesk trebuie adăugate. Pentru o funcționare fără probleme, păstrez curat numele gazdei, DNS invers și certificatele TLS valide, deoarece serverele de livrare verifică aceste puncte. Un punct de plecare curat economisește mult timp mai târziu și consolidează Reputație.

Configurarea SPF în Plesk - pas cu pas

Pentru a începe, deschid "Instrumente și setări" → "Setări DNS" și caut o înregistrare TXT care începe cu v=spf1 începe. Dacă lipsește, îl pun, de exemplu: v=spf1 a mx include:yourmailprovider.de -allastfel încât sistemele autorizate să poată trimite mesaje, iar toate celelalte să fie blocate. În cazul în care domeniul utilizează expeditori suplimentari, cum ar fi Microsoft 365, Google Workspace sau servicii de newsletter, adaug include-din documentația lor. După salvare, acord până la 48 de ore pentru ca modificarea să aibă efect la nivel global și testez înregistrarea cu un verificator SPF prin intermediul unui e-mail de test către o căsuță poștală selectată. Puteți găsi o clasificare compactă a interacțiunii mecanismelor în ghid compactcare explică cele mai importante scenarii.

Activați DKIM în Plesk - iată cum procedați

Pentru DKIM Mă duc la "Instrumente și setări" → "Setări server de poștă electronică" și activez opțiunea de semnare a e-mailurilor de ieșire. Deschid apoi "Site-uri web și domenii" la nivel de domeniu → Domeniu → "Mail" → "Setări" și verific dacă semnarea este activată pentru fiecare domeniu. Dacă gestionez DNS extern, export datele din Plesk generează cheile publice DKIM și le introduce ca înregistrări TXT la furnizorul DNS (rețineți numele selectorului). După cel mult 24-48 de ore, destinatarii ar trebui să valideze semnăturile DKIM, lucru pe care îl confirm prin trimiterea unui e-mail de test către o căsuță poștală de verificare DKIM sau o verificare a antetului. O semnătură validă consolidează Livrabilitate vizibile.

Definirea politicii DMARC și a rapoartelor de utilizare

Acum am stabilit DMARC ca înregistrare TXT pe _dmarc.yourdomain.tld cu valoarea v=DMARC1; p=carantină; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Etichetele p, rua și apel politica de control și raportare, în timp ce adkim/aspf definiți alinierea strictă (strictă). În practică, încep adesea cu p=nonesă evalueze rapoartele timp de două până la patru săptămâni și apoi să elaboreze carantină sau respingeți pe. Rapoartele arată ce sisteme trimit e-mailuri în numele dvs. și unde SPF sau DKIM eșuează, ceea ce permite efectuarea de corecții directe. O secvență mai detaliată de pași descrie Implementarea DMARC cu exemple concrete.

Propagarea DNS, teste și bune practici

Fiecare schimbare de DNS necesită timp, așa că am planificat până la 48 de ore pentru schimbările de DNS la nivel mondial. Propagarea on. În această fază, trimit e-mailuri de test către căsuțe poștale externe și verific rezultatele autentificării în antetul pentru spf=pass, dkim=pass și dmarc=pass. Dacă o corespondență primește un softfail sau NeutruVerific mecanismele SPF, selectorii DKIM și plicul "de la" (calea de returnare) pentru alinierea cu "de la". Atunci când folosesc redirecționări, monitorizez rezultatele DMARC, deoarece SPF se întrerupe adesea în acest caz; DKIM compensează de obicei acest lucru. Eu evit ~toate permanent și pentru configurații productive se bazează în mod constant pe -all.

Etichete și valori DMARC - tabel compact

Eu folosesc următoarea prezentare generală pentru a DMARC rapid și fiabil și pentru a evita interpretările eronate. Păstrez coerența valorilor între domeniile principale și subdomenii și documentez modificările într-o manieră trasabilă. Pentru domeniile productive, stabilesc o aliniere strictă și activez întotdeauna rapoartele agregate. Rapoarte criminalistice (apel) Planific în conformitate cu reglementările privind protecția datelor. Stabilirea unor orientări clare stabilizează Reputație a domeniului.

Ziua	Adică	Valori posibile	Recomandare
p	Politica pentru domeniul principal	niciunul, carantină, respingere	Începeți cu niciunul, apoi creșteți până la respingere
sp	Politica pentru subdomenii	niciunul, carantină, respingere	sp=reject pentru configurații productive
rua	Rapoarte agregate	mailto:adresse	Utilizați propria adresă de raportare
apel	Rapoarte criminalistice	mailto:adresse	Activați numai dacă este necesar
adkim	Alinierea DKIM	r (relaxat), s (strict)	adkim=s pentru o atribuire clară
aspf	Alinierea SPF	r (relaxat), s (strict)	aspf=s pentru mai puține alarme false
pct	Procent din cerere	0-100	Strângerea pas cu pas cu pct

Integrați expeditorii externi: Microsoft 365, Google, servicii de newsletter

Dacă un domeniu utilizează căi de expediere suplimentare, adaug SPF include pentru Microsoft 365, Google Workspace, Mailgun, SendGrid sau instrumente de buletin informativ exact așa cum este documentat. Pentru fiecare serviciu, verific dacă o cheie DKIM separată este activă și dacă domeniul de la este într-adevăr semnat. Evit duplicarea sau prea multe include-cascade, deoarece SPF este limitat la zece căutări DNS. Dacă bugetul pentru căutări nu este suficient, consolidez expeditorii sau mut fluxurile individuale pe subdomenii cu propria politică DMARC. Acesta este modul în care mențin SPF redus și securizez Semnături de la.

Verificări aprofundate și selectarea serverului

Pentru e-mailurile primite activez în Plesk verificarea SPF, DKIM și DMARC, astfel încât serverul să filtreze spam-ul într-un stadiu incipient. Pe Linux, aceste verificări sunt disponibile în mod implicit, în timp ce pe Windows ele sunt implementate cu SmarterMail. Mă asigur că serverul de e-mail este actualizat corespunzător, astfel încât rutinele de semnătură și analizoarele să rămână la zi. Dacă există probleme cu falsii pozitivi, ajustez pragurile de notare, dar niciodată Politică din propriul domeniu. Acesta este modul în care mențin protecția ridicată și asigur livrarea de la expeditori legitimi.

Erori frecvente și soluții rapide

Întâlniri "SPF permerror", există de obicei o eroare de sintaxă sau limita de căutare a fost depășită. Dacă DKIM eșuează, verific selectorul, înregistrarea cheii publice și terminarea valorii TXT cu ghilimele corecte. Dacă DMARC eșuează eșueazăMai întâi verific alinierea: From-Domain, Return-Path și DKIM-d= trebuie să corespundă perfect. Dacă SPF se întrerupe cu redirecționările, mă bazez pe DKIM și menține statutul semnăturii stabil. Folosesc această secvență pentru a rezolva majoritatea problemelor de livrare fără o căutare îndelungată.

Șabloane DNS și automatizare în Plesk

Dacă gestionez mai multe domenii, setez Șablon DNS în Plesk și stochez înregistrările standard pentru SPF, DKIM și DMARC acolo. Domeniile noi primesc imediat valori implicite solide pe care trebuie doar să le ajustez. De asemenea, implementez modificările planificate, cum ar fi DMARC mai strict la nivelul întregului domeniu, utilizând șabloane și scripturi. Pentru rotațiile cheilor DKIM, lucrez cu doi selectori, astfel încât să pot face schimbări treptate. Astfel, operațiunea rămâne consecventă în zeci de domenii și mentenabil.

Evaluați rapoartele DMARC și înăspriți politica

După punerea în funcțiune, analizez zilnic rapoartele agregate și identific Sursecare trimit în numele domeniului fără autorizație. Blochez IP-urile neașteptate și curăț instrumentele învechite înainte de a înăspri politica. Schimbarea de la p=none la carantină și mai târziu respingeți Eu realizez cu pct în etape, astfel încât să pot măsura efectele într-un mod controlat. Dacă expeditorii legitimi apar în raportul eșuat, corectez SPF include sau activez propria mea cheie DKIM. Această rutină consolidează Reputație vizibile și reduce spoofing-ul.

Înțelegerea corectă a alinierii

Așa că DMARC Asigur în mod constant alinierea corectă. Cu SPF este domeniul din plicul de la (calea de întoarcere) sau identitatea HELO/EHLO, care trebuie să corespundă domeniului vizibil de la (strict: identic, relaxat: același domeniu al organizației). Cu DKIM Verific d=-atribut al semnăturii: trebuie să indice același domeniu (strict) sau același domeniu organizațional (relaxat). În practică, mă asigur că:

• calea de respingere utilizată (calea de returnare) utilizează un domeniu care corespunde domeniului de origine sau este externalizată în mod deliberat către un subdomeniu cu propria politică DMARC,
• toți furnizorii terți domeniul From semn (DKIM), nu doar propriul lor domeniu de expediere,
• semnătura DKIM rămâne intactă în timpul expedierii pentru a compensa întreruperile SPF.

Dacă alinierea lipsește, receptorii DMARC raportează o eroare, în ciuda unui SPF/DKIM valid. dmarc=fail. Acesta este motivul pentru care verific câmpurile din antetul e-mailului Rezultatele autentificării, Cale de întoarcere și parametrii DKIM. Acest lucru îmi permite să recunosc rapid dacă SPF sau DKIM asigură alinierea și unde trebuie să fac îmbunătățiri.

Gestionarea cheilor și parametrii DNS

Pentru robust DKIM-am folosit chei pe 2048 de biți. În Plesk Pot seta lungimea cheii pentru fiecare domeniu; găsesc rapid chei mai vechi de 1024 de biți. Dacă este necesar, împart înregistrările TXT DKIM lungi în mai multe segmente cu virgulă inversă, astfel încât serverul DNS să le livreze corect. De asemenea, definesc TTL-valori: În fazele de lansare, merg la 300-900 de secunde, productiv folosesc 1-4 ore. Acest lucru îmi permite să reacționez flexibil la schimbări fără a supraîncărca cache-urile.

The Rotire Fac acest lucru fără eșec cu doi selectori:

1. Creați un selector nou în Plesk și publicați cheia publică ca TXT în DNS.
2. Schimbați expeditorul la noul selector și observați monitorizarea (arată anteturile) s=nou selector).
3. Odată ce toate fluxurile au fost convertite, eliminați selectorul vechi din DNS și dezactivați-l în Plesk.

Folosesc furnizori terți atunci când este posibil, delegate înregistrări DKIM (de exemplu, CNAME către selectorul furnizorului). Acest lucru îmi permite să mențin controlul în zona mea și să schimb cheile fără a risca întreruperi operaționale.

Cazuri speciale: Transmitere, liste de corespondență și porți de acces

În medii reale, văd în mod regulat redirecționări, liste de difuzare sau porți de securitate care rescriu e-mailurile. Acord o atenție deosebită efectelor de aici:

• TransmitereSPF se întrerupe adesea deoarece IP-ul de expediere nu se află în SPF al domeniului expeditorului. Eu mă bazez aici pe DKIMcare asigură protecția conținutului. Dacă semnătura rămâne neschimbată, DMARC există prin alinierea DKIM.
• Liste de corespondențăMulte liste schimbă subiectele sau subsolurile și astfel încalcă semnătura DKIM. În astfel de cazuri, planific o aliniere relaxată și verific dacă lista utilizează SRS/ARC sau propriile semnături. Dacă este posibil, folosesc un subdomeniu cu propria politică DMARC pentru liste.
• Porți de securitateGateway-urile care resemnează mesajele sau rescriu plicul de la trebuie să fie aliniate corect cu domeniul expeditorului. Documentez rolul acestora și le ancorez în SPF (ip4/ip6) sau prin includere, astfel încât alinierea să fie menținută.

Întâlniți e-mailuri cu spf=fail printr-o redirecționare, acest lucru nu este automat critic atâta timp cât dkim=pass este prezent, iar alinierea DKIM este corectă. Evaluez ansamblul rezultatelor autentificării în locul semnalelor individuale izolate.

IP-uri partajate, HELO/EHLO și rDNS

Dacă mai multe domenii împart același IP de ieșire, mă bazez pe rDNS și nume HELO/EHLO coerente. Pointerul invers indică un FQDN (de exemplu mail.hosting-exemplu.tld), al cărui A-record indică același IP. MTA raportează exact cu acest nume. Mă asigur că Certificat SMTP TLS corespunde numelui HELO (SNI în cazul în care sunt servite mai multe nume). Pentru fiecare domeniu de expediere, mă asigur, de asemenea, că SPF/DKIM/DMARC sunt aliniate complet și corect - IP-ul comun nu afectează DMARC atât timp cât autentificarea este eficientă.

Pentru expeditorii dedicați (de exemplu, e-mail tranzacțional vs. marketing), îmi place să îi separ prin subdomenii și, opțional, prin IP-uri proprii. Acest lucru ajută cu Gestionarea reputațieisimplifică evaluarea rapoartelor DMARC și minimizează interferențele reciproce.

Monitorizarea și implementarea în practică

Pentru a asigura buna funcționare, combin Analiza DMARC cu etape clare de punere în aplicare:

• Linia de bază: 2-4 săptămâni p=nonecolectați toate rapoartele agregate (rua), identificați sursele de eroare.
• CurățareEliminați expeditorii neautorizați, curățați SPF include, activați DKIM pe toate sistemele legitime.
• DressingCu pct treptat la carantină, mai târziu respingeți crește, măsurați efectele ca procent.
• AlertăDefiniți valorile prag (IP-uri noi, rata de eșec pe furnizor, domenii noi) și configurați notificările.
• DocumentațieMențineți selectorii, TTL, timpii de execuție cheie, bugetul SPF și responsabilitățile sub controlul versiunii.

Verific Buget de căutare SPF (max. 10 mecanisme cu interogări DNS) și consolidați include. Mecanisme critice, cum ar fi ptr sau + toate În general, nu le folosesc; ip4/ip6, a, mx și direcționate include rămân mijloacele de alegere. Acesta este modul în care mențin configurația stabilă și verificabilă.

Verificare rapidă pentru fiecare domeniu

La sfârșitul fiecărei instalări, execut un test fix Verificare prin: Înregistrare SPF disponibilă, buget de căutare sub zece, mecanisme sortate corect, -all Activ. Semnătură DKIM validă, selector documentat, lungime suficientă a cheii, rotație planificată. DMARC cu înregistrare TXT validă, aliniere strictă, căsuțe poștale de raportare accesibile și arhivate. Afișați e-mailurile de test spf=pass, dkim=pass și dmarc=pass în antet. Eu folosesc această secvență pentru a păstra configurațiile reproductibile și Eroare scăzută.

Rezumat practic pentru un succes rapid

Încep fiecare proiect cu obiective clare StandardeMențineți SPF redus, activați DKIM pentru fiecare expeditor și implementați DMARC cu raportare. Acestea sunt urmate de două până la patru săptămâni de monitorizare pentru a elimina punctele moarte și pentru a întări orientările. Integrez serviciile externe într-un mod controlat, documentez includerile și țin sub control bugetul de căutare. Folosesc șabloane DNS pentru mai multe domenii și planific rotații ale cheilor DKIM pentru a menține semnăturile proaspete. Rezum ideile practice utile și sfaturile de depanare în Sfaturi Plesk 2025 împreună, astfel încât să puteți menține o puternică Livrabilitate ajunge.