SPF, DKIM en DMARC uitgelegd

SPF, DKIM en DMARC zijn essentieel voor een betrouwbare e-mail aflevering. Ontdek hoe deze DNS-records werken, waarom precies ze belangrijk zijn en hoe ze tegelijk spam en phishing helpen beperken.
SPF DKIM DMARC

Betrouwbare e-mail aflevering draait vandaag om veel meer dan alleen een goede verzendreputatie of een nette nieuwsbrief.

Grote e-mailproviders zoals Gmail, Hotmail, Outlook en Yahoo willen kunnen controleren of een e-mail wel degelijk afkomstig is van de afzender die zichtbaar wordt getoond. Daarom spelen SPF, DKIM en DMARC vandaag een cruciale rol in professionele e-mail communicatie.

Zonder deze DNS-records wordt het steeds moeilijker om e-mails betrouwbaar afgeleverd te krijgen. Zeker voor bulkmail, e-mail nieuwsbrieven en geautomatiseerde e-mails zijn correcte instellingen vandaag vrijwel onmisbaar geworden.

Tegelijk zorgen SPF, DKIM en DMARC vaak voor verwarring. Wat is precies het verschil? Waarom zijn ze alle drie belangrijk? En waarom raken e-mails soms toch nog in spam, zelfs wanneer alles technisch correct ingesteld lijkt?

In dit artikel leggen we stap voor stap uit hoe SPF, DKIM en DMARC precies werken. Technisch correct en begrijpbaar uitgelegd.

Waarom SPF, DKIM en DMARC vandaag essentieel zijn

Vroeger was het relatief eenvoudig om e-mails te versturen uit naam van eender welk domein. Daardoor konden oplichters jarenlang spam en phishing versturen die afkomstig leek van legitieme afzenderadressen.

Vandaag controleren grote e-mailproviders daarom veel strenger of een e-mail wel degelijk afkomstig is van de afzender die zichtbaar wordt getoond. SPF, DKIM en DMARC helpen om de identiteit van de verzender te controleren en misbruik te beperken.

Correcte instellingen zijn ondertussen vrijwel onmisbaar geworden voor professionele e-mail communicatie. Zeker bij bulkmail, e-mail nieuwsbrieven en geautomatiseerde e-mails verwachten providers zoals Gmail, Microsoft en Yahoo dat SPF, DKIM en DMARC correct zijn ingesteld.

Ontbrekende of foutieve records kunnen ervoor zorgen dat e-mails in spam terechtkomen, tijdelijk worden geweigerd of zelfs volledig geblokkeerd worden.

Tegelijk bieden deze technieken ook voordelen voor ontvangers. Ze helpen spamfilters beter inschatten welke e-mails betrouwbaar zijn en maken het moeilijker om zomaar e-mails te vervalsen uit naam van bestaande domeinen.


Bekijk indien gewenst ook volgend artikel waarin SPF, DKIM en DMARC besproken worden binnen een ruimer kader van ook andere belangrijke factoren voor het betrouwbaar afleveren van e-mail.

Wat is SPF en hoe werkt het?

SPF staat voor Sender Policy Framework en is een DNS-record waarmee een domeinnaam kan aangeven welke mailservers e-mails mogen versturen uit naam van dat domein.

Wanneer een ontvangende mailserver een e-mail ontvangt, kan die controleren of de server die de e-mail verzond ook effectief toegelaten is volgens het SPF-record van het afzenderdomein.

Komt de verzendende server niet voor in het SPF-record, dan kan dat een belangrijk signaal zijn dat de e-mail mogelijk vervalst is.

SPF helpt zo voorkomen dat zomaar e-mails kunnen worden verstuurd uit naam van bestaande domeinen. Tegelijk helpt het e-mailproviders om betrouwbaarder in te schatten welke e-mails legitiem zijn.

Envelope sender vs zichtbaar afzenderadres

