Hoe SPF, DKIM en DMARC correct configureren in Plesk

In deze gids laat ik je stap voor stap zien hoe je SPF DKIM en DMARC in Plesk, zodat uw e-mails betrouwbaar worden geverifieerd. U krijgt duidelijke procedures voor DNS-vermeldingen, Plesk-switches en testmethoden waarmee u de deliverability kunt verhogen en onrechtmatige afzenders kunt blokkeren.

Centrale punten

• SPF bepaalt welke systemen gemachtigd zijn om e-mails voor je domein te verzenden.
• DKIM ondertekent uitgaande berichten en beschermt tegen manipulatie.
• DMARC koppelt SPF/DKIM met richtlijnen en rapporten.
• Plesk biedt wizards en DNS-sjablonen voor een snelle start.
• Controle van de DMARC-rapporten scherpt je beleid aan.

Controleer de vereisten in Plesk

Voordat ik instellingen maak, controleer ik de mailserver die wordt gebruikt in Plesk en DNS-beheer. Op Linux werk ik meestal met Postfix, op Windows met SmarterMail, omdat deze services SPF-, DKIM- en DMARC-functies bieden. Ik controleer ook of het domein zijn DNS-zones in de Plesk DNS heeft of bij een externe provider, omdat ik dan de entries kan beheren buiten Plesk moet worden toegevoegd. Voor een soepele werking houd ik de hostnaam, reverse DNS en geldige TLS-certificaten schoon, omdat afleverservers deze punten controleren. Een schoon startpunt bespaart later veel tijd en versterkt de Reputatie.

SPF instellen in Plesk - stap voor stap

Om te beginnen open ik "Tools & Settings" → "DNS Settings" en zoek naar een TXT-record dat begint met v=spf1 begint. Als het ontbreekt, doe ik het bijvoorbeeld aan: v=spf1 a mx include:yourmailprovider.de -allzodat geautoriseerde systemen mogen verzenden en alle andere worden geblokkeerd. Als het domein extra afzenders gebruikt, zoals Microsoft 365, Google Workspace of nieuwsbriefdiensten, voeg ik de juiste opnemen-mechanismen uit hun documentatie. Na het opslaan laat ik de wijziging maximaal 48 uur inwerken en test ik het record met een SPF-checker via een testmail naar een geselecteerde mailbox. Je kunt een compacte indeling van de interactie van de mechanismen vinden in de compacte gidswaarin de belangrijkste scenario's worden uitgelegd.

DKIM activeren in Plesk - zo gaat u te werk

Voor DKIM Ik ga naar "Tools & Settings" → "Mail server settings" en activeer de optie om uitgaande e-mails te ondertekenen. Vervolgens open ik "Websites & domeinen" op domeinniveau → Domein → "Mail" → "Instellingen" en controleer of ondertekening is ingeschakeld voor elk domein. Als ik DNS extern beheer, exporteer ik de gegevens van Plesk gegenereerde DKIM publieke sleutels en voer deze in als TXT-records bij de DNS-provider (let op de selectornaam). Na maximaal 24-48 uur moeten ontvangers de DKIM handtekeningen valideren, wat ik bevestig door een testmail naar een DKIM check mailbox of een header check te sturen. Een geldige handtekening versterkt de Bezorgbaarheid merkbaar.

DMARC-beleid definiëren en rapporten gebruiken

Nu stel ik DMARC als TXT-record op _dmarc.uwdomein.tld met de waarde v=DMARC1; p=quarantaine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. De tags p, rua en bel controlebeleid en rapportage, terwijl adkim/aspf definieer de strikte uitlijning (strict). In de praktijk begin ik vaak met p=geentwee tot vier weken rapporten evalueren en vervolgens quarantaine of afwijzen . De rapporten laten zien welke systemen namens jou mails versturen en waar SPF of DKIM faalt, waardoor direct correcties kunnen worden doorgevoerd. Een uitgebreidere reeks stappen beschrijft de DMARC-implementatie met concrete voorbeelden.

DNS-propagatie, tests en best practices

