SPF: wie mag verzenden
RFC 7208 vertrekt van een vaststelling: niets in het e-mailprotocol verhindert een server om eender welk afzendadres op te geven. Met SPF kan de eigenaar van een domein in de DNS de lijst publiceren van servers die in zijn naam mogen verzenden, en kan de ontvangende server die toestemming controleren.
Twee verduidelijkingen veranderen alles:
- SPF controleert het envelopadres (dat van de dialoog tussen servers, “MAIL FROM” genoemd) en de naam die de server opgeeft, niet het adres dat de ontvanger in “Van” leest.
- SPF beoordeelt de laatste server die het bericht heeft afgeleverd. Wanneer een bericht door een andere server wordt doorgestuurd, levert niet langer een server af die door het oorspronkelijke domein is toegestaan: de controle kan mislukken terwijl het bericht legitiem is.
Een domein publiceert maar één SPF-record. Alle verzendbronnen moeten erin staan: e-mailomgeving, facturatiesoftware, nieuwsbrieftool, CRM, kopieerapparaat dat naar e-mail scant.
DKIM: het bericht is ondertekend
Volgens RFC 6376 stelt DKIM de eigenaar van een ondertekenend domein in staat een deel van de verantwoordelijkheid voor een bericht op te eisen, door middel van een cryptografische handtekening. De publieke sleutel staat in de DNS. Door de handtekening te controleren, stelt u vast dat de ondertekende delen sinds de ondertekening niet zijn gewijzigd.
De handtekening reist met het bericht mee. Ze overleeft een relay of een doorsturing dus beter dan SPF, zolang die relay het onderwerp of de inhoud niet wijzigt. Een distributielijst die onderaan het bericht een vermelding toevoegt, breekt haar.
Wat DKIM volgens dezelfde RFC niet doet: het versleutelt het bericht niet, een mislukking verplicht niet tot weigering, en het ondertekenende domein hoeft niet het domein te zijn dat in “Van” wordt getoond. Dat is precies het gat dat DMARC dicht.
DMARC: de afstemming en het beleid
RFC 7489 definieert DMARC als een manier voor de eigenaar van een domein om een beleid op domeinniveau uit te drukken. Het mechanisme berust op afstemming (alignment): het domein van het adres dat in “Van” wordt getoond, moet overeenkomen met het domein dat door SPF of door DKIM is gevalideerd. Als geen van beide is afgestemd, mislukt DMARC.
Het domein publiceert dan wat het wenst:
- none: geen actie gevraagd, er wordt geobserveerd;
- quarantine: het bericht als verdacht behandelen;
- reject: het bericht weigeren.
DMARC voorziet ook in rapporten: geaggregeerde rapporten, die samenvatten welke servers in naam van het domein hebben verzonden en met welk resultaat, en foutrapporten, per bericht. Daarmee ontdekt u een vergeten tool die voor u verzendt, of iemand die uw domein misbruikt.
| Mechanisme | Wat het controleert | Waar het niet naar kijkt |
|---|
| SPF | De server die het bericht aflevert, is toegestaan voor het envelopdomein | Het getoonde adres, de inhoud |
| DKIM | Het ondertekende bericht is niet gewijzigd; een domein neemt er de verantwoordelijkheid voor | Het getoonde adres, de eerlijkheid van de inhoud |
| DMARC | Het getoonde domein is afgestemd op SPF of DKIM; beleid bij mislukking | Gelijkende domeinen, de weergavenaam, de tekst |
Blokkeert DMARC phishing?
Het blokkeert een deel van het misbruik van het domein, niet phishing in het algemeen. RFC 7489 zegt het uitdrukkelijk: DMARC behandelt geen visueel gelijkende domeinnamen, noch misbruik van de weergavenaam, en de analyse van de inhoud valt buiten zijn reikwijdte. Het probeert niet alle problemen van frauduleuze post op te lossen.
Concreet ziet DMARC niet:
- een gelijkend domein: de fraudeur authenticeert zijn eigen domein, dat op het uwe lijkt, perfect;
- een misbruikte weergavenaam: “Afdeling boekhouding”, geschreven vanaf een adres zonder enig verband;
- een gecompromitteerd account dat correct ondertekent, aangezien de echte server verzendt;
- een bericht zonder verband met uw domein: een valse melding van een vervoerder komt van een domein dat niets met het uwe te maken heeft;
- een domein zonder beleid: als het geïmiteerde domein “none” publiceert, heeft de ontvanger geen instructie om te weigeren.
Deze gevallen vragen andere analyses: gelijkenis van domeinen, reputatie, inhoud, gedrag. Zie spam, phishing, malware en gecompromitteerd account.
Doorsturen en distributielijsten: ARC
Doorsturen breekt vaak SPF, een lijst die het bericht wijzigt breekt DKIM, en DMARC mislukt dan op een legitiem bericht. ARC, beschreven in RFC 8617 (experimentele status), stelt elke tussenpersoon in staat het authenticatieresultaat te bevestigen dat hij heeft vastgesteld. De uiteindelijke server kan ervoor kiezen daar rekening mee te houden.
Uw domein beschermen, filteren wat binnenkomt
Dat zijn twee onderwerpen die vaak worden verward.
- Het verzendende domein beschermen: SPF, DKIM en DMARC publiceren voor uw domein, zodat anderen berichten kunnen weigeren die het misbruiken. U publiceert; de ontvangers passen toe.
- Filteren wat binnenkomt: de records van andere domeinen controleren op de post die u ontvangt, en daarna alle andere analyses toepassen.
Geleidelijke invoering
- Inventaris van alles wat in naam van het domein verzendt.
- Eén SPF-record dat ze toestaat; een DKIM-handtekening voor elke dienst die kan ondertekenen.
- DMARC op “none”, met een adres voor de ontvangst van de rapporten.
- De rapporten gedurende meerdere weken lezen; vergeten bronnen corrigeren.
- Overstappen op “quarantine”, daarna op “reject” wanneer alle legitieme verzendingen zijn afgestemd.
Een voorbeeld, ter illustratie. Een kantoor publiceert DMARC op “none” en leest zijn eerste rapporten. Het ontdekt er drie bronnen: zijn e-mailomgeving, goed afgestemd; zijn facturatiesoftware, die de facturen met het domein van het kantoor verstuurt zonder DKIM-handtekening; en een onbekende server in het buitenland die honderden berichten in zijn naam verstuurt. Het corrigeert de facturatiesoftware, wacht een schone rapportcyclus af en stapt dan over op “quarantine”: de ontvangers die DMARC toepassen, behandelen de berichten van de onbekende server voortaan als verdacht.
Op de dag dat u van e-mailomgeving verandert, bereidt u deze records voor vóór de wijziging van het MX-record. De gids e-mail migreren zonder onderbreking beschrijft dat moment; het wordt hier niet herhaald.
Veelgestelde vragen
Beschermt een DMARC-beleid “none”?
Nee. Het maakt observatie mogelijk dankzij de rapporten. De bescherming begint met “quarantine” of “reject”.
Waarom mislukt DMARC bij een legitiem bericht?
Meestal: een doorsturing, een distributielijst, of een dienst die voor u verzendt zonder in SPF te zijn opgenomen of met DKIM te ondertekenen.
Onze e-mailomgeving ondertekent niet met DKIM: wat nu?
Een gateway op het traject van de verzendingen kan in haar plaats ondertekenen. Zie De e-mailomgeving beschermen die u al hebt.
Waar leest u het resultaat van deze controles op een ontvangen bericht?
In de headers van het bericht. Voor Klytic MTA, zie Een beslissing van de filter lezen en exporteren.
Waar Klytic staat
Klytic MTA behandelt beide onderwerpen, vóór elke e-mailomgeving:
- Essential en Advanced: controle van SPF, DKIM en MX; DMARC-controle, ook voor doorgestuurde berichten dankzij ARC; DKIM-ondertekening van de verzendingen, zelfs als uw e-mailomgeving dat niet doet.
- Advanced: DMARC-console, met de rapporten van uw domeinen, waarschuwingen en correctieadvies, om de geleidelijke overstap naar “reject” te begeleiden.
DMARC is maar één laag: Klytic MTA voegt de detectie toe van lookalike-domeinen, de weergavenaam en fraudescenario’s, beschreven in imitatie en CEO-fraude.
Als u Klytic Mail gebruikt, zijn SPF, DKIM en DMARC ingesteld voor uw domein: dat is de bescherming van het verzendende domein. Klytic MTA neemt u af met of zonder Klytic Mail.
Bronnen
Geraadpleegd in oktober 2026.
- RFC 7208, SPF: de eigenaar van een domein publiceert de hosts die zijn domein mogen gebruiken in de identiteit “MAIL FROM” of “HELO”, en de ontvanger controleert die toestemming. rfc-editor.org
- RFC 6376, DKIM: een domein eist de verantwoordelijkheid voor een bericht op via een cryptografische handtekening; geen versleuteling, geen verplichte weigering, ondertekenend domein mogelijk verschillend van de getoonde auteur. rfc-editor.org
- RFC 7489, DMARC: afstemming van het domein in “From” op SPF of DKIM, beleid none, quarantine en reject, geaggregeerde rapporten en foutrapporten; visueel gelijkende domeinen, weergavenaam en analyse van de inhoud buiten de reikwijdte. rfc-editor.org
- RFC 9989 (mei 2026), die RFC 7489 vervangt: dezelfde beleidswaarden en dezelfde uitsluitingen (gelijkende domeinen, weergavenaam). rfc-editor.org
- RFC 8617, ARC (experimenteel): geauthenticeerde doorgifteketen; een DMARC-ontvanger kan de beoordelingen aanvaarden die door een geldige ARC-keten worden gedragen. rfc-editor.org
- Klytic, pagina Klytic MTA: authenticatiecontroles, uitgaande DKIM-ondertekening en DMARC-console van de formules Essential en Advanced, opties, implementatievormen, ingebruikname via het MX-record. klytic.com
