SPF versus DKIM: wat is het verschil en heb je beide nodig?

Inleiding

Veel SPF-fouten worden niet veroorzaakt door een verkeerd geconfigureerd record, maar komen doordat de e-mail is doorgestuurd.

Een IT-beheerder stelt SPF correct in, controleert of de controle slaagt en beschouwt de klus als geklaard. Vervolgens stuurt een gebruiker een bericht door via een relay van een derde partij. De ontvangende server ziet een IP-adres dat niet op de lijst met geautoriseerde adressen staat, de controle mislukt, de beheerder controleert het record en dat ziet er in orde uit. Het probleem zit niet in het record, maar in de manier waarop SPF werkt.

SPF alleen is niet voldoende voor e-mailverificatie, en SPF en DKIM dienen niet hetzelfde doel. Elk protocol beschermt een andere laag van het e-mailbezorgingsproces. Als je een van beide weglaat, ontstaan er hiaten die zowel door doorstuurinfrastructuren als door aanvallers kunnen worden misbruikt, op verschillende manieren en om verschillende redenen.

In deze blog kom je te weten wat het verschil is tussen SPF en DKIM, waarom het doorsturen van e-mails de ene wel en de andere niet verstoort, en waarom beide nodig zijn om DMARC te laten werken.

Wat is SPF en hoe werkt het?

SPF (Sender Policy Framework) is een protocol voor e-mailverificatie waarmee een domeineigenaar kan aangeven welke mailservers bevoegd zijn om namens het domein e-mails te versturen.

Het domein publiceert een SPF-record in zijn DNS als een TXT-vermelding met daarin de goedgekeurde IP-adressen en servers. Wanneer een ontvangende mailserver een bericht ontvangt, vergelijkt deze het domein van de afzender met dit gepubliceerde record om te controleren of de verzendende server is toegestaan. 

Op basis van het resultaat beslist de ontvanger of hij het bericht accepteert, markeert of afwijst. SPF is bedoeld om te voorkomen dat spammers en aanvallers het afzenderadres vervalsen, waardoor e-mailspoofing en phishing. Het werkt samen met DKIM en DMARC om de legitimiteit van berichten te verifiëren. 

Wat controleert SPF?

SPF controleert of de server die een bericht verstuurt, bevoegd is om e-mail te verzenden namens het domein waarvan hij beweert afkomstig te zijn. Dit gebeurt op het moment dat een ontvangende server de inkomende verbinding accepteert, nog voordat de inhoud van het bericht wordt verwerkt.

SPF controleert echter niet het ‘Van’-adres dat uw ontvangers daadwerkelijk te zien krijgen. Het controleert alleen de ‘envelope sender’, ook wel Return-Path of MAIL FROM genoemd, en dat is het adres dat achter de schermen wordt gebruikt tijdens de SMTP-transactie. 

Een aanvaller kan dus de SPF-controle voor het envelopdomein doorstaan en toch een vervalst ‘Van’-adres in de inbox laten zien. DMARC helpt deze lacune te dichten door het SPF-resultaat te koppelen aan het zichtbare ‘Van’-domein.

De ontvangende server heeft twee invoergegevens nodig: 

1. Het verzendende IP-adres
2. Het domein van de afzender van de e-mail

Vervolgens zoekt het het SPF-record van dat domein op in het DNS. Het doorloopt de mechanismen van het record in volgorde, zoals ip4, ip6, a, mx, en inclusief. Als het verzendende IP-adres overeenkomt met een geautoriseerde bron, slaagt de SPF-controle. Als het doorloopt tot de afsluitende alle zonder een overeenkomst, hangt de uitkomst af van hoe je dat mechanisme hebt geconfigureerd.

SPF geeft geen eenvoudig ja of nee als antwoord. Het geeft een van de volgende resultaten weer:

• Geslaagd: De server is geautoriseerd.
• Mislukt (-all): Geen toestemming. U wilt dat deze e-mail wordt geweigerd.
• SoftFail (~alle): Waarschijnlijk niet geautoriseerd. Accepteer het, maar markeer het als verdacht.
• Neutraal (?alle): Je doet geen uitspraak in welke richting dan ook.
• Geen: Er bestaat geen SPF-record voor het domein.
• PermError / TempError: Het record is beschadigd, of een DNS-probleem heeft de opzoekactie geblokkeerd.

