Sådan konfigureres SPF, DKIM og DMARC korrekt i Plesk

I denne guide viser jeg dig trin for trin, hvordan du SPF DKIM og DMARC i Plesk, så dine e-mails bliver autentificeret på en pålidelig måde. Du får klare procedurer for DNS-indgange, Plesk-switches og testmetoder, som du kan bruge til at øge leveringsevnen og blokere misbrugte afsendere.

Centrale punkter

• SPF bestemmer, hvilke systemer der har tilladelse til at sende mails for dit domæne.
• DKIM signerer udgående beskeder og beskytter mod manipulation.
• DMARC forbinder SPF/DKIM med retningslinjer og rapporter.
• Plesk indeholder guider og DNS-skabeloner til en hurtig start.
• Overvågning af DMARC-rapporterne skærper din politik i praksis.

Tjek forudsætningerne i Plesk

Før jeg foretager nogen indstillinger, tjekker jeg den mailserver, der bruges i Plesk og DNS-administration. På Linux arbejder jeg normalt med Postfix, på Windows med SmarterMail, da disse tjenester leverer SPF-, DKIM- og DMARC-funktioner. Jeg tjekker også, om domænet har sine DNS-zoner i Plesk DNS eller hos en ekstern udbyder, fordi jeg så kan administrere posterne uden for Plesk skal tilføjes. For at få en gnidningsfri drift holder jeg værtsnavnet, reverse DNS og gyldige TLS-certifikater rene, da leveringsserverne kontrollerer disse punkter. Et rent udgangspunkt sparer en masse tid senere og styrker Omdømme.

Opsætning af SPF i Plesk - trin for trin

For at komme i gang åbner jeg "Værktøjer og indstillinger" → "DNS-indstillinger" og søger efter en TXT-post, der starter med v=spf1 begynder. Hvis den mangler, tager jeg den f.eks. på: v=spf1 a mx include:yourmailprovider.de -allså autoriserede systemer får lov til at sende, og alle andre blokeres. Hvis domænet bruger yderligere afsendere som Microsoft 365, Google Workspace eller nyhedsbrevstjenester, tilføjer jeg de relevante inkludere-mekanismer fra deres dokumentation. Når jeg har gemt, lader jeg ændringen træde i kraft globalt i op til 48 timer og tester posten med en SPF-checker via en testmail til en udvalgt postkasse. Du kan finde en kompakt klassifikation af mekanismernes interaktion i kompakt guidesom forklarer de vigtigste scenarier.

Aktivér DKIM i Plesk - sådan gør du

For DKIM Jeg går til "Værktøjer og indstillinger" → "Mailserverindstillinger" og aktiverer muligheden for at underskrive udgående e-mails. Derefter åbner jeg "Hjemmesider og domæner" på domæneniveau → Domæne → "Mail" → "Indstillinger" og kontrollerer, om signering er slået til for hvert domæne. Hvis jeg administrerer DNS eksternt, eksporterer jeg dataene fra Plesk genererede offentlige DKIM-nøgler og indtaste disse som TXT-poster hos DNS-udbyderen (bemærk selector-navnet). Efter maksimalt 24-48 timer bør modtagerne validere DKIM-signaturerne, hvilket jeg bekræfter ved at sende en testmail til en DKIM-kontrolpostkasse eller en headerkontrol. En gyldig signatur styrker Leveringsevne Bemærkelsesværdigt.

Definer DMARC-politik og brug rapporter

Nu sætter jeg DMARC som TXT-post på _dmarc.ditdomæne.tld med værdien v=DMARC1; p=karantæne; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Taggene p, rua og opkald kontrolpolitik og rapportering, mens adkim/aspf definere den strenge tilpasning (strict). I praksis starter jeg ofte med p=ingenevaluere rapporter i to til fire uger og derefter udarbejde karantæne eller afvise på. Rapporterne viser, hvilke systemer der sender mails på dine vegne, og hvor SPF eller DKIM fejler, hvilket gør det muligt at foretage direkte rettelser. En mere detaljeret rækkefølge af trin beskriver DMARC-implementering med konkrete eksempler.

DNS-udbredelse, test og bedste praksis

