Deze tool draait op de server
Hoe het werkt
Het e-mailprotocol controleert niet wie verstuurt: elke server kan jouw domein als afzender invullen. Drie DNS-records sluiten die deur. SPF somt op welke servers namens het domein mogen versturen. DKIM ondertekent elk bericht met een privésleutel waarvan het publieke deel in DNS staat. DMARC verbindt beide: het eist dat minstens één slaagt en overeenkomt met het zichtbare afzenderdomein, vertelt de ontvanger wat hij met mislukkingen moet doen en vraagt rapporten op over alles wat in jouw naam is verstuurd.
Sinds februari 2024 eisen Gmail en Yahoo SPF, DKIM en DMARC van iedereen die meer dan 5000 berichten per dag naar hun gebruikers stuurt, en ontbreekt er één, dan wordt e-mail geweigerd of belandt die in spam. Daarom loont het om ze alle drie samen te controleren: een perfect SPF helpt weinig zonder DMARC, en een DMARC op reject met een slecht gepubliceerde DKIM houdt je eigen mail tegen.
De controle gebeurt vanaf onze server met openbare DNS-queries, precies zoals elke mailserver dat zou doen. SPF wordt volledig geëvalueerd door elke include en redirect te volgen om de DNS-lookups te tellen, want boven de limiet van 10 vervalt het hele record. Daarnaast worden de MX-records en de optionele records MTA-STS, TLS-RPT en BIMI opgevraagd.
Voorbeelden
github.comSPF · 10 / 10Acht provider-includes (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) en wat die zelf includen, brengen de evaluatie precies op de limiet van 10 DNS-lookups. Nog één provider en het hele SPF geeft een permanente fout.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sDe juiste configuratie voor een domein dat geen e-mail verstuurt of ontvangt: null-MX, een SPF die niemand autoriseert en DMARC op reject. Zo bescherm je geparkeerde domeinen, een geliefd doelwit van spoofing.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Een geleidelijke uitrol: slechts één op de vier mislukte berichten gaat naar spam, en de rapporten komen binnen op het rua-adres, zodat je legitieme afzenders ziet die nog niet geauthenticeerd zijn.Gebruiksscenario's
- Achterhalen waarom de e-mails van het domein in spam belanden of door Gmail, Outlook of Yahoo worden geweigerd.
- Controleren dat SPF onder de 10 DNS-lookups blijft voordat je een nieuwe verzendprovider toevoegt, zoals een CRM of een nieuwsbriefplatform.
- Controleren of de DKIM-sleutel van een provider na het instellen goed is gepubliceerd.
- De overstap van DMARC van none naar quarantine en reject plannen zonder legitieme mail te blokkeren.
- De domeinen van een klant of overgenomen bedrijf auditen, inclusief geparkeerde domeinen die geen e-mail zouden moeten versturen.
- De configuratie van een verdachte afzender bekijken tijdens de analyse van een phishingpoging.
Veelgestelde vragen
Waarom staat er dat er geen DKIM is gevonden als mijn domein zijn e-mail ondertekent?
Omdat DKIM het niet toestaat de sleutels van een domein op te sommen: elke sleutel staat op <selector>._domainkey.<domein> en je moet de selector kennen om hem op te vragen. De tool probeert de meest gebruikte selectors, maar veel providers gebruiken eigen namen of namen met een datum. Open een e-mail die vanaf het domein is verstuurd, zoek de header DKIM-Signature en kopieer de waarde van s=; met die selector is de controle exact.
Wat gebeurt er als SPF meer dan 10 DNS-lookups nodig heeft?
RFC 7208 verplicht de ontvanger een permanente fout (permerror) terug te geven, en voor DMARC telt dat als een mislukte SPF. Lookups worden verbruikt door de mechanismen include, a, mx, ptr en exists en de modifier redirect, ook binnen elke include; ip4 en ip6 verbruiken er geen. Om het aantal te verlagen verwijder je providers die je niet meer gebruikt, vervang je includes door ip4-bereiken of verstuur je vanaf subdomeinen met een eigen SPF.
~all of -all?
Met DMARC actief is het verschil klein: de ontvanger past het DMARC-beleid toe, niet de SPF-qualifier. ~all is gebruikelijk omdat sommige ontvangers bij -all meteen weigeren voordat ze DKIM beoordelen, waardoor doorgestuurde e-mail verloren kan gaan die DKIM had gered. Zonder DMARC is -all de enige manier om te vragen dat niet-geautoriseerde mail wordt geweigerd.
Hoe zet ik DMARC van none naar reject zonder e-mail te verliezen?
Begin met p=none en een adres in rua en lees een paar weken de geaggregeerde rapporten: ze tonen elke server die met je domein verstuurt en of die slaagt voor SPF of DKIM. Authenticeer de legitieme afzenders die ontbreken, ga naar quarantine met een lage pct, verhoog pct geleidelijk en eindig bij reject. Direct naar reject springen houdt vaak factuursystemen, CRM's of interne systemen tegen waar niemand meer aan dacht.
Is een DKIM-sleutel van 1024 bits genoeg?
Hij werkt, want RFC 8301 verplicht ontvangers sleutels van 1024 tot 4096 bits te accepteren, maar dezelfde norm raadt ondertekenaars aan minstens 2048 te gebruiken. Sleutels onder 1024 bits gelden niet als geldig. Overstappen naar 2048 is eenvoudig: publiceer de nieuwe sleutel onder een andere selector, wissel de ondertekening om en trek daarna de oude in door p leeg te laten.
Waar dienen MTA-STS, TLS-RPT en BIMI voor?
MTA-STS (RFC 8461) vraagt verzendende servers TLS te eisen bij aflevering op je MX, wat aanvallen voorkomt die de verbinding naar platte tekst terugbrengen. TLS-RPT (RFC 8460) stuurt je rapporten als die afleveringen mislukken. BIMI toont het merklogo naast de afzender in clients die het ondersteunen en werkt alleen met DMARC op quarantine of reject. Geen van drieën is verplicht, maar ze helpen alle drie.