De ontvangende server beschouwt dit resultaat als een van de signalen, naast DKIM en DMARC, om de legitimiteit van de e-mail te beoordelen voordat uw bericht wordt afgeleverd, gemarkeerd of geweigerd. 

Wat is DKIM en hoe werkt het?

DKIM (DomainKeys Identified Mail) is een authenticatieprotocol voor e-mail waarbij aan elk bericht dat een domein verstuurt een cryptografische handtekening wordt toegevoegd. De verzendende server ondertekent het bericht met een privésleutel en voegt de handtekening toe aan de header van de e-mail. Het domein publiceert de bijbehorende openbare sleutel in zijn DNS als een TXT-record. 

Wanneer een ontvangende server het bericht ontvangt, haalt deze de openbare sleutel op en controleert de handtekening. Een geldige handtekening bevestigt twee dingen: 

1. Het bericht is daadwerkelijk afkomstig van het opgegeven domein
2. De inhoud is tijdens het transport niet gewijzigd. 

DKIM is bedoeld om manipulatie en vervalsing van afzenders te voorkomen, en werkt samen met SPF en DMARC om de authenticiteit van berichten te controleren. 

Wat DKIM ondertekent

DKIM ondertekent twee onderdelen van elk bericht: een geselecteerde reeks headervelden en de berichttekst. Het ondertekent niet de envelop, het IP-adres van de verbinding of iets anders buiten deze twee onderdelen. Dat is het verschil tussen de twee protocollen: SPF controleert de envelop en de verzendende server, terwijl DKIM het bericht zelf ondertekent.

De handtekening wordt niet op de ruwe tekst aangebracht. De verzendende server berekent een hash van de berichttekst en de gekozen headers, en versleutelt die hash vervolgens met zijn privésleutel. Het resultaat wordt in de DKIM-Signature-header geplaatst, die de server aan het bericht toevoegt. Binnen die header geven een aantal tags de ontvanger precies aan wat er is ondertekend:

• h= geeft een overzicht van de headervelden die in de handtekening zijn opgenomen, zoals Van, Aan, Onderwerp en Datum.
• bh= bevat de hash van de berichttekst.
• b= bevat de handtekening zelf, de versleutelde hash van de ondertekende headers.
• c= stelt de canonieke vorm in, die bepaalt hoe strikt witruimte en opmaak moeten overeenkomen.

De From-header is altijd ondertekend. DKIM vereist dit, omdat het de bedoeling is om de handtekening te koppelen aan het domein dat de ontvanger daadwerkelijk te zien krijgt.

Alles wat niet in h= wordt vermeld, is niet beveiligd. Als een header niet in die lijst voorkomt, kan deze tijdens de overdracht worden gewijzigd zonder dat de handtekening ongeldig wordt. De hoofdtekst wordt volledig gedekt, tenzij de optionele l=-tag de ondertekening beperkt tot het eerste deel ervan; daarom wordt het gebruik van l= over het algemeen afgeraden. Alle inhoud die na de ondertekende lengte wordt toegevoegd, zou onondertekend blijven.

Wanneer een ontvangende server DKIM controleert, berekent deze de hash van de berichttekst en de hash van de header opnieuw, decodeert b= met uw gepubliceerde openbare sleutel en vergelijkt deze twee. Als beide overeenkomen, is de handtekening geldig en zijn de ondertekende delen van het bericht ongewijzigd aangekomen.

SPF versus DKIM

SPF en DKIM lossen twee verschillende problemen op. SPF bepaalt welke servers e-mail mogen versturen namens uw domein, terwijl DKIM aan de hand van een cryptografische handtekening aantoont dat een bericht niet is gewijzigd en daadwerkelijk afkomstig is van uw domein. Hier volgt een kort overzicht van de verschillen tussen SPF en DKIM.

