1. Begin met een lijst van alle verzendroutes
Schrijf op welke diensten mail met jouw domein als zichtbare afzender versturen. Denk aan je gewone mailbox, het contactformulier op je website en een nieuwsbriefdienst. Noteer per route de dienst, het afzenderadres en de beheerder. Een nieuwe route kan andere instellingen nodig hebben dan de mailbox die al jaren werkt.
Haal de actuele instructies bij iedere betrokken provider op voordat je DNS wijzigt. DNS bevat onder meer de openbare gegevens waarmee andere mailservers je domein controleren. Maak geen wijziging op basis van alleen een algemeen voorbeeldrecord. Een voorbeeld voor één maildienst weet niets van de andere systemen die jij gebruikt.
2. SPF controleert de verzendende server
SPF publiceert welke servers namens een domein mogen verzenden. De controle gebruikt het domein van de technische envelopafzender, doorgaans terug te zien als Return-Path. Dat hoeft niet hetzelfde domein te zijn als het adres dat de ontvanger in het Van-veld ziet. De SPF-standaard beschrijft die serverautorisatie; SPF controleert niet zelfstandig of de zichtbare afzender erbij past.
Let op bij een extra leverancier: zet niet zomaar een tweede SPF-record naast het bestaande record voor dezelfde domeinnaam. Meer dan één geselecteerd SPF-record veroorzaakt een fout. Laat de beheerder de toegestane verzenders in één passende configuratie verwerken, met aandacht voor de SPF-zoeklimieten. Verwijder daarbij geen bestaande verzenddienst die nog in gebruik is.
3. DKIM voegt een controleerbare handtekening toe
Bij DKIM ondertekent de verzenddienst uitgaande berichten met een privésleutel. De ontvangende server controleert de handtekening met de publieke sleutel die via DNS beschikbaar is. Daardoor kan de ontvanger de ondertekenende domeinnaam en de geldigheid van de handtekening controleren. Het is geen versleuteling die de mailinhoud geheim maakt.
Volg de DKIM-instructie van jouw provider. Alleen een DNS-record plaatsen is niet in iedere dienst voldoende: de dienst moet ook daadwerkelijk ondertekenen. Google beschrijft daarom zowel inschakelen als verifiëren. Deel nooit privésleutels of mailboxwachtwoorden in een supportbericht. Voor onderzoek zijn doorgaans de gebruikte domeinnaam, provider en relevante testresultaten voldoende.
4. DMARC controleert de aansluiting op het Van-domein
DMARC verbindt de authenticatie met het domein in de zichtbare From-header, het Van-veld. Een bericht slaagt wanneer minstens één route klopt: SPF slaagt én het SPF-domein sluit aan, of DKIM slaagt én het ondertekenende domein sluit aan. Die aansluiting heet alignment. Bij strikte alignment moeten de domeinen identiek zijn; de ruimere variant kijkt naar hetzelfde organisatorische domein.
De DMARC-standaard benadrukt dat een geslaagde controle alleen het gebruik van het afzenderdomein bevestigt. Ze beoordeelt niet of de inhoud betrouwbaar is en garandeert geen inboxplaatsing. Via het DMARC-beleid geef je bovendien een voorkeur door voor berichten die niet slagen. De ontvangende dienst maakt uiteindelijk haar eigen afhandelingskeuze.
5. Wijzig het beleid pas nadat je de routes begrijpt
Laat eerst SPF en DKIM per legitieme verzendroute controleren. Google adviseert bij een nieuwe DMARC-inrichting te beginnen met een observerend beleid: p=none. Met ingestelde rapportage kun je vervolgens onderzoeken welke bronnen je domein gebruiken en waar controles misgaan. Dat beleid vraagt niet om weigering op basis van een DMARC-fout.
Beoordeel de rapporten voordat je naar quarantine of reject gaat. Anders kan ook een vergeten, legitieme verzenddienst worden geraakt. Laat een beheerder vastleggen wat verandert, hoe bestaande routes worden getest en hoe een onbedoelde fout wordt hersteld. Gebruik geen kopieerbaar universeel record: de verzenders, rapportagebestemming en huidige inrichting bepalen wat bij jouw bedrijf past.
6. Controleer een ontvangen testbericht per route
Stuur per bedoelde route een herkenbaar testbericht naar een testmailbox die je zelf beheert. Bekijk de oorspronkelijke berichtheaders bij de ontvanger; in Gmail kan dat via Origineel weergeven. Zoek de Authentication-Results en vergelijk SPF, DKIM en DMARC met de gebruikte domeinen. De Google-handleiding voor DKIM laat zien hoe je zo de ondertekening controleert.
Fictief voorbeeld: een studio gebruikt een gewone mailbox en een afzonderlijke formulierdienst. De mailboxproef toont DMARC=pass. De formuliermail toont SPF=pass voor het leveranciersdomein, maar geen geldige, aansluitende DKIM-handtekening en DMARC=fail voor het Van-domein van de studio. Die eerste proef bewijst dus niet dat beide routes goed staan. De beheerder onderzoekt de aansluiting en ondertekening bij de formulierdienst; de studio vervangt niet blind alle DNS-records.
Bewaar per test route, tijdstip, afzender, resultaat en vervolgstap. Deel volledige headers alleen waar nodig: ze kunnen adressen en andere technische gegevens bevatten. Een geslaagde proef is bewijs voor die geteste route, geen garantie voor iedere toekomstige mail.
7. Houd de mailboxkoppeling in MANE apart
MANE kan je mailbox via Gmail of IMAP en SMTP verbinden. Volgens de handleiding voor IMAP en SMTP worden bij het koppelen de verbindingen getest zonder een testmail te verzenden. Een succesvolle koppeling bewijst daarom niet dat je zakelijke domein voor alle verzendroutes correct is geauthenticeerd. Gebruik de provider- en DNS-controle naast die verbindingscontrole.
Ook een SMTP-bevestiging heeft een beperkte betekenis: jouw mailserver heeft het bericht aangenomen. Zij bewijst niet dat de ontvanger het heeft ontvangen of gelezen. Laat domeininstellingen door de bevoegde beheerder controleren en test daarna de route die je werkelijk in MANE gebruikt. Zo kun je onderscheid maken tussen een verbindingsprobleem, een authenticatieprobleem en een afzonderlijk afleverprobleem.
