E-mailauthenticatie met SPF, DKIM en DMARC uitgelegd

E-mailauthenticatie met SPF, DKIM en DMARC is essentieel. Wie in 2025 of 2026 zakelijke mail vanaf een eigen domein verstuurt, gebruikt deze records als belangrijke signalen voor ontvangers. Inbox, spam of afwijzing hangt ook van andere factoren af. Begin voor het bredere model bij zakelijke e-mail voor kleine bedrijven.

Teams zoeken problemen vaak in inhoud, terwijl een fout domein ook veel veroorzaakt: een verkeerd SPF-record, ontbrekende DKIM-sleutel of nooit gepubliceerd DMARC-beleid. Dat kan bijdragen aan bounces, snelheidsbeperkingen, spamclassificatie en forwardingproblemen.

De theorie is eenvoudig, de uitvoering vraagt zorg. SPF autoriseert het werkelijke verzendpad. DKIM valideert ondertekening en behouden ondertekende gegevens. DMARC publiceert gevraagd beleid voor fouten en controleert alignment met het zichtbare From-domein. Een correcte configuratie helpt, maar garandeert geen aflevering.

Wat SPF, DKIM en DMARC werkelijk doen

Deze drie lagen helpen mailboxproviders een bericht beoordelen. SPF controleert het verzendpad, DKIM de handtekening en DMARC alignment plus beleid. Toepasselijke bulkregels kunnen alle drie vereisen; voor een DMARC-pass volstaat aligned SPF of DKIM.

DMARC vereist niet dat SPF en DKIM beide slagen. Een van beide moet slagen én aligned zijn met het From-domein dat de ontvanger ziet.

SPF: wie namens je domein mag verzenden

SPF is de eerste laag. De ontvangende server gebruikt het feitelijke MAIL FROM- of envelope-domein, leest het SPF TXT-record en controleert het verbindende IP. Forwarding en grote include-ketens maken SPF kwetsbaar.

SPF staat als TXT-record in DNS. Een normaal voorbeeld:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Deze regel betekent:

1. v=spf1 geeft het recordtype aan.
2. include: verwijst naar gepubliceerde infrastructuur van een ander domein.
3. -all vraagt om een fail voor overige bronnen.

Een bekende grens is de limiet van 10 DNS-lookups uit RFC 7208. Iedere include telt mee, net als geneste mechanismen en modifiers die DNS opvragen. Overschrijding kan PermError geven; SPF levert dan geen geldige pass.

Een twee jaar geleden opgezegde CRM liet zijn include: achter. Het marketingplatform voegde er drie toe en de servicedesk nog een. Pas bij evaluatie van de hele keten werd het probleem zichtbaar.

SPF kan falen bij forwarding. Stuurt een universiteit naar Gmail door, dan ziet Gmail mogelijk de universiteitsserver als bron. Een oorspronkelijk correct SPF-pad kan dan toch falen. Daarom is SPF alleen niet genoeg.

Voor TrekMail beschrijven actuele documenten de benodigde include en het samenvoegen zonder duplicaten: Vereiste DNS-records.

DKIM: wie ondertekende en wat intact bleef

DKIM ondertekent met een privésleutel; de ontvanger verifieert via een publieke DNS-sleutel. DKIM kan forwarding overleven als een geldige aligned handtekening en gecanonicaliseerde ondertekende gegevens behouden blijven. Wijzigingen aan body of ondertekende headers kunnen DKIM breken.

DKIM-records staan onder een selector, zoals selector1._domainkey.example.com of dkim._domainkey.example.com. De afzender gebruikt die selector en de ontvanger haalt de publieke sleutel uit DNS.

Een typische waarde:

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

Veelvoorkomende fouten:

1. Na rotatie gebruikt de mailserver nog de oude selector.
2. Na providerwisseling ontbreekt de nieuwe sleutel.
3. De DNS-host verwerkt de lange TXT-waarde verkeerd.
4. Een mailinglijst herschrijft de body en breekt de handtekening.

Gebruik waar compatibel 2048-bits sleutels als aanbevolen standaard, tenzij provider of DNS een geteste andere keuze vraagt. Legacy-omgevingen gebruiken soms 1024-bits sleutels; plan een compatibele migratie in 2026.

Op TrekMail-plannen met beheerde SMTP en geactiveerde domein-DKIM kan uitgaande mail met de domeinsleutel worden ondertekend. Raadpleeg bij fouten Mijn e-mails gaan naar spam.

DMARC: gevraagd beleid voor ontvangers

DMARC ligt boven SPF en DKIM. Het publiceert gevraagd beleid bij fouten en controleert alignment tussen zichtbaar From en de SPF- of DKIM-domeinen. Zonder aligned pass geen DMARC-pass.

Publiceer op _dmarc.example.com. Begin eenvoudig:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Scherp aan na inventarisatie en live tests:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

p=none vraagt geen DMARC-beperking. p=quarantine vraagt verdachte behandeling en p=reject weigering. Ontvangers behouden lokaal beleid, dus disposition is niet gegarandeerd.

Alignment is vaak de valkuil:

Zichtbare From: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
DKIM-domein: vendor.com

SPF en DKIM kunnen slagen terwijl DMARC faalt, want geen van beide is aligned met yourcompany.com.

Dit gebeurt bij Mailchimp, HubSpot, Zendesk en CRM-routes wanneer aangepaste domeinauthenticatie niet werkelijk actief is. Googles actuele FAQ vraagt voor toepasselijke bulkafzenders naar persoonlijke Gmail-accounts zowel SPF als DKIM, waarvan minstens één aligned met From voor directe mail, plus minimaal DMARC, eventueel p=none: FAQ met Googles afzenderrichtlijnen.

