Så här konfigurerar du SPF, DKIM och DMARC korrekt i Plesk

I den här guiden visar jag dig steg för steg hur du SPF DKIM och DMARC i Plesk så att dina e-postmeddelanden autentiseras på ett tillförlitligt sätt. Du får tydliga rutiner för DNS-poster, Plesk-switchar och testmetoder med vilka du kan öka leveransbarheten och blockera oseriösa avsändare.

Centrala punkter

• SPF avgör vilka system som har behörighet att skicka e-post för din domän.
• DKIM signerar utgående meddelanden och skyddar mot manipulation.
• DMARC länkar SPF/DKIM med riktlinjer och rapporter.
• Plesk tillhandahåller guider och DNS-mallar för en snabb start.
• Övervakning av DMARC-rapporterna skärper din policy i drift.

Kontrollera förutsättningarna i Plesk

Innan jag gör några inställningar kontrollerar jag den mailserver som används i Plesk och DNS-hantering. På Linux arbetar jag vanligtvis med Postfix, på Windows med SmarterMail, eftersom dessa tjänster tillhandahåller SPF-, DKIM- och DMARC-funktioner. Jag kontrollerar också om domänen har sina DNS-zoner i Plesk DNS eller hos en extern leverantör, eftersom jag då kan hantera posterna utanför Plesk måste läggas till. För att det ska fungera smidigt håller jag värdnamnet, omvänd DNS och giltiga TLS-certifikat rena, eftersom leveransservrar kontrollerar dessa punkter. En ren startpunkt sparar mycket tid senare och stärker Rykte.

Konfigurera SPF i Plesk - steg för steg

För att komma igång öppnar jag "Verktyg och inställningar" → "DNS-inställningar" och söker efter en TXT-post som börjar med v=spf1 börjar. Om det saknas sätter jag på det, till exempel: v=spf1 a mx include:yourmailprovider.de -allså att behöriga system tillåts skicka och alla andra blockeras. Om domänen använder ytterligare avsändare, t.ex. Microsoft 365, Google Workspace eller nyhetsbrevstjänster, lägger jag till lämpliga inkludera-mekanismer från deras dokumentation. Efter att ha sparat låter jag det ta upp till 48 timmar för ändringen att träda i kraft globalt och testar posten med en SPF-kontrollant via ett testmeddelande till en vald brevlåda. Du kan hitta en kompakt klassificering av mekanismernas interaktion i kompakt guidesom förklarar de viktigaste scenarierna.

Aktivera DKIM i Plesk - så här går du tillväga

För DKIM Jag går till "Verktyg & inställningar" → "Inställningar för e-postserver" och aktiverar alternativet att signera utgående e-post. Sedan öppnar jag "Websites & Domains" på domännivå → Domän → "Mail" → "Inställningar" och kontrollerar om signeringen är aktiverad för varje domän. Om jag hanterar DNS externt exporterar jag data från Plesk genererade publika DKIM-nycklar och anger dessa som TXT-poster hos DNS-leverantören (notera väljarnamnet). Efter maximalt 24-48 timmar bör mottagarna validera DKIM-signaturerna, vilket jag bekräftar genom att skicka ett testmail till en DKIM-kontrollbrevlåda eller en header-kontroll. En giltig signatur stärker Leveransförmåga märkbar.

Definiera DMARC-policy och användningsrapporter

Nu ställer jag in DMARC som TXT-post på _dmarc.yourdomain.tld med värdet v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Taggarna p, rua och samtal kontrollpolicy och rapportering, medan adkim/aspf definiera den strikta anpassningen (strikt). I praktiken börjar jag ofta med p=ingenutvärdera rapporterna i två till fyra veckor och sedan utarbeta karantän eller . avvisa på. Rapporterna visar vilka system som skickar e-post för din räkning och var SPF eller DKIM misslyckas, vilket gör det möjligt att göra direkta korrigeringar. En mer detaljerad sekvens av steg beskriver DMARC-implementering med konkreta exempel.

DNS-propagering, tester och bästa praxis