Bij SPF is het belangrijk om te begrijpen dat een e-mail technisch verschillende afzenderadressen kan bevatten.

Het zichtbaar afzenderadres het adres dat u meestal ziet in uw mailbox bij ‘Van:’  is niet noodzakelijk hetzelfde adres dat mailservers gebruiken om SPF-controles uit te voeren.

Voor SPF wordt gekeken naar het zogenaamde ‘envelope sender’ adres. Dat is het technische afzenderadres dat gebruikt wordt tijdens de verzending van de e-mail en waarop bijvoorbeeld ook bounceberichten terechtkomen.

Daardoor kan een e-mail perfect zichtbaar verzonden lijken vanuit info@uwdomein.be, terwijl de SPF-controle in werkelijkheid gebeurt op een volledig ander domein.


Bij professionele e-mail marketing platformen is dat verschil erg belangrijk. Sommige platformen gebruiken bijvoorbeeld een generieke envelope sender die gedeeld wordt door alle klanten. Daardoor wordt het veel moeilijker om de reputatie van individuele klanten correct op te bouwen of specifieke afzenders betrouwbaar te whitelisten.

Dat is één van de redenen waarom SOLID Mailings bewust kiest voor een volledig gescheiden verzendstructuur per klant. Daardoor zijn zowel het zichtbare afzenderadres als de envelope sender duidelijk herkenbaar en gekoppeld aan het domein van de klant of diens verzendomgeving.

Zo vermijden we generieke en moeilijk herkenbare envelope sender adressen zoals:
msprvs1=205489jlzNi7aP=bounces-12741-14199@bounces.wixemails.com

en verkiezen we duidelijke en consistente adressen zoals:

  • zichtbaar afzenderadres:
    nieuws@mail.uwdomein.be
  • envelope sender:
    uwbedrijfsnaam@mail.uwdomein.be


Dat zorgt niet alleen voor meer transparantie, maar helpt ook bij reputatieopbouw, troubleshooting, betrouwbare aflevering en het correct kunnen whitelisten van afzenderadressen.

Bij generieke en voortdurend wijzigende envelope sender adressen is dat in de praktijk vaak veel moeilijker of zelfs onmogelijk.

SPF qualifiers, includes en limieten uitgelegd

Een SPF-record bestaat uit verschillende onderdelen die samen bepalen welke mailservers e-mails mogen versturen uit naam van een domein.

Een eenvoudig SPF-record kan er bijvoorbeeld zo uitzien:

v=spf1 include:_spf.google.com ip4:192.0.2.10 -all
 

Elk onderdeel heeft daarbij een specifieke betekenis.

v=spf1 geeft aan dat het om een SPF-record gaat.

Met include: kan een domein aangeven dat ook de mailservers van een andere partij toegelaten zijn. Dat wordt bijvoorbeeld vaak gebruikt bij externe e-maildiensten of e-mail marketing platformen.

ip4: en ip6: laten toe om specifieke IPv4- of IPv6-adressen rechtstreeks toe te voegen aan het SPF-record.

Daarnaast bestaan ook mechanismes zoals a en mx, waarbij automatisch de IP-adressen worden gebruikt die gekoppeld zijn aan respectievelijk het A-record of de MX-records van het domein.

Op het einde van een SPF-record wordt vaak een zogenaamde qualifier toegevoegd, zoals -all of ~all, al is dat niet verplicht.

-all wordt ook wel een strict fail genoemd. Met -all geeft een domein aan dat uitsluitend de servers in het SPF-record e-mails mogen versturen. Servers die niet voorkomen in het SPF-record zouden dan moeten falen voor SPF.

~all wordt een softfail genoemd en is minder streng. Die qualifier wordt vaak gebruikt tijdens een overgangsperiode of om SPF eerst voorzichtig te testen.

Tijdens een SPF-controle mogen maximaal 10 externe DNS-lookups uitgevoerd worden. Bij te veel include: mechanismes of complexe SPF-structuren kan die limiet overschreden worden, waardoor SPF-controles mislukken.