Hver DNS-ændring tager tid, så jeg planlægger op til 48 timer til verdensomspændende DNS-ændringer. Forplantning på. I denne fase sender jeg testmails til eksterne postkasser og kontrollerer godkendelsesresultaterne i headeren for spf=pass, dkim=pass og dmarc=pass. Hvis en mail modtager en softfail eller NeutralJeg tjekker SPF-mekanismerne, DKIM-selektorer og envelope-from (returstien) for overensstemmelse med From:. Når jeg bruger omdirigeringer, overvåger jeg DMARC-resultaterne, da SPF ofte bryder sammen der; DKIM kompenserer normalt for dette. Jeg undgår ~alle permanent og for produktive opsætninger konsekvent stole på -alle.

DMARC-tags og -værdier - kompakt tabel

Jeg bruger følgende oversigt til at DMARC hurtigt og pålideligt og for at undgå fejlfortolkninger. Jeg holder værdierne konsistente på tværs af hoved- og underdomæner og dokumenterer ændringer på en sporbar måde. For produktive domæner indstiller jeg streng tilpasning og aktiverer altid samlede rapporter. Retsmedicinske rapporter (opkald) Jeg planlægger i overensstemmelse med databeskyttelsesreglerne. At opstille klare retningslinjer stabiliserer Omdømme af domænet.

Dag	Betydning	Mulige værdier	Anbefaling
p	Politik for hoveddomæne	ingen, karantæne, afvise	Start med ingen, øg derefter til afvisning
sp	Politik for underdomæner	ingen, karantæne, afvise	sp=afvis for produktive opsætninger
rua	Samlede rapporter	mailto:adresse	Brug din egen rapporteringsadresse
opkald	Retsmedicinske rapporter	mailto:adresse	Aktiver kun, hvis det er nødvendigt
adkim	DKIM-tilpasning	r (afslappet), s (streng)	adkim=s for klar tildeling
aspf	SPF-tilpasning	r (afslappet), s (streng)	aspf=s for færre falske alarmer
pct.	Procentdel af ansøgning	0-100	Trinvis opstramning med pct.

Integrer eksterne afsendere: Microsoft 365, Google, nyhedsbrevstjenester

Hvis et domæne bruger flere forsendelsesveje, tilføjer jeg SPF-inklusioner for Microsoft 365, Google Workspace, Mailgun, SendGrid eller nyhedsbrevsværktøjer præcis som dokumenteret. For hver tjeneste tjekker jeg, om en separat DKIM-nøgle er aktiv, og om from-domænet virkelig er signeret. Jeg undgår dubletter eller for mange inkludere-kaskader, da SPF er begrænset til ti DNS-opslag. Hvis budgettet for opslag ikke er tilstrækkeligt, konsoliderer jeg afsendere eller flytter individuelle streams til subdomæner med deres egen DMARC-politik. Det er sådan, jeg holder SPF slank og sikrer Underskrifter fra.

Dybdegående tjek og valg af server

For indgående mails aktiverer jeg i Plesk kontrol af SPF, DKIM og DMARC, så serveren filtrerer spam på et tidligt tidspunkt. På Linux er disse kontroller tilgængelige som standard, mens de på Windows er implementeret med SmarterMail. Jeg sørger for, at mailserveren opdateres korrekt, så signaturrutiner og parsere forbliver opdaterede. Hvis der er problemer med falske positiver, justerer jeg scoringstærsklerne, men aldrig grænseværdierne. Politik på dit eget domæne. Det er sådan, jeg holder beskyttelsen høj og sikrer levering fra legitime afsendere.

Almindelige fejl og hurtige løsninger

Møder "SPF permerror", er der som regel en syntaksfejl, eller grænsen for opslag er overskredet. Hvis DKIM fejler, tjekker jeg selector, public key record og afslutningen af TXT-værdien med korrekte kommaer. Hvis DMARC fejler mislykkesJeg tjekker først tilpasningen: From-Domain, Return-Path og DKIM-d= skal matche perfekt. Hvis SPF bryder med omdirigeringer, stoler jeg på DKIM og holde signaturstatussen stabil. Jeg bruger denne sekvens til at løse de fleste leveringsproblemer uden lang tids søgen.

DNS-skabeloner og automatisering i Plesk