Geen van beide protocollen weet wat het andere weet.

SPF kan bevestigen dat een bericht afkomstig is van een geautoriseerde server, maar zodra dat bericht de server heeft verlaten, heeft SPF geen zicht meer op wat ermee is gebeurd. 

Op dezelfde manier kan DKIM bevestigen dat de inhoud ongeschonden is aangekomen en dat het ondertekenende domein de beheersing had over de privésleutel, maar het zegt niets over de vraag of die server überhaupt toestemming had om het bericht te verzenden.

Dit is wat er gebeurt als een ontvangende server beide resultaten beoordeelt:

DMARC leest beide resultaten en past uw gepubliceerde beleid toe op basis van de overeenstemming met de Van domein. Daarom zijn de twee protocollen ontworpen om elkaar aan te vullen, niet om met elkaar te concurreren.

Waarom faalt SPF bij het doorsturen, maar DKIM niet?

Het SPF-doorstuurprobleem

SPF werkt niet meer wanneer een e-mail wordt doorgestuurd. Dit is een van de meest voorkomende redenen waarom een legitiem bericht de SPF-controle niet doorstaat, en het vloeit rechtstreeks voort uit de werking van het protocol.

SPF vergelijkt het IP-adres van de verbindende server met het SPF-record van het domein van de afzender van de envelop. Bij doorsturen gaat die overeenkomst verloren. Wanneer een server een bericht doorstuurt, gebeuren er drie dingen:

1. De doorstuurserver wordt het nieuwe IP-adres waarmee verbinding wordt gemaakt.
2. De afzender van de envelop verwijst nog steeds naar het domein van de oorspronkelijke afzender.
3. In het SPF-record van het oorspronkelijke domein wordt de doorstuurserver niet vermeld, waardoor de controle de status ‘Fail’ oplevert.

Stel dat een bericht van uw domein bij de eerste hop de SPF-controle doorstaat. De server van de ontvanger stuurt het vervolgens door naar een tweede adres, zoals een alumni-account of een mailinglijst. Op die tweede bestemming is het IP-adres van de verbinding nu dat van de doorstuurserver, maar in het Return-Path staat nog steeds uw domein vermeld. Uw SPF-record heeft die server nooit geautoriseerd, dus de SPF-controle mislukt, ook al is het bericht legitiem.

Dit komt het vaakst voor bij:

• Mailinglijsten
• Regels voor automatisch doorsturen op accountniveau in Gmail of Outlook
• Alumni of op functies gebaseerde doorstuuradressen
• Spamfilters en gateways die e-mail doorsturen

Er zijn twee redenen waarom doorgestuurde e-mails niet worden geweigerd:

1. SRS (Sender Rewriting Scheme): De doorstuurserver herschrijft het Return-Path naar zijn eigen domein voordat het bericht wordt doorgestuurd. SPF controleert vervolgens het domein van de doorstuurserver, dat die server wel autoriseert, dus de controle slaagt. De meeste gerenommeerde doorstuurservices passen SRS automatisch toe.
2. DKIM en DMARC: Een DKIM-handtekening blijft behouden bij doorsturen, zolang de doorstuurder de ondertekende inhoud niet wijzigt. Dus zelfs wanneer SPF faalt bij een doorgestuurd bericht, kan DKIM nog steeds slagen, en DMARC heeft slechts één van de twee nodig om te voldoen. Dit is de belangrijkste reden waarom u niet alleen op SPF moet vertrouwen.

Waarom DKIM bij doorsturen blijft werken

DKIM blijft intact bij doorsturen omdat het bericht zelf wordt ondertekend, en niet de route die het bericht aflegt. De handtekening staat in de DKIM-Signature-header en wordt dus bij elke stap meegegeven met de e-mail. Hoeveel servers het bericht ook doorsturen, de handtekening is er nog steeds wanneer het de eindbestemming bereikt.