Een domein mag bovendien slechts één SPF-record bevatten. Wanneer meerdere SPF-records aanwezig zijn, wordt SPF ongeldig en kunnen controles mislukken.

Wat is DKIM en hoe werkt de digitale handtekening?

DKIM staat voor DomainKeys Identified Mail en voegt een digitale handtekening toe aan uitgaande e-mails.

Die handtekening laat ontvangende mailservers toe om te controleren of een e-mail onderweg niet ongemerkt werd gewijzigd én of de verzendende server gemachtigd was om die handtekening namens het domein te plaatsen.

Bij het verzenden van een e-mail maakt de mailserver een soort digitale vingerafdruk van belangrijke onderdelen van de e-mail, zoals bepaalde headers en delen van de inhoud. Die vingerafdruk wordt vervolgens cryptografisch ondertekend met een private key die enkel beschikbaar is op de verzendende mailserver.

De publieke sleutel waarmee die handtekening gecontroleerd kan worden, staat gepubliceerd in een DNS-record van het domein.

Wanneer een ontvangende mailserver de e-mail ontvangt, kan die de publieke sleutel opvragen via DNS en controleren of de handtekening nog correct overeenkomt met de inhoud van de e-mail.

Werd de e-mail onderweg aangepast bijvoorbeeld doordat een systeem headers of inhoud wijzigde dan kan de DKIM-controle mislukken.

DKIM werkt daardoor anders dan SPF. Waar SPF vooral controleert welke mailserver een e-mail mocht versturen, helpt DKIM controleren of de inhoud van de e-mail onderweg intact bleef en effectief gekoppeld is aan het ondertekenende domein.

Public key, private key en selectors uitgelegd

DKIM werkt met een combinatie van een private key en een public key.

De private key bevindt zich op de verzendende mailserver en wordt gebruikt om de digitale handtekening van uitgaande e-mails te genereren. Die sleutel blijft geheim en mag nooit publiek zichtbaar zijn.

De public key wordt daarentegen gepubliceerd in een DNS-record van het domein. Ontvangende mailservers kunnen die publieke sleutel gebruiken om te controleren of de DKIM-handtekening geldig is.

De public key geeft daarbij geen toegang tot de private key. Ze dient uitsluitend om de handtekening te controleren, niet om zelf geldige handtekeningen te kunnen genereren.

Daarnaast gebruikt DKIM ook zogenaamde selectors.

Een selector maakt het mogelijk om meerdere DKIM-sleutels naast elkaar te gebruiken voor hetzelfde domein. Dat is handig wanneer bijvoorbeeld verschillende systemen e-mails versturen uit naam van hetzelfde domein, of wanneer sleutels periodiek vervangen worden.

De selector wordt toegevoegd aan de DKIM-handtekening van de e-mail en verwijst naar het juiste DNS-record waarin de bijhorende public key gepubliceerd staat.

Een typisch DKIM DNS-record ziet er bijvoorbeeld zo uit:

selector1._domainkey.uwdomein.be TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
 

Hierbij is selector1 de selector die verwijst naar de juiste DKIM public key voor dat domein.

Wat is DMARC en waarom is alignment belangrijk?

DMARC staat voor Domain-based Message Authentication, Reporting and Conformance en bouwt verder op SPF en DKIM.

Waar SPF en DKIM afzonderlijk controleren of bepaalde technische controles slagen, bepaalt DMARC vooral of die controles ook effectief gekoppeld zijn aan het zichtbaar afzenderadres van de e-mail. Dat principe wordt alignment genoemd.

Bij alignment controleert DMARC of het domein dat zichtbaar wordt getoond in het “Van:” adres overeenkomt met het domein dat gebruikt werd bij SPF en/of DKIM.