Elke DNS-wijziging kost tijd, dus ik plan tot 48 uur voor globale DNS-wijzigingen. Propagatie aan. In deze fase stuur ik testmails naar externe mailboxen en controleer ik de authenticatieresultaten in de header voor spf=pas, dkim=pas en dmarc=pass. Als een e-mail een softfail of NeutraalIk controleer de SPF-mechanismen, de DKIM-selectors en de envelope-from (retourpad) op afstemming met From:. Als ik redirects gebruik, controleer ik de DMARC resultaten, omdat SPF daar vaak breekt; DKIM compenseert dit meestal. Ik vermijd ~all permanent en voor productieve opstellingen consequent vertrouwen op -allemaal.

DMARC tags en waarden - compacte tabel

Ik gebruik het volgende overzicht om DMARC snel en betrouwbaar en om verkeerde interpretaties te voorkomen. Ik houd de waarden consistent over hoofd- en subdomeinen en documenteer wijzigingen op een traceerbare manier. Voor productieve domeinen stel ik een strikte afstemming in en activeer ik altijd geaggregeerde rapporten. Forensische rapporten (bel) Ik plan in overeenstemming met de regelgeving voor gegevensbescherming. Het opstellen van duidelijke richtlijnen stabiliseert de Reputatie van het domein.

Dag	Dat betekent	Mogelijke waarden	Aanbeveling
p	Beleid voor hoofddomein	geen, quarantaine, afwijzen	Begin met geen, verhoog dan tot weigeren
sp	Beleid voor subdomeinen	geen, quarantaine, afwijzen	sp=afwijzen voor productieve opstellingen
rua	Samengevoegde rapporten	mailto:adresse	Gebruik je eigen meldadres
bel	Forensische rapporten	mailto:adresse	Alleen activeren indien nodig
adkim	DKIM uitlijning	r (ontspannen), s (streng)	adkim=s voor duidelijke toewijzing
aspf	SPF uitlijning	r (ontspannen), s (streng)	aspf=s voor minder valse alarmen
pct	Percentage van toepassing	0-100	Stapsgewijze aanscherping met pct

Integreer externe afzenders: Microsoft 365, Google, nieuwsbriefdiensten

Als een domein extra verzendpaden gebruikt, voeg ik de SPF toe voor Microsoft 365, Google Workspace, Mailgun, SendGrid of nieuwsbrieftools precies zoals gedocumenteerd. Voor elke service controleer ik of er een aparte DKIM-sleutel actief is en of het from-domein echt ondertekend is. Ik vermijd dubbele of te veel opnemen-cascades, omdat SPF beperkt is tot tien DNS lookups. Als het budget voor lookups niet toereikend is, consolideer ik afzenders of verplaats ik individuele streams naar subdomeinen met hun eigen DMARC-beleid. Zo houd ik SPF slank en beveilig ik de Handtekeningen van.

Grondige controles en serverselectie

Voor inkomende mails activeer ik in Plesk SPF, DKIM en DMARC controleren zodat de server spam in een vroeg stadium filtert. Op Linux zijn deze controles standaard beschikbaar, terwijl ze op Windows worden geïmplementeerd met SmarterMail. Ik zorg ervoor dat de mailserver goed wordt bijgewerkt zodat de handtekeningroutines en parsers up-to-date blijven. Als er problemen zijn met valse positieven, pas ik de scoringsdrempels aan, maar nooit de Beleid van je eigen domein. Zo houd ik de bescherming hoog en garandeer ik aflevering door legitieme afzenders.

Veelvoorkomende fouten en snelle oplossingen

Meer "SPF permerror", is er meestal een syntaxisfout of is de opzoeklimiet overschreden. Als DKIM mislukt, controleer ik de selector, het openbare sleutelrecord en de beëindiging van de TXT-waarde met correcte aanhalingstekens. Als DMARC mislukt mislukkenIk controleer eerst de uitlijning: From-Domain, Return-Path en DKIM-d= moeten perfect overeenkomen. Als SPF breekt met redirects, vertrouw ik op DKIM en de handtekeningstatus stabiel houden. Ik gebruik deze volgorde om de meeste leveringsproblemen op te lossen zonder lang te hoeven zoeken.

DNS-sjablonen en automatisering in Plesk

Als ik veel domeinen beheer, stel ik de DNS-sjabloon in Plesk en sla daar standaardrecords op voor SPF, DKIM en DMARC. Nieuwe domeinen krijgen meteen solide standaardinstellingen die ik alleen nog maar hoef bij te stellen. Ik implementeer ook geplande wijzigingen zoals strengere DMARC domeinbreed met behulp van sjablonen en scripts. Voor rotaties van de DKIM-sleutels werk ik met twee selectors zodat ik geleidelijk veranderingen kan doorvoeren. Dit houdt de werking consistent over tientallen domeinen en onderhoudbaar.