De verificatie is ook niet afhankelijk van de server waarmee verbinding wordt gemaakt. De ontvanger haalt de openbare sleutel van het ondertekenende domein op uit de DNS van dat domein en gebruikt deze om de handtekening te controleren. Het IP-adres van de afzender is niet van belang. Dit staat haaks op SPF, dat bij doorsturen niet werkt juist omdat het het IP-adres van de verbinding controleert, en bij doorsturen verandert dat IP-adres.

Zolang de doorstuurder het bericht doorstuurt zonder de ondertekende inhoud te wijzigen, komen de hash van de hoofdtekst en de hash van de header nog steeds overeen en wordt DKIM goedgekeurd.

DKIM blijft intact bij het doorsturen van onbewerkte e-mails, maar is niet tegen alles bestand. De handtekening wordt ongeldig wanneer een tussenpersoon de ondertekende inhoud wijzigt. De meest voorkomende boosdoeners zijn mailinglijsten, die vaak:

• Voeg een voettekst of een afmeldlink toe aan de hoofdtekst
• Voeg een tag zoals [list-name] toe aan de onderwerpregel
• Kopteksten die in de handtekening staan, herschrijven of invoegen

Elke van deze wijzigingen verandert de hash, waardoor de handtekening niet langer geldig is. ARC (Authenticated Received Chain) is precies voor dit geval ontwikkeld, waarbij de oorspronkelijke authenticatieresultaten behouden blijven terwijl een bericht door tussenpersonen gaat die het wijzigen.

Daarom is DKIM van belang voor doorgestuurde e-mail in het kader van DMARC. DMARC wordt geaccepteerd als SPF of DKIM slaagt en overeenkomt met het ‘Van’-domein. Bij doorgestuurde berichten faalt SPF meestal, dus DKIM is dan de doorslaggevende factor de DMARC-overeenstemming bij elkaar houdt. Het ondertekenende domein blijft hetzelfde bij doorsturen, dus de afstemming blijft daarmee behouden. Als u alleen op SPF vertrouwt en e-mail doorstuurt vanaf uw domein, kan dit DMARC-fouten opleveren en in de spam terechtkomen.

Hoe werken SPF, DKIM en DMARC samen?

SPF en DKIM lossen elk een ander probleem op, maar geen van beide zorgt op zichzelf voor afdwinging. DMARC koppelt de resultaten van beide aan een actie en relateert beide controles aan het domein dat je ontvangers daadwerkelijk te zien krijgen.

Dit is wat er gebeurt wanneer een ontvangende server een binnenkomend bericht verwerkt:

1. SPF wordt als eerste uitgevoerd: De server leest de afzender van de envelop, de MAIL FROM -adres dat tijdens de SMTP-sessie is uitgewisseld, niet de From-header die de ontvanger ziet, en vergelijkt het verzendende IP-adres met uw SPF-record. Als het IP-adres geautoriseerd is, slaagt de SPF-controle. Zo niet, dan mislukt deze.
2. Vervolgens wordt DKIM uitgevoerd: De server leest de DKIM-Signature header, zoekt uw publieke sleutel op in DNS met behulp van de selector- en domeintags, en verifieert de cryptografische handtekening aan de hand van de inhoud van het bericht. Een geldige handtekening bevestigt dat het bericht afkomstig is van een domein dat de privésleutel beheert en dat het niet is gewijzigd tijdens het transport.
3. DMARC wordt als laatste beoordeeld: Het haalt uw polisgegevens op en controleert of deze kloppen:
   1. Komt het domein dat de SPF-controle heeft doorstaan overeen met uw afzenderdomein? 
   2. Is de d= overeen met uw 'Van'-domein? 

Als een van beide overeenkomt, wordt DMARC goedgekeurd. Uw gepubliceerde beleid bepaalt vervolgens wat er met het bericht gebeurt.

Wat afstemming in de praktijk inhoudt

SPF keurt elk domein goed dat in de afzender van de envelop staat vermeld. DKIM keurt elk domein goed met een geldige ondertekeningssleutel. Geen van beide controles op zich bevestigt de From-header, het veld waarin [email protected] in de inbox van de ontvanger staat, legitiem is. DMARC voegt die verificatie toe door het geauthenticeerde domein te vergelijken met het From-domein.