Een e-mail kan bijvoorbeeld perfect slagen voor SPF, maar toch verzonden zijn via een volledig ander domein dan het zichtbaar afzenderadres. Zonder alignment zou dat nog steeds misbruikt kunnen worden voor phishing of spoofing. DMARC helpt dat voorkomen door extra controles toe te voegen rond de identiteit van het zichtbaar afzenderadres.

Een e-mail hoeft daarbij niet noodzakelijk zowel SPF als DKIM correct aligned te hebben. In de praktijk volstaat het dat minstens één van beide controles correct aligned slaagt voor DMARC.

Daarnaast laat DMARC domeineigenaars ook toe om aan ontvangende mailservers door te geven wat er moet gebeuren wanneer SPF en DKIM niet correct aligned zijn. Bijvoorbeeld enkel rapporteren, e-mails markeren als spam of ze volledig weigeren.

DMARC vormt daardoor een belangrijke extra beschermingslaag tegen phishing, spoofing en misbruik van domeinnamen.

DMARC policies: none, quarantine en reject

Via een DMARC-record kan een domeineigenaar aangeven hoe ontvangende mailservers best omgaan met e-mails die niet correct slagen voor DMARC.

Daarvoor gebruikt DMARC zogenaamde policies.

Met p=none wordt vooral gemonitord en gerapporteerd. E-mails die falen voor DMARC worden daarbij normaal nog niet actief geblokkeerd of in spam geplaatst. Deze policy wordt vaak gebruikt tijdens de opstartfase om eerst te controleren of SPF, DKIM en alignment correct functioneren.

Met p=quarantine vraagt een domein om verdachte e-mails bijvoorbeeld in spam of quarantaine te plaatsen.

Met p=reject wordt aan ontvangende mailservers gevraagd om e-mails die falen voor DMARC volledig te weigeren.

Hoewel reject de strengste bescherming biedt, is voorzichtigheid belangrijk. Wanneer SPF, DKIM of alignment niet volledig correct geconfigureerd zijn, kunnen ook legitieme e-mails onbedoeld geweigerd worden.

Daarom starten veel organisaties eerst met p=none om hun e-mailverkeer en rapportering grondig te analyseren, om daarna geleidelijk strengere policies toe te passen.

DMARC rapportering via rua en ruf

DMARC ondersteunt ook uitgebreide rapportering via zogenaamde rua– en ruf-rapporten.

Met rua kunnen ontvangende mailservers periodieke rapporten versturen over e-mails die uit naam van het domein werden ontvangen. Die rapporten bevatten onder meer informatie over SPF, DKIM, alignment en de mailservers die e-mails verstuurden.

Zo krijgen domeineigenaars beter zicht op:

  • legitieme verzendbronnen;
  • foutieve configuraties;
  • systemen die nog niet correct ingesteld zijn;
  • of mogelijk misbruik van hun domein.


ruf-rapporten zijn gedetailleerder en kunnen informatie bevatten over individuele e-mails die falen voor DMARC. Omdat dergelijke rapporten gevoelige informatie kunnen bevatten, worden ze in de praktijk minder vaak gebruikt.

DMARC-rapportering speelt een belangrijke rol bij het veilig opbouwen van strengere DMARC-policies. Veel organisaties starten daarom met p=none en gebruiken de rapportering eerst om hun volledige e-mailverkeer in kaart te brengen.

Waarom SPF, DKIM en DMARC samenwerken

SPF en DKIM vormen de technische basis waarop DMARC verder bouwt.

SPF controleert in de eerste plaats welke mailservers e-mails mogen versturen uit naam van een domein. DKIM helpt controleren of de inhoud van een e-mail onderweg niet gewijzigd werd en effectief gekoppeld is aan het ondertekenende domein.

DMARC bouwt daarop verder en controleert of SPF en/of DKIM ook correct aligned zijn met het zichtbaar afzenderadres van de e-mail.

Geen van deze technieken is afzonderlijk perfect.