DMARC-rapporten evalueren en beleid aanscherpen

Na de go-live analyseer ik dagelijks geaggregeerde rapporten en identificeer ik Bronnendie namens het domein verzenden zonder autorisatie. Ik blokkeer onverwachte IP's en ruim verouderde tools op voordat ik het beleid aanscherp. De verandering van p=geen op quarantaine en later afwijzen Ik voer uit met pct in stappen, zodat ik de effecten op een gecontroleerde manier kan meten. Als er legitieme afzenders voorkomen in het mislukte rapport, corrigeer ik SPF includes of activeer ik mijn eigen DKIM key. Deze routine versterkt de Reputatie zichtbaar en vermindert spoofing.

Uitlijning correct begrijpen

Dus dat DMARC Ik zorg consequent voor de juiste uitlijning. Met SPF is het domein in de envelop van (retourpad) of de HELO/EHLO identiteit, die overeen moet komen met het zichtbare van domein (strikt: identiek, ontspannen: zelfde organisatiedomein). Met DKIM Ik controleer de d=-attribuut van de handtekening: Het moet verwijzen naar hetzelfde domein (strikt) of naar hetzelfde organisatiedomein (ontspannen). In de praktijk zorg ik ervoor dat:

• het gebruikte bouncepad (retourpad) een domein gebruikt dat overeenkomt met het from-domein of doelbewust is uitbesteed aan een subdomein met een eigen DMARC-beleid,
• alle externe providers het domein Van bord (DKIM), niet alleen hun eigen verzenddomein,
• de DKIM handtekening blijft intact tijdens het doorsturen om SPF onderbrekingen te compenseren.

Als uitlijning ontbreekt, melden DMARC-ontvangers een fout ondanks een geldige SPF/DKIM. dmarc=fail. Daarom controleer ik de velden in de e-mailheaders Authenticatieresultaten, Pad terug en de DKIM-parameters. Hierdoor kan ik snel herkennen of SPF of DKIM voor afstemming zorgt en waar ik verbeteringen moet aanbrengen.

Sleutelbeheer en DNS-parameters

Voor robuuste DKIM-instellingen heb ik 2048-bits sleutels gebruikt. In Plesk Ik kan de sleutellengte per domein instellen; oudere 1024-bits sleutels draai ik meteen op. Indien nodig splits ik lange DKIM TXT-records op in meerdere omgekeerde komma-segmenten zodat de DNS-server ze correct aflevert. Ik definieer ook zinvolle TTL-waarden: In uitrolfasen ga ik naar 300-900 seconden, productief gebruik ik 1-4 uur. Hierdoor kan ik flexibel reageren op veranderingen zonder de caches te overbelasten.

De Rotatie Ik doe dit zonder mislukking met twee selectors:

1. Maak een nieuwe selector in Plesk en publiceer de publieke sleutel als TXT in de DNS.
2. Verander de afzender in de nieuwe selector en observeer de monitoring (toon headers) s=nieuwe selector).
3. Zodra alle flows zijn geconverteerd, verwijdert u de oude selector in de DNS en deactiveert u deze in Plesk.

Waar mogelijk gebruik ik providers van derden, gedelegeerd DKIM-records (bijvoorbeeld CNAME naar de provider-selector). Hierdoor kan ik de controle over mijn zone behouden en sleutels rouleren zonder het risico te lopen op operationele onderbrekingen.

Speciale gevallen: Doorsturen, mailinglijsten en gateways

In echte omgevingen zie ik regelmatig redirects, mailinglijsten of beveiligingsgateways die e-mails herschrijven. Ik let hier vooral op de effecten:

• DoorsturenSPF breekt vaak af omdat het doorsturende IP niet in de SPF van het domein van de afzender staat. Ik vertrouw hier op DKIMdie de inhoud beschermt. Als de handtekening ongewijzigd blijft, bestaat DMARC via DKIM alignment.
• MailinglijstenVeel lijsten veranderen van onderwerp of voettekst en verbreken zo de DKIM-handtekening. In zulke gevallen plan ik een ontspannen uitlijning en controleer ik of de lijst SRS/ARC of zijn eigen handtekeningen gebruikt. Indien mogelijk gebruik ik een subdomein met een eigen DMARC-beleid voor lijsten.
• VeiligheidspoortenGateways die berichten opnieuw ondertekenen of de envelope-from herschrijven moeten correct worden uitgelijnd met het domein van de afzender. Ik documenteer hun rol en veranker ze in de SPF (ip4/ip6) of via include zodat de uitlijning behouden blijft.