De uitlijning werkt in twee modi:

1. In de standaardmodus (de standaardinstelling) volstaat het als het domein van de organisatie overeenkomt, waarbij mail.uwbedrijf.com overeenkomt met uwbedrijf.com. 
2. In de strikte modus moeten de domeinen exact overeenkomen. De meeste organisaties kiezen voor een minder strikte afstemming, omdat de strikte modus tot bezorgingsproblemen bij subdomeinen leidt, tenzij elke verzendbron nauwkeurig is geconfigureerd.

De uitkomst van legitieme versus vervalste e-mail

Voor een correct opgesteld legitiem bericht:

• De verzendende IP komt overeen met je SPF-record → SPF-controle geslaagd
• DKIM-handtekening is geldig, d= komt overeen met uw 'Van'-domein → DKIM geslaagd
• Beide resultaten komen overeen met uw 'Van-domein → DMARC geslaagd'
• Uw p=afwijzen beleid → bericht is afgeleverd

Voor een vervalst bericht dat is verzonden vanaf een onbevoegde server zonder geldige ondertekeningssleutel:

• Ongeautoriseerd IP-adres → SPF-controle mislukt
• Geen geldige handtekening → DKIM mislukt
• Geen van beide resultaten komt overeen met uw ‘Van’-domein → DMARC-fout
• Uw p=afwijzen beleid → bericht wordt geweigerd voordat het een inbox bereikt

Daarom zijn SPF en DKIM in combinatie onder DMARC effectiever dan elk afzonderlijk. DMARC kan beide resultaten doorgeven, dus wanneer SPF faalt bij doorgestuurde e-mail, zorgt DKIM ervoor dat DMARC legitieme berichten toch doorlaat. Wanneer beide falen bij vervalste e-mail, handelt DMARC volgens uw beleid.

Zodra uw domein p=quarantaine of p=reject en zowel SPF als DKIM zijn geslaagd en op elkaar zijn afgestemd, dan voldoe je ook aan de handhavingsvoorwaarde voor BIMI, de standaard die uw geverifieerde merklogo weergeeft in ondersteunende inboxen zoals Gmail en Apple Mail.

Heb je zowel SPF als DKIM nodig?

Ja, je hebt zowel SPF als DKIM nodig. 

Een domein dat SPF gebruikt zonder DKIM beschikt niet over integriteitscontrole op berichtniveau. Er is geen manier om te controleren of de inhoud tijdens het verzenden niet is gewijzigd. Er is geen DKIM-afstemming om DMARC te ondersteunen, wat betekent dat als SPF faalt (en dat zal gebeuren bij elke doorgestuurde e-mail), DMARC geen vangnet heeft. Eén doorstuurregel tussen de zakelijke inbox van een gebruiker en zijn persoonlijke account is voldoende om de authenticatie te laten mislukken voor e-mail die volkomen legitiem was.

Google en Yahoo hebben beide maatregelen in februari 2024 verplicht gesteld.

Google vereist SPF, DKIM en een DMARC-record voor alle bulkverzenders die 5.000 of meer berichten per dag versturen. Yahoo vereist ten minste één van SPF of DKIM plus DMARC, hoewel het gebruik van slechts één daarvan betekent dat niet aan de vereisten van Google wordt voldaan. Als u berichten verstuurt naar ontvangers op beide platforms, is het configureren van beide de enige manier om in één keer aan alle vereisten te voldoen.

Zelfs onder de drempel van 5.000 berichten zijn deze vereisten in feite de norm geworden voor de afleverbaarheid bij de belangrijkste e-mailproviders. 

Wat het ene wel biedt en het andere niet:

SPF-controle mislukt bij doorgestuurde e-mail, wat volgens RFC 7208 de bedoeling is. Het IP-adres van de doorstuurserver vervangt het oorspronkelijke adres; dat IP-adres staat niet op je lijst met geautoriseerde adressen, waardoor de controle mislukt, ook al is er niets misgegaan. DKIM houdt geen rekening met IP-wijzigingen. De handtekening gaat mee met het bericht en wordt gevalideerd ongeacht welke servers het bericht heeft doorlopen, zolang de inhoud maar niet is gewijzigd.