SPF alleen volstaat bijvoorbeeld niet wanneer e-mails automatisch worden doorgestuurd via een andere mailserver. DKIM alleen zegt dan weer niets over welke servers e-mails mochten verzenden.

DMARC vormt daarom een belangrijke extra laag die SPF en DKIM samenbrengt en helpt voorkomen dat domeinnamen eenvoudig misbruikt kunnen worden voor spoofing of phishing.

De combinatie van SPF, DKIM en DMARC is vandaag dan ook uitgegroeid tot de standaard voor professionele en betrouwbare e-mail communicatie.

Veel grote e-mailproviders verwachten daarom vandaag dat minstens SPF, DKIM en DMARC correct geconfigureerd zijn.

Waarom grote providers deze records vereisen

Spam, phishing en misbruik van domeinnamen zijn de voorbije jaren sterk toegenomen. Grote e-mailproviders zoals Gmail, Microsoft en Yahoo controleren daarom steeds strenger of verzonden e-mails technisch betrouwbaar zijn.

Vooral bij bulkmail, nieuwsbrieven en geautomatiseerde e-mails verwachten providers vandaag dat SPF, DKIM en DMARC correct ingesteld zijn.

Zo kondigden Google en Yahoo in 2024 bijkomende vereisten aan voor bulkverzenders, waaronder correcte SPF- en DKIM-authenticatie, een geldig DMARC-record en een correcte verwerking van uitschrijvingen.

Ook Microsoft en andere providers houden steeds meer rekening met technische authenticatie, verzendreputatie, engagement en verzendgedrag bij het beoordelen van e-mails.

Betrouwbare e-mail aflevering draait vandaag dan ook om veel meer dan alleen het technisch kunnen verzenden van e-mails. Providers willen vooral kunnen inschatten of een afzender legitiem en betrouwbaar is.

Ontbrekende of foutieve SPF-, DKIM- en DMARC-records kunnen daardoor een negatieve impact hebben op de aflevering van e-mails — zelfs wanneer de inhoud volledig legitiem is.

Waarom e-mail forwarding problemen kan veroorzaken

Automatisch doorsturen of forwarden van e-mails kan vandaag problemen veroorzaken bij SPF, DKIM en DMARC.

Wanneer een e-mail automatisch wordt doorgestuurd via een andere mailserver, verandert namelijk de verzendende server. Daardoor komt de server die de e-mail uiteindelijk aflevert vaak niet meer overeen met de servers die toegelaten zijn in het SPF-record van het oorspronkelijke domein.

Daardoor mislukt SPF bij forwarding in veel gevallen volledig.

DKIM blijft bij forwarding vaak beter behouden, omdat daarbij de inhoud van de e-mail gecontroleerd wordt in plaats van de verzendende server. Toch kan ook DKIM breken wanneer forwarding-systemen onderweg headers of inhoud aanpassen, bijvoorbeeld door waarschuwingen, voetregels of extra tekst toe te voegen.

Omdat DMARC steunt op SPF en/of DKIM, kunnen forwardingproblemen er soms voor zorgen dat legitieme e-mails toch geweigerd worden of in spam terechtkomen.

Dat verklaart waarom e-mails soms probleemloos aankomen bij de meeste ontvangers, maar toch geweigerd worden bij specifieke personen of organisaties die hun e-mails automatisch laten doorsturen via een andere server.

Veelgemaakte fouten bij SPF, DKIM en DMARC

SPF, DKIM en DMARC correct configureren lijkt op het eerste zicht eenvoudig, maar in de praktijk komen fouten regelmatig voor.

Een veelvoorkomend probleem is het gebruik van meerdere SPF-records voor hetzelfde domein. Een domein mag slechts één geldig SPF-record bevatten. Wanneer meerdere SPF-records aanwezig zijn, kan SPF ongeldig worden en kunnen controles mislukken.

Ook te complexe SPF-records met te veel externe DNS-lookups veroorzaken regelmatig problemen.