Ontmoet mails met spf=fail via een doorsturing, is dit niet automatisch kritisch zolang dkim=pas aanwezig is en de DKIM-uitlijning correct is. Ik evalueer het geheel van de verificatieresultaten in plaats van afzonderlijke signalen afzonderlijk.

Gedeelde IP's, HELO/EHLO en rDNS

Als verschillende domeinen hetzelfde uitgaande IP-adres hebben, vertrouw ik op schone rDNS en consistente HELO/EHLO namen. De reverse pointer wijst naar een FQDN (bijv. mail.hosting-voorbeeld.tld), waarvan het A-record terugverwijst naar hetzelfde IP. De MTA rapporteert met precies deze naam. Ik zorg ervoor dat de SMTP TLS-certificaat overeenkomt met de HELO-naam (SNI als er meerdere namen worden geserveerd). Voor elk afzenderdomein zorg ik er ook voor dat SPF/DKIM/DMARC volledig en correct zijn uitgelijnd - het gedeelde IP alleen heeft geen invloed op DMARC zolang de authenticatie effectief is.

Voor specifieke afzenders (bijv. transactionele mail vs. marketing), scheid ik ze graag via subdomeinen en eventueel hun eigen IP's. Dit helpt bij Reputatiemanagementvereenvoudigt de evaluatie van DMARC-rapporten en minimaliseert wederzijdse interferentie.

Monitoring en uitrol in de praktijk

Om een soepele werking te garanderen, combineer ik continu DMARC-analyse met duidelijke stappen voor de uitrol:

• Basislijn2-4 weken p=geenverzamel alle geaggregeerde rapporten (rua), identificeer foutenbronnen.
• OpruimenVerwijder onbevoegde afzenders, ruim SPF includes op, activeer DKIM op alle legitieme systemen.
• DressingMet pct geleidelijk naar quarantainelater afwijzen toename, meet de effecten als een percentage.
• WaarschuwingDefinieer drempelwaarden (nieuwe IP's, fail rate per provider, nieuw van domeinen) en stel meldingen in.
• DocumentatieHoud selectors, TTL, sleutelruntimes, SPF-budget en verantwoordelijkheden onder versiebeheer.

Ik controleer de SPF-opzoekbudget (max. 10 mechanismen met DNS-query's) en consolideren omvat. Kritieke mechanismen zoals ptr of +all Over het algemeen gebruik ik ze niet; ip4/ip6, a, mx en doelgericht opnemen het middel bij uitstek blijven. Zo houd ik de opstelling stabiel en controleerbaar.

Snelle controle voor elk domein

Aan het einde van elke installatie voer ik een vaste Controleer door: SPF record beschikbaar, lookup budget onder de tien, mechanismen correct gesorteerd, -allemaal Actief. DKIM handtekening geldig, selector gedocumenteerd, sleutellengte voldoende, rotatie gepland. DMARC met geldig TXT-record, strikte uitlijning, rapportage-mailboxen toegankelijk en gearchiveerd. Testmails tonen spf=pas, dkim=pas en dmarc=pass in de koptekst. Ik gebruik deze volgorde om opstellingen reproduceerbaar te houden en Lage fout.

Praktische samenvatting voor snel succes

Ik begin elk project met duidelijke NormenHoud SPF mager, activeer DKIM voor elke afzender en rol DMARC uit met rapportage. Dit wordt gevolgd door twee tot vier weken monitoring om blinde vlekken te dichten en richtlijnen aan te scherpen. Ik integreer externe services op een gecontroleerde manier, documenteer inclusief en houd het lookup budget onder controle. Ik gebruik DNS-sjablonen voor verschillende domeinen en plan rotaties van DKIM-sleutels om de handtekeningen vers te houden. Nuttige praktische ideeën en tips voor probleemoplossing vat ik samen in mijn Plesk tips 2025 samen zodat je een sterke Bezorgbaarheid bereiken.