Hoe DMARC instellen met controle van legitieme mail

Zoekt u hoe u DMARC instelt? Begin niet meteen met p=reject. Start doorgaans met monitoring, controleer geslaagde SPF of DKIM met uitlijning voor uw werkelijke verzenders en beoordeel daarna stapsgewijze handhaving. Dat kan domeinmisbruik beperken zonder vergeten factuur-, herstel- of SaaS-stromen onnodig te treffen.

De praktijk is minder overzichtelijk dan een schema. Een domein gebruikt Microsoft 365, facturatie loopt via een externe app, marketing via een ander platform en een scanner verstuurt nog documenten. Een vergeten bron kan bij handhaving uitval veroorzaken. Lees ook e-mail op mijn domein instellen en de bredere gids voor zakelijke e-mail.

Deze gids volgt de beheerpraktijk: gegevens verzamelen, bronnen controleren, uitlijning herstellen en pas daarna beleid beoordelen. Monitoring is een startpunt, geen bewijs dat iedere volgende stap veilig is.

Wat doet DMARC?

DMARC publiceert via DNS uw gewenste behandeling van berichten die uw domein als afzender tonen maar de authenticatie- en uitlijningsvoorwaarden niet halen. Het bouwt voort op SPF en DKIM: minstens één moet slagen én uitgelijnd zijn met het zichtbare From-domein.

DMARC staat voor Domain-based Message Authentication, Reporting, and Conformance. U publiceert een beleidsverzoek en vraagt rapporten over waargenomen mailstromen. De basisspecificatie is RFC 7489.

De belangrijkste regels bij het instellen:

SPF-pass zonder uitlijning is onvoldoende, maar geslaagde uitgelijnde DKIM kan DMARC alsnog laten slagen.
DKIM-pass zonder uitlijning is onvoldoende, maar geslaagde uitgelijnde SPF kan DMARC alsnog laten slagen.
DMARC slaagt als SPF of DKIM zowel slaagt als uitgelijnd is.

Google vraagt bulkverzenders SPF, DKIM en ten minste DMARC met p=none, naast toepasselijke uitlijningseisen. Voor algemene verzenders gelden niet automatisch alle bulkeisen. Zie Google's veelgestelde vragen over verzendrichtlijnen.

Controleer de basis vóór DMARC

Controleer eerst uw verzendomgeving. Ontbrekende DKIM, ongeldige SPF of leveranciersdomeinen zonder uitlijning kunnen zichtbaar worden in de beoordeling. Vooral ongeteste handhaving kan dan legitieme mail raken.

Controleer deze drie onderdelen:

SPF: gebruik één toepasselijk record per werkelijk envelopdomein en respecteer de limiet van 10 DNS-opzoekende mechanismen en modifiers, inclusief geneste evaluatie, niet alle DNS-query's samen.
DKIM: activeer het waar ondersteund en gebruik sleutels van 2048 bits als de leverancier die ondersteunt.
Broninventarisatie: neem mailhosting, CRM, facturatie, helpdesk, formulieren, scanners en marketing op.

Voor TrekMail helpen Vereiste DNS-records en Een domein toevoegen. DNS-controles kunnen ontbrekende of dubbele records aanwijzen, maar vervangen geen echte authenticatietests.

Uw factuurapp verzendt als billing@yourdomain.com, maar ondertekent met het leveranciersdomein en gebruikt diens return-path. SPF en DKIM kunnen voor die leverancier slagen, terwijl DMARC voor uw From-domein faalt doordat geen geslaagde authenticatie uitgelijnd is.

Dat verklaart waarom ongeteste beleidswijzigingen mail kunnen raken. Het publiceren van monitoring veroorzaakt zo'n authenticatiefout niet zelf.

Stap 1: publiceer een monitoringrecord

Begin doorgaans met p=none. Daarmee vraagt u geen quarantine of reject op grond van DMARC en kunt u rapporten aanvragen. Rapportage is niet gegarandeerd en lokale filtering blijft mogelijk.

Maak TXT op _dmarc.yourdomain.com met deze waarde:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Dezelfde waarde als zoneregel, niet als extra record om daarnaast te publiceren:

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Dit sluit aan bij het voorbeeld in RFC 7489. Gebruik een beheerd rapportagepostvak of alias; aggregatierapporten zijn XML en kunnen talrijk zijn. Controleer privacy, toegang en eventuele DNS-autorisatie voor een externe bestemming.