DKIM bevestigt dat het bericht intact is en dat het ondertekenende domein de beheersing had over de privésleutel, maar zegt niets over de vraag of de server die het bericht heeft verzonden, daarvoor toestemming op netwerkniveau had. SPF zorgt voor die controle.

Geen van beide weet wat de ander weet. Als je beide gebruikt, krijgt de ontvangende server die je e-mail verwerkt het volledige plaatje te zien: het geautoriseerde pad en de ongeschonden inhoud, in plaats van slechts de helft daarvan.

SPF en DKIM instellen: stapsgewijze handleiding

Als SPF en DKIM nog niet zijn geconfigureerd voor uw domein, is het instellen heel eenvoudig. In de onderstaande stappen wordt uitgelegd wat u moet doen om beide protocollen te configureren en te verifiëren. 

Stap 1: Maak je SPF-record aan

Maak om te beginnen een lijst van alle diensten die bevoegd zijn om e-mail te versturen vanuit uw domein, zoals:

1. Uw primaire e-mailserver
2. Marketingplatform
3. CRM
4. Helpdesk-tool
5. Een aanbieder van transactionele e-mails, en alle andere diensten die namens u e-mails versturen.

Elke geautoriseerde dienst krijgt een inclusief: mechanisme in uw SPF-record, of een direct IP-bereik met behulp van ip4: of ip6:. Sluit het record af met -all om ontvangende servers te laten weten dat elk IP-adres dat niet op de lijst staat, niet is geautoriseerd.

Voordat je IP-reeksen rechtstreeks toevoegt met ip4: of ip6:, controleer dan of de reeksen bij de juiste verzendende dienst horen. Met de WHOIS IP-opzoekfunctie van PowerDMARC kunt u het IP-eigendom verifiëren voordat het in uw record wordt opgenomen. 

Een standaard SPF-record ziet er als volgt uit:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Houd het aantal DNS-opzoekingen in de gaten wanneer u diensten toevoegt. RFC 7208 beperkt de SPF-evaluatie tot 10 opzoekingen. Elke inclusief: mechanisme verbruikt er minstens één, en geneste includes tellen mee voor dezelfde limiet. De meeste domeinen bereiken de limiet sneller dan verwacht zodra ze vier of vijf externe afzenders tegelijkertijd gebruiken.

Gebruik de gratis SPF-generator om uw record aan te maken zonder de syntaxis handmatig te hoeven schrijven, en PowerSPF om het automatisch onder de limiet van 10 lookups te houden naarmate uw verzendinfrastructuur verandert.

Stap 2: Maak je DKIM-sleutels aan en publiceer ze

Voor elke dienst die namens u berichten verstuurt, hebt u een DKIM-sleutelpaar nodig: 

1. Een privésleutel die de verzendende server gebruikt om uitgaande e-mail te ondertekenen
2. Een bijbehorende openbare sleutel die in uw DNS is gepubliceerd, zodat ontvangende servers deze kunnen verifiëren.

Als een dienst zoals Google Workspace of Microsoft 365 de DKIM-ondertekening afhandelt, verstrekken zij het record met de openbare sleutel en de selectornaam. Publiceer het record in DNS op selector._domainkey.uwdomein.com en schakel ondertekening in via de beheerconsole van de dienst.

In omgevingen waar u zelf sleutels genereert, moet u minimaal 2048-bits RSA gebruiken; 1024-bits wordt niet langer als voldoende beschouwd. De gratis DKIM-generator van PowerDMARC genereert een publicatieklare DNS-record zonder dat er command-line tools nodig zijn.

Als u DKIM beheert voor meerdere verzendservices, dan regelt Hosted DKIM regelt het genereren van sleutels, het publiceren in DNS en de rotatie vanaf één plek, zonder dat je de DNS handmatig hoeft aan te passen telkens wanneer een sleutel moet worden gewijzigd.

Stap 3: Een DMARC-record toevoegen