Bij DKIM zien we vaak fouten zoals ontbrekende DNS-records, verkeerd ingestelde selectors of systemen die e-mails aanpassen nadat ze ondertekend werden, waardoor de DKIM-handtekening ongeldig wordt.

Bij DMARC wordt soms te snel gekozen voor een strenge p=reject policy zonder eerst grondig te controleren of alle verzendende systemen correct geconfigureerd zijn. Daardoor kunnen ook legitieme e-mails onverwacht geweigerd worden.

Daarnaast vergeten organisaties regelmatig dat niet alleen nieuwsbrieven, maar ook websites, CRM-systemen, scanners, ticketingsystemen, webshops of andere toepassingen e-mails kunnen versturen uit naam van hun domein.

Een correcte configuratie vraagt daarom niet alleen technische kennis, maar ook een goed overzicht van alle systemen die e-mails versturen namens het domein.

Wat SPF, DKIM en DMARC niet kunnen voorkomen

Hoewel SPF, DKIM en DMARC een belangrijke rol spelen in betrouwbare e-mail aflevering en bescherming tegen spoofing, kunnen ze niet alle vormen van spam of phishing voorkomen.

Deze technieken controleren vooral of een e-mail technisch afkomstig lijkt van het domein waarvan ze beweert verzonden te zijn.

Oplichters kunnen echter nog steeds domeinnamen registreren die sterk lijken op bestaande domeinen, bijvoorbeeld door kleine schrijffouten, extra woorden of subtiele variaties te gebruiken.

Ook phishingmails die verzonden worden vanuit technisch correct geconfigureerde domeinen kunnen perfect slagen voor SPF, DKIM en DMARC.

Daarnaast blijven ook technieken zoals misleidende afzendernamen, gehackte mailboxen of legitieme diensten die misbruikt worden voor spam mogelijk.

SPF, DKIM en DMARC vormen daarom geen volledige bescherming tegen phishing, maar wel een belangrijke technische basis om misbruik van domeinnamen moeilijker te maken en betrouwbaarder e-mailverkeer beter herkenbaar te maken.

Hoe SOLID Mailings hiermee omgaat

Bij SOLID Mailings besteden we veel aandacht aan correcte SPF-, DKIM- en DMARC-configuratie, omdat betrouwbare e-mail aflevering onmogelijk is geworden zonder een sterke technische basis.

Voor e-mail marketing gebruiken we bewust afzonderlijke verzendomgevingen en aparte subdomeinen, zodat e-mailverkeer duidelijk gescheiden blijft van websites, gewone mailboxen en andere toepassingen van een domein.

Dat helpt niet alleen om SPF, DKIM en DMARC overzichtelijk en correct te configureren, maar voorkomt ook dat wijzigingen aan andere DNS-records onverwacht invloed hebben op de betrouwbaarheid van e-mail verzending.

Daarnaast kiezen we bewust voor een volledig gescheiden verzendstructuur per klant, met een eigen reputatie en duidelijke afzenderdomeinen in plaats van generieke gedeelde adressen.

Ook envelope sender adressen, trackinglinks en afbeeldingen verlopen via die afzonderlijke infrastructuur, wat zorgt voor meer transparantie, betere reputatieopbouw en betrouwbaardere aflevering.

Bovendien volgen we afleveringsresultaten actief op en helpen we klanten bij het correct configureren van SPF, DKIM en DMARC wanneer dat nodig is.

Zo combineren we gebruiksvriendelijke e-mail marketing met een sterke technische basis voor betrouwbare aflevering op lange termijn.

SOLID Mailings eens van dichtbij zien?

Wilt u e-mail marketing gebruiken met persoonlijke ondersteuning en technische ontzorging? We tonen u graag hoe SOLID Mailings werkt, en beantwoorden met plezier uw vragen. Liever zelf even testen in een demo-omgeving? Dat kan uiteraard ook. Geheel vrijblijvend.

Facebook
Twitter
LinkedIn
Telegram