Controleer het gepubliceerde record en test de verzenders, ongeacht waar uw DNS wordt beheerd. De FAQ mijn mail komt in spam terecht kan helpen bij onderzoek naar doorsturen en authenticatiefouten. Een groene status bewijst niet alle werkelijke mailstromen.

Stap 2: lees rapporten en onderzoek bronnen

Rapporten helpen bij brononderzoek, maar zijn geen volledige inventarisatie of automatische scheiding tussen legitiem verkeer en misbruik. Combineer gegevens van deelnemende ontvangers met eigen logs en tests.

Rapporten kunnen onder meer tonen:

Waargenomen bron-IP's
SPF-authenticatieresultaten
DKIM-authenticatieresultaten
Uitgelijnde resultaten voor de DMARC-beoordeling
De door de ontvanger gerapporteerde behandeling

Maak onderscheid tussen onderzochte bronnen en nog onbekend verkeer.

Bevestigde legitieme bronnen met fouten vragen herstel. Onbekende IP's vragen onderzoek: doorstuurservers of gedeelde relays kunnen daar ook onder vallen. Een authenticatiepass bewijst geen veilige inhoud.

Deze tabel geeft voorbeelden, geen vaste beoordeling van iedere leverancier of configuratie:

Verzender	SPF	DKIM	Uitlijning	Betekenis
Goed ingerichte Microsoft 365- of TrekMail-mailbox	Pass	Pass	Pass	Authenticatie klopt in dit voorbeeld; controleer ook de werkelijke route.
Mailchimp of SendGrid zonder passende domeinconfiguratie	Pass	Pass	Fail	Authenticatie slaagt, maar niet uitgelijnd met uw domein; standaardinstellingen verschillen.
Doorgestuurd bericht met geldige uitgelijnde DKIM	Fail	Pass	Pass via DKIM	Kan bij doorsturen voorkomen als de ondertekende gegevens behouden blijven.
Bevestigde domeinspoofing vanaf een onbekend IP	Fail	Fail	Fail	Handhaving kan dit beperken; het IP of falen alleen bewijst geen spoofing.

Bij veel domeinen vraagt iedere nieuwe dienst aandacht voor authenticatie en beheer. E-mailhosting voor meerdere domeinen kan de inrichting helpen vereenvoudigen, maar garandeert geen lagere kosten of minder tickets.

Stap 3: herstel uitlijning, niet alleen authenticatie

Een SPF- of DKIM-pass zonder uitlijning volstaat niet. Het bij een geslaagde authenticatie gebruikte domein moet volgens de gekozen modus overeenkomen met het zichtbare From-domein of hetzelfde organisatiedomein delen.

RFC 7489 definieert relaxed alignment als hetzelfde organisatiedomein voor het SPF- of DKIM-domein en RFC5322.From. Voor DMARC volstaat één geslaagde uitgelijnde methode; beide instellen blijft nuttig waar ondersteund.

Veelvoorkomende oplossingen:

Marketingplatform: configureer DKIM-ondertekening voor uw domein waar ondersteund.
Bounceverwerking: configureer een passende return-path of bouncedomein waar ondersteund.
Microsoft 365: activeer en test DKIM voor uw eigen domein vóór handhaving.
Beheerde TrekMail-verzending: publiceer de toepasselijke SPF- en DKIM-records uit uw actuele configuratie.

Volg altijd de werkelijk gebruikte uitgaande verzender. TrekMail kan configuratiehulp en verschillende verzendopties bieden, met eigen SMTP voor Nano en beheerde SMTP volgens de betaalde abonnementen. De inrichting en limieten blijven afhankelijk van het abonnement.

Nano wordt beschreven met eigen SMTP en betaalde abonnementen met beheerde SMTP. De genoemde vanafprijs is $3.50/maand, met een aangeboden gratis proefperiode van 14 dagen voor betaalde abonnementen en een gratis Nano-optie zonder kaart. Controleer actuele mogelijkheden, proefvoorwaarden en prijzen bij TrekMail-prijzen.

Stap 4: beoordeel quarantine

Na onderzoek van legitieme bronnen kunt u quarantine overwegen. Dat is al handhaving: u vraagt ontvangers om falende mail als verdacht te behandelen. Het garandeert geen specifieke spammap, herstelbaarheid of veilige tussenstap voor ieder domein.