Zodra SPF en DKIM zijn ingesteld, voeg je een DMARC-record toe aan je DNS. Begin bij p=none om geaggregeerde rapportagegegevens te verzamelen zonder de e-mailbezorging te beïnvloeden.

Een minimaal startrecord:

v=DMARC1; p=none; rua=mailto:[email protected];

p=none blokkeert geen vervalste berichten. Het zet DMARC in de bewakingsmodus, zodat u geaggregeerde rapporten ontvangt waarin wordt weergegeven welke bronnen de authenticatie doorstaan en welke niet, maar er wordt geen e-mail in quarantaine geplaatst of geweigerd. 

Gebruik die gegevens om verkeerde configuraties en afstemmingsproblemen op te sporen, en ga vervolgens verder naar p=quarantaine en uiteindelijk p=reject.

Een domein op p=none is niet beschermd tegen spoofing. De monitoringfase heeft een gedefinieerd eindpunt nodig, geen open tijdlijn.

Stap 4: Controleer je configuratie

Controleer na het publiceren van uw records of ze allemaal correct worden omgezet, voordat u de installatie als voltooid beschouwt.

Hoewel het correct omzetten van records noodzakelijk is, is dat op zichzelf niet voldoende. Voer een live test uit om te controleren of de authenticatieheaders het hele traject doorgaan. Met de SMTP-testtool van PowerDMARC laat u toe uw mailserververbinding te testen en SPF, DKIM en DMARC worden doorgegeven bij daadwerkelijke uitgaande e-mail, niet alleen in DNS. 

Veelgemaakte fouten

De twee meest voorkomende fouten die in de productieomgeving tot mislukte authenticatie leiden, zijn: 

SPF 10-opzoeklimiet

SPF staat maximaal 10 DNS-lookups toe wanneer een ontvangende server uw record evalueert, een limiet die is vastgesteld door RFC 7208. Mechanismen zoals include, a en mx activeren elk een lookup, en ze zijn genest. 

De meeste domeinen overschrijden de limiet van 10 al snel door afzenders van derden te stapelen, aangezien elke dienst die je via een `include`-regel autoriseert, lookups verbruikt. Zodra je de limiet overschrijdt, retourneert SPF een PermError, en ontvangende servers behandelen dit als een defecte record die uw e-mail niet langer autoriseert. 

Vlak maken lost dit op door je include-mechanismen te vervangen door de daadwerkelijke ip4- en ip6-bereiken waarnaar ze verwijzen, waardoor je opzoekingen naar nul dalen.

DKIM-sleutelrotatie

DKIM-sleutelrotatie houdt in dat je je DKIM-sleutelpaar volgens een vast schema vervangt, waarbij de oude privé-ondertekeningssleutel buiten gebruik wordt gesteld en er een nieuwe openbare sleutel voor in de plaats wordt gepubliceerd. Door rotatie wordt de tijd dat een enkele sleutel blootgesteld is beperkt, zodat de schade beperkt blijft als er ooit een sleutel gecompromitteerd raakt. De meeste teams voeren elk kwartaal of twee keer per jaar een rotatie uit, en sommige providers roteren hun eigen sleutels automatisch.

De meeste fouten bij het roteren zijn te wijten aan de stappen rondom de swap. Dit is wat beheerders het vaakst over het hoofd zien.

De oude openbare sleutel te vroeg verwijderen

Berichten die al onderweg zijn, zijn ondertekend met de oude sleutel, en de ontvanger heeft de bijbehorende openbare sleutel in DNS nodig om ze te verifiëren. Verwijder het oude record zodra je overschakelt, anders zullen de berichten die nog onderweg zijn de DKIM-controle niet doorstaan. Laat de oude sleutel gedurende een overgangsperiode gepubliceerd staan totdat alle daarmee ondertekende e-mails zijn verwerkt.

Dezelfde selector opnieuw gebruiken

Selectoren roteren, niet overschrijven. Publiceer de nieuwe sleutel onder een nieuwe selector, verplaats het ondertekenen daarheen en trek vervolgens de oude selector in na de overlappingsperiode. Het overschrijven van het record van één enkele selector creëert een gat waarin e-mail die met de oude sleutel is ondertekend niet langer kan worden gevalideerd.