Hvis jeg administrerer mange domæner, indstiller jeg DNS-skabelon i Plesk og gemmer standardposter for SPF, DKIM og DMARC der. Nye domæner får straks solide standardindstillinger, som jeg kun behøver at finjustere. Jeg implementerer også planlagte ændringer som f.eks. strengere DMARC for hele domænet ved hjælp af skabeloner og scripts. Til rotation af DKIM-nøglerne arbejder jeg med to selektorer, så jeg kan foretage gradvise ændringer. Dette holder operationen konsistent på tværs af dusinvis af domæner og vedligeholdelig.

Evaluer DMARC-rapporter og stram politikken

Efter go-live analyserer jeg de samlede rapporter på daglig basis og identificerer Kilderder sender på vegne af domænet uden tilladelse. Jeg blokerer uventede IP-adresser og rydder op i forældede værktøjer, før jeg strammer politikken. Ændringen fra p=ingen på karantæne og senere afvise Jeg udfører med pct. i etaper, så jeg kan måle effekten på en kontrolleret måde. Hvis der optræder legitime afsendere i den mislykkede rapport, retter jeg SPF-inklusioner eller aktiverer min egen DKIM-nøgle. Denne rutine styrker Omdømme synlig og reducerer spoofing.

Forstå justering korrekt

Så det DMARC Jeg sikrer konsekvent korrekt justering. Med SPF er domænet i konvolutten fra (retursti) eller HELO/EHLO-identiteten, som skal matche det synlige fra-domæne (strict: identisk, relaxed: samme organisationsdomæne). Med DKIM Jeg tjekker d=-attribut for signaturen: Den skal pege på det samme domæne (strict) eller på det samme organisatoriske domæne (relaxed). I praksis sørger jeg for det:

• Den anvendte bounce-sti (retursti) bruger et domæne, der matcher from-domænet, eller er bevidst outsourcet til et subdomæne med sin egen DMARC-politik,
• alle tredjepartsudbydere From-domænet tegn (DKIM), ikke kun deres eget forsendelsesdomæne,
• DKIM-signaturen forbliver intakt under videresendelse for at kompensere for SPF-brud.

Hvis justering mangler, rapporterer DMARC-modtagere en fejl på trods af en gyldig SPF/DKIM. dmarc=fail. Det er derfor, jeg tjekker felterne i e-mail-overskrifterne Resultater af autentificering, Retursti og DKIM-parametrene. På den måde kan jeg hurtigt se, om det er SPF eller DKIM, der sørger for tilpasningen, og hvor jeg skal foretage forbedringer.

Nøglehåndtering og DNS-parametre

For robust DKIM-opsætninger brugte jeg 2048-bit nøgler. I Plesk Jeg kan indstille nøglelængden pr. domæne; jeg finder hurtigt ældre 1024-bit nøgler. Hvis det er nødvendigt, deler jeg lange DKIM TXT-poster op i flere segmenter med omvendt komma, så DNS-serveren leverer dem korrekt. Jeg definerer også meningsfulde TTL-værdier: I udrulningsfaser går jeg op til 300-900 sekunder, produktivt bruger jeg 1-4 timer. Det giver mig mulighed for at reagere fleksibelt på ændringer uden at overbelaste cachen.

Die Rotation Jeg gør det uden problemer med to selektorer:

1. Opret en ny selector i Plesk, og udgiv den offentlige nøgle som TXT i DNS'en.
2. Skift afsender til den nye vælger, og følg med i overvågningen (vis overskrifter) s=ny vælger).
3. Når alle flows er blevet konverteret, skal du fjerne den gamle selector i DNS og deaktivere den i Plesk.

Jeg bruger tredjepartsleverandører, hvor det er muligt, uddelegeret DKIM-poster (f.eks. CNAME til udbydervælgeren). Det giver mig mulighed for at bevare kontrollen over min zone og rotere nøgler uden at risikere driftsafbrydelser.

Særlige tilfælde: Videresendelse, mailinglister og gateways

I virkelige miljøer ser jeg jævnligt omdirigeringer, mailinglister eller sikkerhedsgateways, der omskriver e-mails. Jeg er særligt opmærksom på effekterne her:

• VideresendelseSPF går ofte i stykker, fordi videresendelses-IP'en ikke er i afsenderdomænets SPF. Jeg stoler her på DKIMsom giver indholdsbeskyttelsen. Hvis signaturen forbliver uændret, eksisterer DMARC via DKIM-tilpasning.
• MailinglisterMange lister skifter emne eller sidefod og bryder dermed DKIM-signaturen. I sådanne tilfælde planlægger jeg en afslappet tilpasning og tjekker, om listen bruger SRS/ARC eller sine egne signaturer. Hvis det er muligt, bruger jeg et subdomæne med sin egen DMARC-politik til lister.
• SikkerhedsgatewaysGateways, der gensignerer beskeder eller omskriver konvolut-fra, skal være korrekt afstemt med afsenderdomænet. Jeg dokumenterer deres rolle og forankrer dem i SPF (ip4/ip6) eller via include, så tilpasningen opretholdes.

Mød mails med spf=fail gennem en viderestilling, er dette ikke automatisk kritisk, så længe dkim=pass er til stede, og DKIM-tilpasningen er korrekt. Jeg vurderer helheden af autentificeringsresultaterne i stedet for enkelte signaler isoleret.

Delte IP'er, HELO/EHLO og rDNS

Hvis flere domæner deler den samme udgående IP, stoler jeg på ren rDNS og konsistente HELO/EHLO-navne. Den omvendte pointer peger på en FQDN (f.eks. mail.hosting-eksempel.tld), hvis A-record peger tilbage på den samme IP. MTA'en rapporterer med præcis dette navn. Jeg sørger for, at SMTP TLS-certifikat matcher HELO-navnet (SNI, hvis der serveres flere navne). For hvert afsenderdomæne sikrer jeg også, at SPF/DKIM/DMARC er fuldt og korrekt afstemt - den delte IP alene påvirker ikke DMARC, så længe autentificeringen er effektiv.

For dedikerede afsendere (f.eks. transaktionsmail vs. marketing) kan jeg godt lide at adskille dem via subdomæner og eventuelt deres egne IP'er. Dette hjælper med Håndtering af omdømmeforenkler evalueringen af DMARC-rapporter og minimerer gensidig interferens.

Overvågning og udrulning i praksis

For at sikre problemfri drift kombinerer jeg kontinuerlig DMARC-analyse med klare trin for udrulning:

• Baseline: 2-4 uger p=ingenindsamle alle samlede rapporter (rua), identificere fejlkilder.
• OprydningFjern uautoriserede afsendere, ryd op i SPF-inkluderinger, aktiver DKIM på alle legitime systemer.
• PåklædningMed pct. gradvist til karantæneSenere afvise stigning, mål effekten som en procentdel.
• AdvarselDefiner tærskelværdier (nye IP'er, fejlrate pr. udbyder, nye fra domæner) og opsæt notifikationer.
• DokumentationHold selectors, TTL, key runtimes, SPF-budget og ansvarsområder under versionskontrol.

Jeg tjekker Budget for SPF-opslag (maks. 10 mekanismer med DNS-forespørgsler) og konsolidere inkluderer. Kritiske mekanismer som f.eks. ptr eller +alle Jeg bruger dem generelt ikke; ip4/ip6, a, mx og målrettet inkludere forbliver det foretrukne middel. Det er sådan, jeg holder opsætningen stabil og kontrollerbar.

Hurtigt tjek for hvert domæne

I slutningen af hver installation kører jeg en fast Tjek igennem: SPF-post tilgængelig, opslagsbudget under ti, mekanismer korrekt sorteret, -alle Aktiv. DKIM-signatur gyldig, selector dokumenteret, nøglelængde tilstrækkelig, rotation planlagt. DMARC med gyldig TXT-post, streng tilpasning, rapporteringspostkasser tilgængelige og arkiverede. Vis testmails spf=pass, dkim=pass og dmarc=pass i overskriften. Jeg bruger denne sekvens til at holde opsætningerne reproducerbare og Lav fejl.

Praktisk oversigt til hurtig succes

Jeg starter hvert projekt med en klar StandarderHold SPF slank, aktiver DKIM for hver afsender og udrul DMARC med rapportering. Dette efterfølges af to til fire ugers overvågning for at lukke blinde vinkler og stramme retningslinjerne. Jeg integrerer eksterne tjenester på en kontrolleret måde, dokumenterer inklusioner og holder opslagsbudgettet under kontrol. Jeg bruger DNS-skabeloner til flere domæner og planlægger rotationer af DKIM-nøgler for at holde signaturerne friske. Jeg opsummerer nyttige praktiske ideer og fejlfindingstips i min Tips til Plesk 2025 sammen, så du kan opretholde en stærk Leveringsevne nå.