SPF versus DKIM versus DMARC: wat is het belangrijkst?

Elk doet iets anders. DKIM blijft onder voorwaarden beter behouden bij forwarding, SPF autoriseert het IP-pad en DMARC koppelt alignment aan beleid. De volledige stack is nodig waar actuele regels dat vragen.

Bij één mailserver zonder SaaS is configuratie vaak overzichtelijk. Met servicedesk, nieuwsbrief, CRM en forwarding toont DMARC welke werkelijke routes aligned zijn. Rapporten zijn niet altijd volledig; verifieer met headers en logs.

Waarom forwarding en mailinglijsten vreemde fouten geven

Forwarding kan SPF breken doordat de forwarder verder verzendt. DKIM kan helpen als de geldige aligned handtekening intact blijft, maar een herschreven body of onderwerp kan ook DKIM breken.

Op papier kan alles juist lijken terwijl het indirecte pad faalt: het IP verandert, een lijst voegt een footer toe en beide aligned signalen verdwijnen. Dat verklaart DMARC-fail, niet automatisch de uiteindelijke aflevering.

ARC laat tussenpartijen authenticatiegeschiedenis vastleggen en geeft een ontvanger lokale context; het bewaart vertrouwen of converteert een fail niet automatisch. Googles richtlijnen behandelen indirecte mail en ARC apart. Houd als afzender DKIM gezond en vermijd fragiele routes. Zie DMARC-alignment en e-mailforwarding.

Andere controles die aflevering beïnvloeden

Geldige records garanderen geen inbox. Ontvangers beoordelen ook reverse DNS, TLS, klachten, reputatie en afmelden. SPF, DKIM en DMARC zijn de basis, niet het hele model.

1. Forward-confirmed reverse DNS: het verzend-IP heeft een PTR nodig waarvan de hostnaam naar hetzelfde IP terugleidt. Google noemt geldige heen- en terug-DNS in toepasselijke eisen.
2. TLS: grote providers verwachten TLS; Googles FAQ noemt niet-TLS-mail als mogelijke reden voor tijdelijke of permanente fouten.
3. Spamklachten: Googles toepasselijke richtlijn noemt minder dan 0.1% en waarschuwt voor 0.3%; dit is geen inboxgarantie.
4. Afmelden met één klik: voor toepasselijke promotiemail worden headers volgens RFC 8058 verwacht, niet alleen een verborgen footerlink.

Bij een nieuw domein zijn geleidelijke verzending en toestemming extra belangrijk. Een plotselinge campagne of slechte lijst kan reputatiesignalen schaden.

Configureren zonder productie te verstoren

Inventariseer alle afzenders, publiceer doelgericht, verifieer live en voer DMARC gefaseerd op. Test zeldzame kritieke routes over meerdere representatieve perioden en houd rollback gereed.

1. Noteer mailboxhost, CRM, servicedesk, nieuwsbriefapp, formulieren, facturatie en servers.
2. Combineer ondersteunde afzenders in één SPF-record; publiceer nooit twee SPF TXT-records.
3. Publiceer DKIM voor iedere werkelijk gebruikte selector.
4. Begin DMARC met p=none en beoordeel rapporten, logs en headers.
5. Activeer aangepaste domeinauthenticatie en test alignment voor externe afzenders.
6. Ga gecontroleerd naar p=quarantine en dan p=reject als representatieve data dit ondersteunt.

Voor TrekMail met beheerd verzenden kunnen basisrecords er volgens de actuele accountconfiguratie zo uitzien:

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

Dit voorbeeld is niet universeel. Gebruik accountwaarden en live verificatie uit Vereiste DNS-records en DNS-status controleren. Zie ook e-mail op mijn domein instellen.

Oude tegenover nieuwe aanpak

Traditioneel betaalde men per gebruiker voor een grote suite of beheerde men DNS, TLS, selectors en reputatie zelf. Een modulaire omgeving kan mailboxhosting en verzending scheiden en validatie en migratie bundelen.

Volgens het huidige aanbod kan Nano maximaal 10 domeinen met 5 GB gedeelde opslag en BYO SMTP omvatten. Betaalde plannen beginnen momenteel bij $3.50 per maand en kunnen beheerde SMTP bieden. Functies zoals aangepaste domeinen, IMAP, catch-all, forwarding, IMAP-migratie en API-toegang hangen van het plan af. Voor betaalde plannen kan een gratis proefperiode van 14 dagen met creditcard gelden; Nano kan volgens huidige voorwaarden gratis zonder kaart zijn. Controleer prijzen, functies en limieten.

Voor veel domeinen kunnen één dashboard, gedeelde opslag, accountgebonden DNS-records en server-side migratie werk bundelen, zonder kostenbesparing te garanderen. Vergelijk multi-domein e-mailhosting en TrekMail-prijzen.

Conclusie: SPF, DKIM en DMARC zijn de basis

SPF autoriseert IP's voor het envelope-domein. DKIM valideert de handtekening en intacte ondertekende data. DMARC koppelt een aligned resultaat aan zichtbaar From en publiceert gevraagd beleid.

Publiceer één geldig SPF-record, werkende DKIM en aanvankelijk DMARC met p=none. Verifieer iedere afzender en zeldzame route live. Ga na meerdere representatieve perioden en met rollback richting handhaving. Dat vermindert vermijdbare diagnose, maar garandeert geen kosten of uitkomst.