Varje DNS-ändring tar tid, så jag planerar upp till 48 timmar för globala DNS-ändringar. Förökning på. I den här fasen skickar jag testmeddelanden till externa brevlådor och kontrollerar autentiseringsresultaten i rubriken för spf=pass, dkim=pass och dmarc=pass. Om en försändelse får en softfail eller . NeutralJag kontrollerar SPF-mekanismerna, DKIM-väljarna och kuvertet från (returvägen) för anpassning till From:. När jag använder omdirigeringar övervakar jag DMARC-resultaten, eftersom SPF ofta bryts där; DKIM kompenserar vanligtvis för detta. Jag undviker ~all permanent och för produktiva inställningar förlitar sig konsekvent på -all.

DMARC-taggar och -värden - kompakt tabell

Jag använder följande översikt för att DMARC snabbt och tillförlitligt och för att undvika feltolkningar. Jag håller värdena konsekventa över huvud- och underdomäner och dokumenterar ändringar på ett spårbart sätt. För produktiva domäner ställer jag in strikt anpassning och aktiverar alltid aggregerade rapporter. Forensiska rapporter (samtal) Jag planerar i enlighet med dataskyddsbestämmelserna. Genom att fastställa tydliga riktlinjer stabiliseras Rykte av domänen.

Dag	Betydelse	Möjliga värden	Rekommendation
p	Policy för huvuddomän	ingen, karantän, avvisa	Börja med ingen, öka sedan till avvisa
sp	Policy för underdomäner	ingen, karantän, avvisa	sp=reject för produktiva inställningar
rua	Samlade rapporter	mailto:adresse	Använd din egen rapporteringsadress
samtal	Rättsmedicinska rapporter	mailto:adresse	Aktivera endast vid behov
adkim	DKIM-anpassning	r (avslappnad), s (strikt)	adkim=s för tydlig tilldelning
aspf	SPF:s anpassning	r (avslappnad), s (strikt)	aspf=s för färre falsklarm
procent	Procent av ansökan	0-100	Steg-för-steg-åtstramning med pct

Integrera externa avsändare: Microsoft 365, Google, nyhetsbrevstjänster

Om en domän använder ytterligare leveransvägar lägger jag till SPF-inkluderingar för Microsoft 365, Google Workspace, Mailgun, SendGrid eller nyhetsbrevsverktyg exakt enligt dokumentationen. För varje tjänst kontrollerar jag om en separat DKIM-nyckel är aktiv och om from-domänen verkligen är signerad. Jag undviker duplicerade eller för många inkludera-kaskader, eftersom SPF är begränsat till tio DNS-uppslagningar. Om budgeten för uppslagningar inte räcker till konsoliderar jag avsändare eller flyttar enskilda flöden till underdomäner med en egen DMARC-policy. Det är så jag håller SPF smalt och säkrar Underskrifter från.

Fördjupade kontroller och val av server

För inkommande e-post aktiverar jag i Plesk kontrollerar SPF, DKIM och DMARC så att servern filtrerar skräppost i ett tidigt skede. På Linux är dessa kontroller tillgängliga som standard, medan de på Windows implementeras med SmarterMail. Jag ser till att e-postservern uppdateras ordentligt så att signaturrutiner och parsers är uppdaterade. Om det finns problem med falska positiva meddelanden justerar jag tröskelvärdena för poängsättning, men aldrig Policy på din egen domän. På så sätt håller jag skyddet högt och säkerställer leverans från legitima avsändare.

Vanliga fel och snabba lösningar

Möten "SPF permerror" är det vanligtvis ett syntaxfel eller så har uppslagsgränsen överskridits. Om DKIM misslyckas kontrollerar jag selector, public key record och avslutningen av TXT-värdet med korrekta inverterade kommatecken. Om DMARC misslyckas misslyckasJag kontrollerar först anpassningen: From-Domain, Return-Path och DKIM-d= måste matcha perfekt. Om SPF bryts med omdirigeringar förlitar jag mig på DKIM och hålla signaturstatusen stabil. Jag använder den här sekvensen för att lösa de flesta leveransproblem utan att behöva leta länge.

DNS-mallar och automatisering i Plesk

