SPF, DKIM en DMARC voor uw afzenderdomein begrijpen
Begrijp welke rol SPF, DKIM en DMARC spelen bij uw afzenderdomein. Bereid een veilige configuratiecontrole voor zonder inboxgaranties of kant-en-klare DNS-records.
.jpg){kind=link}
In dit artikel
SPF, DKIM en DMARC helpen ontvangende mailservers beoordelen of een bericht namens uw domein mag worden verstuurd. SPF controleert toegestane verzendbronnen, DKIM controleert een domeinhandtekening en DMARC verbindt zulke controles met het zichtbare afzenderdomein. Samen vormen ze domeinauthenticatie, geen garantie op een plaats in de inbox.
Begin met een inventaris van alle systemen die namens uw organisatie mailen. Pas daarna beoordeelt u de DNS-instellingen en een geschikt beleid. Kopieer geen voorbeeldrecord rechtstreeks naar uw echte domein: de juiste waarden hangen af van uw verzenddiensten en bestaande configuratie.
Maak eerst een verzendinventaris
Noteer welke systemen uw domein gebruiken: gewone zakelijke mail, facturatie, formulieren, accountmeldingen en nieuwsbrieven. Leg per systeem vast wie het beheert, welk adres zichtbaar is en welk domein technisch voor de verzending wordt gebruikt.
Vergeet oude systemen niet. Een strenger beleid kan gewenste mail raken wanneer een nog gebruikte dienst ontbreekt. Laat onbekende verzendbronnen onderzoeken in plaats van ze automatisch toe te voegen.
Maak ook onderscheid tussen transactionele en marketingmail. Dat helpt verantwoordelijkheden en risico’s afbakenen. De technische authenticatie maakt een bericht niet juridisch transactioneel en geeft geen toestemming om naar een bepaald adres te mailen.
Wat SPF daadwerkelijk controleert
SPF, beschreven in RFC 7208, laat een domeineigenaar aangeven welke verzendbronnen voor een bepaalde SMTP-identiteit zijn toegestaan. Dat is niet simpelweg de naam die een lezer in zijn mailbox ziet.
Een provider geeft doorgaans instructies voor uw concrete opzet. Controleer of er al een SPF-record bestaat voordat u iets toevoegt. Meerdere losse SPF-beleidsrecords voor dezelfde naam zijn niet de bedoelde manier om bronnen samen te voegen.
SPF kent een grens voor DNS-opzoekingen die door bepaalde mechanismen en modifiers worden veroorzaakt. Dat is niet hetzelfde als “tien adressen” of “tien TXT-records”. Laat een beheerder de volledige keten beoordelen, inclusief verwijzingen naar andere diensten.
Doorsturen kan bovendien invloed hebben op SPF. Een mislukte SPF-controle betekent daarom niet zonder meer dat iedere betrokken mail kwaadaardig is.
Wat DKIM toevoegt
DKIM, beschreven in RFC 6376, gebruikt een cryptografische handtekening met een domeinidentiteit. De publieke sleutel wordt via DNS beschikbaar gemaakt. De private sleutel hoort beschermd te blijven bij het verzendende systeem.
DKIM versleutelt de mailinhoud niet. Het zegt ook niet dat de boodschap waar, gewenst of veilig is. Het helpt de ontvanger controleren of de ondertekende inhoud volgens de DKIM-regels bij de gebruikte domeinhandtekening past.
Werk met de selectors en sleutels die uw dienst voorschrijft. Een selector maakt onder meer onderscheid tussen sleutels mogelijk. Leg vast wie sleutelwijzigingen en intrekking beheert. Verwijder niet zomaar een oude sleutel wanneer nog ondertekende berichten onderweg kunnen zijn.
Hoe DMARC de domeinen verbindt
DMARC, beschreven in RFC 7489, gebruikt het domein in de zichtbare From-header als referentie. Een bericht kan DMARC doorstaan wanneer een geslaagde SPF- of DKIM-controle ook aan de vereiste domeinafstemming voldoet.
Die afstemming heet alignment. “SPF geslaagd” is dus niet altijd hetzelfde als “DMARC geslaagd”. Het technische afzenderdomein en het zichtbare domein kunnen verschillen. Laat de beheerder de gekozen strikte of ruimere afstemmingsregels uitleggen.
Een DMARC-beleid kan ontvangers vragen om niets bijzonders te doen, berichten apart te behandelen of te weigeren wanneer ze niet voldoen. Ontvangers passen hun eigen beleid toe. Een reject-beleid voorkomt ook niet iedere vorm van misleiding, zoals een vergelijkbare domeinnaam of misbruik van alleen een weergavenaam.
Een fictieve inventaris vóór een wijziging
Adviesgroep Hazelaar is een verzonnen organisatie. Het gebruikt in dit oefenvoorbeeld drie systemen: zakelijke mail, facturatie en een nieuwsbriefdienst. Er is geen echte DNS-controle uitgevoerd.
De beheerder ontdekt dat de nieuwsbriefdienst wel een DKIM-handtekening heeft, maar met een domein dat niet aansluit op het zichtbare afzenderdomein. Hij beoordeelt daarom de domeinconfiguratie van die dienst voordat hij een strenger DMARC-beleid overweegt.
Bij de facturatie staat een oude verzendbron in de documentatie. Het team vraagt eerst na of die nog nodig is. Het voegt de bron niet voor de zekerheid toe en verwijdert ze evenmin zonder onderzoek.
Dit voorbeeld geeft geen kant-en-klaar record. Het laat zien waarom inventaris, bewijs en wijzigingsvolgorde belangrijker zijn dan drie losse vinkjes in een dashboard.
Voer wijzigingen gecontroleerd uit
Laat DNS-wijzigingen uitvoeren door iemand die de bestaande configuratie begrijpt. Bewaar de vorige instellingen en een herstelplan. Houd rekening met caching en met de tijd die wijzigingen nodig kunnen hebben om zichtbaar te worden.
Controleer een ontvangen testbericht uit ieder geautoriseerd systeem. Kijk naar de daadwerkelijke authenticatieresultaten en domeinen. Een providerstatus “geverifieerd” is nuttig, maar vervangt niet de controle van de verzonden route.
Rapportages kunnen helpen onbekende bronnen te vinden. Beperk wie ze ontvangt en beoordeel de privacygevolgen. Vooral uitgebreidere rapportagevormen kunnen gevoelige berichtinformatie bevatten. Zet niet elke beschikbare rapportageoptie aan zonder afweging.
Houd in uw marketingdashboard technische controles apart van campagnesignalen. Een domein kan correct zijn ingericht terwijl een specifieke verzendroute nog een afwijkende identiteit gebruikt. Noteer daarom welk systeem en welk ontvangen testbericht aan de conclusie ten grondslag liggen.
Controleer na een providerwissel ook oude verwijzingen en toegangsrechten. Een dienst die niet meer wordt gebruikt, hoort niet zonder beoordeling verzendrechten te behouden. Trek rechten gecontroleerd in en beoordeel wat een herstelactie betekent. De DNS-beheerder, mailbeheerder en contracteigenaar kunnen verschillende personen zijn; leg hun rollen vooraf vast.
Verbind techniek met beheer
Wijs een eigenaar aan voor domeininstellingen, sleutels en providerwijzigingen. Neem authenticatie mee bij een mailprovider kiezen. Vraag wat u zelf beheert en wat na een migratie moet worden aangepast.
Onderzoek bezorgfouten via bounces opvolgen, zonder direct iedere fout aan SPF of DMARC toe te schrijven. Inhoud, reputatie, lijstkwaliteit en ontvangerbeleid spelen eveneens een rol.
De basis voor een nieuwsbrief met toestemming blijft apart nodig. Correcte DNS-instellingen veranderen een ongewenste mailing niet in een gewenste nieuwsbrief.
Technische bronnen en begrenzing
Dit zijn technische specificaties voor de beschreven mechanismen. Controleer bij implementatie ook actuele standaarden en de concrete documentatie van uw dienst. Dit artikel is geen DNS-audit of afleveringstest.