Vervang het bestaande beleid indien passend door:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Waarom kan quarantine vóór reject nuttig zijn?

Het vraagt strengere behandeling van DMARC-falende mail.
Het kan minder ingrijpend uitpakken dan weigering, maar legitieme mail kan nog steeds worden geraakt.
U kunt de gevolgen onderzoeken, met monitoring en een herstelplan.

Observeer lang genoeg om relevante stromen te beoordelen. Een paar weken kan een eerste richtlijn zijn; ook 30 dagen bewijst geen volledigheid. Test zeldzame, maandelijkse en kwartaalstromen afzonderlijk.

Een vergeten WordPress-plugin, CRM-testomgeving, scanner of periodieke leverancier kan pas later zichtbaar worden. Vertrouw daarom niet alleen op een stille rapportageperiode.

Stap 5: beoordeel reject na voldoende controle

p=reject vraagt ontvangers DMARC-falende mail te weigeren. Dat kan directe domeinspoofing beperken, maar voorkomt niet alle vormen van impersonatie en garandeert geen inboxplaatsing.

Een passend eindbeleid kan het bestaande record vervangen:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

RFC 7489 beschrijft weigering op verzoek van p=reject. Ontvangers kunnen lokaal afwijken; beschouw het niet als gegarandeerde blokkering van ieder bericht.

Controleer vóór deze stap:

De werkelijke mailboxverzending slaagt en is uitgelijnd.
Marketing- en transactionele bronnen slagen en zijn uitgelijnd.
U hebt rapporten over relevante perioden bekeken, niet alleen enkele rustige weken.
Resterende fouten zijn onderzocht en zeldzame kritieke stromen zijn getest.

Blijf rapporten, logs en wijzigingen volgen. DMARC hoort bij doorlopend wijzigingsbeheer.

Fouten die mail kunnen raken

Vooral ontbrekende bronnen, dubbele SPF, ongeteste DKIM en leveranciersconfiguraties zonder uitlijning verdienen aandacht. Monitoring publiceren is op zichzelf geen oorzaak van authenticatiefalen; onzorgvuldige handhaving kan de gevolgen vergroten.

Handhaving invoeren voordat DKIM en de routes zijn getest.
Meerdere SPF-records publiceren in plaats van één toepasselijk record.
SPF-pass automatisch als DMARC-pass zien.
Laagvolumeleveranciers vergeten.
Direct van geen DMARC naar p=reject gaan.
Rapporten naar een onbeheerde bestemming sturen.

Doorsturen kan SPF laten falen terwijl geldige uitgelijnde DKIM DMARC ondersteunt, mits de ondertekende gegevens volgens canonicalisatie intact blijven. Lees ook e-mailalias doorsturen en veilige zakelijke e-mail.

Korte checklist voor DMARC

Deze checklist helpt de beoordeling structureren, maar is geen garantie dat handhaving na een vaste periode veilig is.

Inventariseer alle bronnen die uw domein gebruiken.
Gebruik één geldige SPF per toepasselijk envelopdomein binnen de evaluatielimieten.
Activeer en test DKIM bij ondersteunde verzenders.
Publiceer monitoring, bijvoorbeeld v=DMARC1; p=none; rua=mailto:....
Onderzoek rapporten samen met logs en brongegevens.
Herstel geslaagde authenticatie met uitlijning voor legitieme bronnen.
Beoordeel p=quarantine en de gevolgen ervan.
Blijf gegevens en kritieke stromen controleren.
Beoordeel p=reject met tests en een herstelplan.

Samenvatting: zorgvuldig DMARC instellen

Begin doorgaans met p=none, onderzoek bronnen en herstel authenticatie met uitlijning. Beoordeel daarna p=quarantine en eventueel p=reject. Deze aanpak helpt risico's beheersen, maar garandeert geen aflevering of volledige bescherming tegen spoofing.

Bij tientallen of honderden domeinen kan een samenhangende omgeving helpen. TrekMail kan volgens het abonnement eigen domeinen, IMAP-postvakken, catch-all, doorsturen en migratie bieden, met eigen of beheerde SMTP. IMAP kopieert ondersteunde berichten; MX-overgang en overige appgegevens vragen aparte aandacht. Vergelijk kosten en limieten voor uw situatie.

Zo pakt u DMARC instellen praktisch aan: onderzoek eerst, test uitlijning en beoordeel beleid op basis van meer dan rapporten alleen.