Om jag hanterar många domäner ställer jag in DNS-mall i Plesk och lagrar standardposter för SPF, DKIM och DMARC där. Nya domäner får omedelbart stabila standardvärden som jag bara behöver finjustera. Jag implementerar också planerade förändringar, t.ex. striktare DMARC för hela domänen, med hjälp av mallar och skript. För rotationer av DKIM-nycklarna arbetar jag med två väljare så att jag kan göra gradvisa ändringar. Detta gör att operationen förblir konsekvent över dussintals domäner och underhållsbar.

Utvärdera DMARC-rapporter och skärp policyn

Efter driftsättningen analyserar jag dagligen aggregerade rapporter och identifierar Källorsom skickar på domänens vägnar utan tillstånd. Jag blockerar oväntade IP-adresser och rensar upp i föråldrade verktyg innan jag skärper policyn. Förändringen från p=ingen på karantän och senare på avvisa Jag utför med procent i etapper så att jag kan mäta effekterna på ett kontrollerat sätt. Om legitima avsändare förekommer i den misslyckade rapporten korrigerar jag SPF-inkluderingar eller aktiverar min egen DKIM-nyckel. Den här rutinen stärker Rykte synlig och minskar risken för spoofing.

Förstå inriktning på rätt sätt

Så att DMARC Jag säkerställer konsekvent korrekt uppriktning. Med SPF är domänen i kuvertet från (returväg) eller HELO/EHLO-identiteten, som måste matcha den synliga från-domänen (strikt: identisk, avslappnad: samma organisationsdomän). Med DKIM Jag kontrollerar d=-attribut för signaturen: Den måste peka på samma domän (strikt) eller på samma organisatoriska domän (avslappnad). I praktiken ser jag till att:

• den använda studssökvägen (retursökvägen) använder en domän som matchar från-domänen eller är avsiktligt outsourcad till en underdomän med en egen DMARC-policy,
• alla tredjepartsleverantörer domänen From tecken (DKIM), inte bara deras egen leveransdomän,
• DKIM-signaturen förblir intakt under vidarebefordran för att kompensera för SPF-avbrott.

Om justering saknas rapporterar DMARC-mottagare ett fel trots en giltig SPF/DKIM. dmarc=fail. Det är därför jag kontrollerar fälten i e-postens rubriker Autentiseringsresultat, Returväg och DKIM-parametrarna. På så sätt kan jag snabbt se om det är SPF eller DKIM som ger den rätta anpassningen och var jag behöver göra förbättringar.

Nyckelhantering och DNS parametrar

För robust DKIM-inställningar använde jag 2048-bitars nycklar. I Plesk Jag kan ställa in nyckellängden per domän; äldre 1024-bitarsnycklar dyker upp direkt. Om det behövs delar jag upp långa DKIM TXT-poster i flera segment med omvänt kommatecken så att DNS-servern levererar dem på rätt sätt. Jag definierar också meningsfulla TTL-värden: I utrullningsfaser går jag till 300-900 sekunder, produktivt använder jag 1-4 timmar. Detta gör att jag kan reagera flexibelt på förändringar utan att överbelasta cacherna.

Die Rotation Jag gör detta utan att misslyckas med två väljare:

1. Skapa en ny väljare i Plesk och publicera den publika nyckeln som TXT i DNS.
2. Byt avsändare till den nya väljaren och observera övervakningen (visa rubriker) s=ny väljare).
3. När alla flöden har konverterats tar du bort den gamla väljaren i DNS och avaktiverar den i Plesk.

Jag använder tredjepartsleverantörer där det är möjligt, delegerad DKIM-poster (t.ex. CNAME till leverantörsväljaren). Detta gör att jag kan behålla kontrollen i min zon och rotera nycklar utan att riskera driftavbrott.

Särskilda fall: Vidarebefordran, e-postlistor och gateways

I verkliga miljöer ser jag regelbundet omdirigeringar, e-postlistor eller säkerhetsgateways som skriver om e-postmeddelanden. Jag ägnar särskild uppmärksamhet åt effekterna här:

• VidarebefordranSPF bryts ofta eftersom den vidarebefordrande IP: n inte finns i SPF för avsändardomänen. Jag förlitar mig här på DKIMvilket ger innehållsskyddet. Om signaturen förblir oförändrad finns DMARC via DKIM-anpassning.
• MailinglistorMånga listor byter ämne eller sidfot och bryter därmed DKIM-signaturen. I sådana fall planerar jag en avslappnad anpassning och kontrollerar om listan använder SRS/ARC eller sina egna signaturer. Om möjligt använder jag en underdomän med en egen DMARC-policy för listor.
• SäkerhetsgatewaysGateways som signerar om meddelanden eller skriver om kuvertet-från måste vara korrekt anpassade till avsändarens domän. Jag dokumenterar deras roll och förankrar dem i SPF (ip4/ip6) eller via include så att anpassningen upprätthålls.

Möt mejl med spf=fail genom en vidarebefordran är detta inte automatiskt kritiskt så länge som dkim=pass är närvarande och DKIM-anpassningen är korrekt. Jag utvärderar helheten av autentiseringsresultaten istället för enskilda signaler isolerat.

Delade IP-adresser, HELO/EHLO och rDNS

Om flera domäner delar samma utgående IP förlitar jag mig på ren rDNS och konsekventa HELO/EHLO-namn. Den omvända pekaren pekar på ett FQDN (t.ex. mail.hosting-exempel.tld), vars A-record pekar tillbaka till samma IP. MTA rapporterar med exakt detta namn. Jag försäkrar mig om att SMTP TLS-certifikat matchar HELO-namnet (SNI om flera namn används). För varje avsändardomän ser jag också till att SPF/DKIM/DMARC är helt och korrekt anpassade - den delade IP-adressen påverkar inte DMARC så länge autentiseringen är effektiv.

För dedikerade avsändare (t.ex. transaktionell e-post kontra marknadsföring) gillar jag att separera dem via underdomäner och eventuellt egna IP-adresser. Detta hjälper till med Hantering av rykteförenklar utvärderingen av DMARC-rapporter och minimerar ömsesidig störning.

Uppföljning och utrullning i praktiken

För att säkerställa en smidig drift kombinerar jag kontinuerlig DMARC-analys med tydliga steg för utrullning:

• Baslinje: 2-4 veckor p=ingensamla in alla aggregerade rapporter (rua), identifiera felkällor.
• StädningTa bort obehöriga avsändare, rensa upp SPF-inkluderingar, aktivera DKIM på alla legitima system.
• PåklädningMed procent gradvis till karantän, senare avvisa öka, mäta effekterna i procent.
• VarningDefiniera tröskelvärden (nya IP-adresser, felfrekvens per leverantör, nya från domäner) och ställ in aviseringar.
• DokumentationHåll väljare, TTL, viktiga körtider, SPF-budget och ansvarsområden under versionskontroll.

Jag kontrollerar SPF-uppslag budget (max 10 mekanismer med DNS-förfrågningar) och konsolidera inkluderar. Kritiska mekanismer som t.ex. ptr eller . +allt Jag använder dem i allmänhet inte; ip4/ip6, a, mx och riktade inkludera förblir det valfria medlet. Det är så här jag håller installationen stabil och granskningsbar.

Snabbkontroll för varje domän

I slutet av varje installation kör jag en fast Kontrollera genom: SPF record tillgänglig, lookup budget under tio, mekanismer korrekt sorterade, -all Aktiv. DKIM-signatur giltig, väljare dokumenterad, nyckellängd tillräcklig, rotation planerad. DMARC med giltig TXT-post, strikt anpassning, rapporteringsbrevlådor tillgängliga och arkiverade. Visa testmeddelanden spf=pass, dkim=pass och dmarc=pass i sidhuvudet. Jag använder den här sekvensen för att hålla inställningarna reproducerbara och Lågt fel.

Praktisk sammanfattning för snabb framgång

Jag inleder varje projekt med tydliga StandarderHåll SPF på en låg nivå, aktivera DKIM för varje avsändare och rulla ut DMARC med rapportering. Detta följs av två till fyra veckors övervakning för att täppa till blinda fläckar och skärpa riktlinjerna. Jag integrerar externa tjänster på ett kontrollerat sätt, dokumenterar vad som ingår och håller uppslagsbudgeten under kontroll. Jag använder DNS-mallar för flera domäner och planerar rotationer av DKIM-nycklar för att hålla signaturerna färska. Jag sammanfattar användbara praktiska idéer och felsökningstips i min Plesk-tips 2025 tillsammans så att du kan upprätthålla en stark Leveransförmåga räckvidd.