SPF, DKIM en DMARC helpen ontvangende mailservers controleren of een bericht echt namens jouw domein is verstuurd. Je leest hoe de drie technieken samenwerken, welke DNS-instellingen daarbij horen en waarom een kleine fout ertoe kan leiden dat e-mail wordt geweigerd of in de spam belandt.
Waarom e-maildomeinen SPF, DKIM en DMARC nodig hebben
Een e-mail toont vaak een herkenbare afzender, maar die naam en het zichtbare e-mailadres zijn niet automatisch bewijs dat het bericht echt van die afzender komt. Kwaadwillenden kunnen het domein in het zichtbare Van-veld vervalsen en zo phishingmails versturen die betrouwbaar lijken. Ontvangende mailservers hebben daarom manieren nodig om te controleren of een bericht past bij de domeinen die erin worden gebruikt.
SPF, DKIM en DMARC gebruiken DNS-informatie om zulke controles mogelijk te maken. SPF geeft aan welke servers mail mogen versturen voor een domein. DKIM laat een verzendende server een digitale handtekening toevoegen die de ontvanger kan controleren. DMARC bouwt daarop voort: het controleert of SPF of DKIM slaagt én of het gebruikte domein overeenkomt met het domein dat de ontvanger in het Van-veld ziet. De domeineigenaar kan bovendien aangeven hoe mislukte controles behandeld moeten worden.
Deze technieken zijn geen garantie dat een bericht in de inbox belandt. Ook reputatie, inhoud, verzendvolume en het gedrag van ontvangers wegen mee. Ze maken het wel lastiger om jouw domein na te bootsen en geven ontvangende partijen bruikbare signalen over legitieme mail. Dat is belangrijk voor nieuwsbrieven, bestelbevestigingen, facturen en berichten die via externe platforms worden verstuurd.
SPF-record instellen zonder de DNS-limiet te overschrijden
SPF staat voor Sender Policy Framework. In een SPF-record, dat als TXT-record in DNS staat, vermeld je welke mailservers namens een domein mogen verzenden. Dat kunnen bijvoorbeeld de servers van je eigen mailomgeving zijn, maar ook diensten voor nieuwsbrieven, webshopmeldingen of klantenservice. Een ontvangende server vergelijkt de verzendende server met de regels in het record en bepaalt daarmee of SPF slaagt, faalt of een minder sterke uitkomst geeft.
Een domein hoort één SPF-record te hebben. Twee losse SPF-records voor hetzelfde domein kunnen een permanente fout opleveren, ook als elk record afzonderlijk logisch lijkt. Voeg nieuwe verzenddiensten daarom toe aan het bestaande record in plaats van een tweede record aan te maken. Let ook op de limiet van tien DNS-opzoekingen tijdens een SPF-controle. Mechanismen zoals include en redirect kunnen extra opzoekingen veroorzaken, soms ook via records van andere partijen. Overschrijding kan ertoe leiden dat SPF niet goed kan worden beoordeeld.
Gebruik een zachte mislukking, vaak aangeduid als softfail, niet als permanente tussenoplossing zonder vervolgplan. Die markering vraagt ontvangers doorgaans om het bericht verdacht te vinden, maar schrijft geen vaste behandeling voor. Een harde mislukking is strikter en kan legitieme mail blokkeren als een verzendserver ontbreekt. Controleer vóór wijzigingen alle verzendbronnen, inclusief oude systemen en applicaties. Een SPF-record dat alleen de reguliere mailboxprovider noemt, kan bijvoorbeeld bestelbevestigingen van een webshop onbedoeld laten falen.
DKIM-handtekeningen en selectors correct publiceren
DKIM, voluit DomainKeys Identified Mail, voegt een digitale handtekening toe aan een uitgaande e-mail. De verzendende dienst gebruikt daarvoor een privésleutel; de bijbehorende publieke sleutel staat in DNS. De ontvangende mailserver haalt die publieke sleutel op en controleert of de handtekening bij het bericht past. In de handtekening staat onder meer een domeinvermelding, aangeduid met d=, en een selector die de juiste DNS-sleutel aanwijst.
Een selector maakt het mogelijk meerdere sleutels naast elkaar te gebruiken. Zo kan een organisatie een nieuwe sleutel publiceren, de verzenddienst laten overschakelen en pas daarna de oude sleutel verwijderen. De selector is vaak herkenbaar aan een dienstnaam of een datum, maar de precieze naam hangt af van de mailprovider. De publieke sleutel moet precies op de DNS-naam staan die de dienst opgeeft. Een typefout, verkeerd recordtype of onvolledig geplakte sleutel kan de controle laten mislukken.
DKIM controleert niet of de inhoud betrouwbaar of gewenst is; het controleert de handtekening en de onderdelen van het bericht die zijn ondertekend. Wijzigingen onderweg kunnen daardoor problemen geven. Een mailingplatform dat de inhoud na ondertekening aanpast, of een systeem dat berichten opnieuw opmaakt, kan de controle ongeldig maken. Vraag daarom na het inschakelen een testbericht op en controleer in de berichtheaders of DKIM slaagt en welk domein de handtekening gebruikt. Een provider kan meerdere verzendstromen met eigen selectors aanbieden; activeer ze allemaal als je ze daadwerkelijk gebruikt.
DMARC-beleid kiezen: none, quarantine of reject
DMARC staat voor Domain-based Message Authentication, Reporting and Conformance. Het record vertelt ontvangende mailservers hoe ze berichten moeten behandelen die niet aan de DMARC-controle voldoen. Het staat als TXT-record op een specifieke DNS-naam voor het domein. De beleidskeuze begint meestal met none: ontvangende partijen vragen dan niet om berichten op basis van DMARC af te wijzen of in quarantaine te plaatsen, maar kunnen wel rapporten sturen.
Quarantine vraagt om mislukte berichten als verdacht te behandelen, bijvoorbeeld door ze in spam te plaatsen. Reject is strenger: de ontvanger wordt gevraagd zulke berichten niet af te leveren. Dat kan domeinmisbruik beperken, maar een strenge instelling is riskant als er nog een legitieme verzenddienst buiten beeld is. Denk aan een oud facturatiesysteem dat slechts af en toe mail verstuurt. Zo’n systeem valt mogelijk pas op wanneer klanten berichten missen.
DMARC kan rapportageadressen bevatten voor geaggregeerde rapporten. Die rapporten geven inzicht in bronnen die namens het domein verzenden en laten zien of SPF en DKIM slagen en uitlijnen. Ze zijn doorgaans XML-bestanden en kunnen omvangrijk zijn; gebruik een geschikte parser of rapportagedienst om ze leesbaar te maken. Sommige ontvangers sturen geen rapporten, dus afwezigheid ervan bewijst niet dat alles goed staat. Gedetailleerde foutmeldingen zijn bovendien niet overal beschikbaar en kunnen privacygevoelige informatie bevatten. Begin daarom met een beleid dat inzicht oplevert, controleer de bronnen en verhoog de strengheid pas wanneer legitieme mail goed wordt herkend.
DMARC-alignment: waarom een geslaagde SPF-controle soms niet genoeg is
Een belangrijk DMARC-begrip is alignment, oftewel overeenstemming tussen domeinen. De ontvanger vergelijkt het domein in het zichtbare Van-veld met het domein dat SPF of DKIM heeft gecontroleerd. DMARC slaagt wanneer minstens één van die controles slaagt én het gecontroleerde domein volgens de gekozen regels overeenkomt met het zichtbare afzenderdomein. Een bericht kan dus SPF-technisch slagen en toch DMARC niet halen als SPF een ander domein controleert.
SPF controleert meestal het domein uit het envelope-from-adres: het technische afzenderadres dat mailservers gebruiken voor bezorging en foutmeldingen. Dat adres is niet noodzakelijk hetzelfde als het adres in het Van-veld. DKIM gebruikt het domein uit de handtekening. Een externe nieuwsbriefdienst kan bijvoorbeeld mail versturen via haar eigen technische domein, terwijl de nieuwsbrief jouw merkdomein als zichtbare afzender toont. Zonder passende domeinafstemming kan DMARC dan mislukken.
DMARC kent een ontspannen en een strikte vorm van alignment. In de ontspannen vorm kunnen domeinen die onder hetzelfde hoofddomein vallen als passend worden beschouwd. De strikte vorm vereist een exacte overeenkomst en biedt daardoor meer controle, maar vraagt om nauwkeuriger ingerichte verzendstromen. Voor veel organisaties is ontspannen alignment een praktische start, zeker als meerdere subdomeinen of platforms betrokken zijn. Kijk per dienst of SPF-alignment, DKIM-alignment of beide haalbaar zijn. DKIM-alignment is vaak nuttig wanneer mail wordt doorgestuurd, omdat de SPF-controle daar kan breken. Het is niet verstandig om alignment strenger te zetten voordat alle legitieme afzenders zijn getest.
E-mailauthenticatie veilig invoeren en DNS-wijzigingen testen
Een veilige invoering begint met een inventarisatie, niet met het kopiëren van een voorbeeldrecord. Noteer iedere dienst die mail kan versturen met jouw domein: reguliere mailboxen, webshops, CRM-systemen, marketingplatforms, boekhoudsoftware en applicaties die automatisch meldingen versturen. Vraag per dienst welke SPF-regels en DKIM-records nodig zijn en welk domein wordt gebruikt voor zichtbare afzender, envelope-from en handtekening. Een afzender die slechts enkele keren per jaar wordt gebruikt, is gemakkelijk over het hoofd te zien.
Controleer daarna de bestaande DNS-records en wijzig ze in kleine stappen. Voeg ontbrekende SPF-bronnen toe aan het bestaande record en publiceer DKIM-sleutels exact volgens de instructies van de dienst. Begin DMARC desgewenst met een monitorend beleid, zodat je rapporten kunt bekijken voordat je ontvangers vraagt berichten af te wijzen. Houd bij wie de wijzigingen heeft gedaan, welke dienst bij welk record hoort en wanneer oude sleutels of verwijzingen veilig kunnen worden verwijderd. Dat voorkomt dat een latere opschoning een nog actieve verzendstroom onderbreekt.
DNS-wijzigingen zijn niet altijd onmiddellijk overal zichtbaar. De TTL bepaalt mede hoelang eerdere antwoorden in caches kunnen blijven staan. Test daarom niet alleen door het record in een beheerpaneel te bekijken: vraag DNS op bij een resolver en verstuur testberichten via iedere belangrijke route. Controleer de headers op resultaten voor SPF, DKIM en DMARC, en test ook berichten naar verschillende grote mailboxproviders. Let bij uitrol op foutmeldingen, bounces en spamplaatsing. Een wijziging die op één testadres werkt, bewijst nog niet dat alle ontvangers dezelfde uitkomst zien.
Doorgestuurde e-mail en externe platforms als lastige uitzonderingen
Doorgestuurde e-mail is een bekende uitdaging voor SPF. SPF controleert het IP-adres van de server die het bericht bij de ontvanger aflevert. Bij doorsturen is dat vaak de server van de tussenliggende partij, niet de oorspronkelijke verzendserver. Omdat die tussenpartij meestal niet in het SPF-record van de oorspronkelijke afzender staat, kan SPF falen. Sommige doorstuurdiensten passen Sender Rewriting Scheme toe: het envelope-from-adres wordt dan aangepast zodat de doorstuurserver voor dat aangepaste domein kan slagen. Dat lost niet automatisch alle DMARC-problemen op, omdat het zichtbare afzenderdomein hetzelfde blijft.
DKIM kan bij doorsturen vaker intact blijven, omdat de handtekening aan het bericht is gekoppeld en niet aan het IP-adres van de laatste server. Toch kan een tussenpartij het bericht aanpassen, bijvoorbeeld door een onderwerpregel te veranderen, een waarschuwing toe te voegen of de inhoud opnieuw op te maken. Als zo’n wijziging onderdelen raakt die door DKIM zijn ondertekend, kan de handtekening ongeldig worden. Daarom helpt een correct uitgelijnde DKIM-handtekening vaak, maar het is geen garantie voor elke doorstuurroute.
Externe platforms vragen om vergelijkbare aandacht. Een dienst kan een eigen DKIM-domein gebruiken of een aangepast subdomein aanbieden dat bij jouw merk hoort. Volg de verificatiestappen van de leverancier en controleer na activatie of het domein in de DKIM-handtekening werkelijk aansluit op jouw DMARC-domein. Verwijder een oude dienst niet alleen uit SPF omdat het contract is beëindigd: controleer eerst of er nog berichten, retries of historische systemen via die route lopen. Andersom is het onveilig om ongebruikte afzenders onbeperkt te laten staan; een vergeten platform kan later een zwakke plek vormen.
Fouten in SPF, DKIM en DMARC opsporen met headers en rapporten
Wanneer een bericht niet aankomt, begin dan met vaststellen waar het misgaat. Een bouncebericht kan aangeven of de ontvangende server het bericht direct heeft geweigerd, terwijl de spammap laat zien dat het wel is afgeleverd maar anders is geclassificeerd. Bekijk vervolgens de volledige berichtheaders. Daarin staan vaak authenticatieresultaten zoals SPF, DKIM en DMARC, inclusief het domein waarop de controle betrekking had. Alleen de regel die zegt pass of fail is niet genoeg: controleer ook of het gecontroleerde domein overeenkomt met het zichtbare afzenderdomein.
Bij SPF-fouten zijn veelvoorkomende oorzaken een ontbrekende verzenddienst, meerdere SPF-records of te veel DNS-opzoekingen. Bij DKIM zijn een verkeerde selector, een verkeerd geplaatste publieke sleutel en wijzigingen aan het bericht veelvoorkomende verklaringen. Een DMARC-fout kan ontstaan doordat zowel SPF als DKIM faalt, maar ook doordat beide slagen op een domein dat niet aligned is. Controleer de exacte DNS-naam en het recordtype; een correct ogende tekst op de verkeerde hostnaam helpt de ontvangende server niet.
Geaggregeerde DMARC-rapporten helpen terugkerende patronen te herkennen. Vergelijk verzend-IP’s en domeinen met je inventaris: een onbekende bron kan een vergeten applicatie zijn, maar ook misbruik van je domein. Beoordeel wijzigingen over meerdere verzenddagen, omdat sommige systemen onregelmatig mailen. Gebruik geen enkel testresultaat als enige bewijs en verander niet tegelijk SPF, DKIM en DMARC zonder vast te leggen wat is aangepast. Door één oorzaak per keer te onderzoeken, kun je zien of een correctie werkt of een nieuw probleem heeft veroorzaakt. Controleer na een DNS-aanpassing ook de zichtbare publieke records, niet alleen de configuratie in het dashboard van een leverancier.