Overschakelen voordat de DNS-wijzigingen zijn doorgevoerd

Als je de nieuwe sleutel al ondertekent voordat de de nieuwe publieke sleutel is verspreid, kunnen ontvangers deze niet vinden en mislukt DKIM. Publiceer eerst het nieuwe record, houd rekening met de TTL van het record en schakel daarna de ondertekening over.

Vergeet afzenders van derden

Elke verzendservice, zoals uw ESP of CRM, beheert zijn eigen DKIM-sleutels en -selectors. Het vernieuwen van de sleutel voor uw primaire domein heeft hier geen invloed op. Vernieuw de sleutel van elke service afzonderlijk, of controleer of de provider dit voor u regelt.

Een 2048-bits record onjuist splitsen

Een openbare sleutel van 2048 bits – de huidige standaard en zeker de moeite waard om naar over te stappen als je nog steeds 1024 bits gebruikt – overschrijdt vaak de limiet van 255 tekens voor een enkele DNS TXT-string en moet daarom worden opgesplitst in meerdere strings tussen aanhalingstekens. Een verkeerde opdeling zorgt ervoor dat het record niet klopt, waardoor de sleutel niet als geldig wordt herkend, ook al lijkt deze aanwezig te zijn.

Draaien zonder toezicht

Via de geaggregeerde DMARC-rapporten kunt u controleren of de nieuwe sleutel correct wordt gevalideerd. Zonder deze rapporten wordt een mislukte rotatie weergegeven als een afname van de afleverbaarheid in plaats van als een waarschuwing. Controleer uw rapporten na elke rotatie.

Beide fouten zijn het gevolg van records die sneller veranderen dan je ze handmatig kunt bijhouden. PowerDMARC houdt je SPF gestroomlijnd onder de limiet van 10 lookups en zorgt ervoor dat je DKIM-sleutels netjes rouleren; vervolgens waarschuwt het je op het moment dat er iets misgaat, voordat het ten koste gaat van je deliverability.

Start je gratis proefperiode om te zien hoe uw domein er vandaag voor staat.

FAQs

Vervangt DKIM SPF?

Nee. DKIM controleert de integriteit van het bericht aan de hand van een cryptografische handtekening, maar garandeert niet dat de verzendende server geautoriseerd is. SPF voert die controle uit, dus beide zijn nodig voor een volledige bescherming. 

Waarom slaagt mijn e-mail niet voor de SPF-controle na het doorsturen?

SPF vergelijkt het IP-adres van de verzendende server met uw lijst van geautoriseerde adressen, en bij doorsturen wordt het oorspronkelijke IP-adres vervangen door dat van de doorstuurder, dat niet in uw lijst staat. Dit is het verwachte gedrag volgens RFC 7208, en DKIM is zo ontworpen dat het hiertegen bestand is, omdat het de inhoud valideert en niet het pad. 

Wat is belangrijker: SPF of DKIM?

Geen van beide. SPF voert authenticatie uit op serverniveau, DKIM verifieert op berichtniveau, en beide zijn nodig voor een betrouwbare DMARC-afstemming. Als je beide hebt, wordt je e-mail nog steeds doorgestuurd als er bij het doorsturen een fout optreedt. 

Hoeveel DKIM-selectors mag ik hebben?

Er geldt geen limiet. Publiceer er zoveel als je nodig hebt, meestal één per verzendservice of sleutelrotatiecyclus. Elk record wordt opgeslagen als een afzonderlijk DNS TXT-record op selector._domainkey.jouwdomein.com. 

Wat gebeurt er als ik alleen SPF heb, maar geen DKIM?

Je verliest de integriteit op berichtniveau en hebt geen terugvaloptie voor DKIM-afstemming, waardoor DMARC kan mislukken bij legitieme doorgestuurde e-mails wanneer SPF niet werkt. De regels van Google voor bulkverzenders schrijven ook DKIM voor, waardoor verzenders met grote volumes niet meer aan de vereisten voldoen.