DMARC-fouten bij forwarding: oorzaken en oplossingen

Meldingen over DMARC-fouten komen vaak nadat je dacht dat de lastige inrichting klaar was. SPF staat live, DKIM ook, en je DMARC-beleid staat inmiddels op p=quarantine of p=reject. Dan wordt een legitiem bericht doorgestuurd en komt het niet aan. Het hoeft geen spoofing of spam te zijn: de route kan authenticatie verstoren. Het beleid vraagt om een behandeling, maar de ontvanger bepaalt uiteindelijk wat er gebeurt.

Dat is het lastige aan een DMARC-fout bij forwarding. Een legitiem bericht kan via een tussenstap terechtkomen in een andere aflevercontext, waardoor de eindontvanger niet langer dezelfde vertrouwenssignalen ziet. Als je SPF en DKIM alleen als afgevinkte instellingen kent, lijkt dat willekeurig. Door het pad en de domeinen te onderzoeken kun je het patroon herkennen en gerichter herstellen.

Begin voor de bredere basis bij zakelijke e-mail. Gebruik je al forwarding, lees dan ook de gids over e-mailforwarding.

Wat een DMARC-fout werkelijk betekent

Een DMARC-fout betekent dat het bericht geen geslaagde, afgestemde SPF of geslaagde, afgestemde DKIM opleverde voor het zichtbare From-domein. Authenticatie alleen is niet genoeg. DMARC controleert of het geauthenticeerde domein volgens de gekozen afstemmingsmodus past bij het domein dat de ontvanger ziet.

DMARC bouwt voort op SPF en DKIM. Volgens het basisprincipe beschreven in de historische specificatie RFC 7489 slaagt een bericht voor DMARC als ten minste één van de volgende voorwaarden geldt:

1. SPF slaagt en het domein is afgestemd op het Header From-domein.
2. DKIM slaagt en het domein is afgestemd op het Header From-domein.

Dat klinkt eenvoudig. Toch ontstaat een DMARC-fout vaak doordat beheerders verschillende begrippen door elkaar halen:

• Authenticatie: slaagde SPF of DKIM?
• Domeinafstemming: past het domein van de geslaagde controle bij het Header From-domein?
• Bestandheid tegen forwarding: bleef het bericht over de tussenstap voldoende intact?

SPF kan slagen terwijl er toch een DMARC-fout ontstaat. DKIM kan slagen terwijl er toch een DMARC-fout ontstaat. Als geen enkele geslaagde identiteit is afgestemd op het zichtbare domein, slaagt DMARC niet.

Waarom forwarding vaak DMARC-fouten veroorzaakt

Forwarding kan een DMARC-fout veroorzaken doordat het afleverpad en soms de inhoud veranderen. SPF is afhankelijk van de verbinding; DKIM van de integriteit van ondertekende gegevens. Een doorgestuurd bericht kan de ene controle verliezen, en inhoudswijzigingen kunnen ook de andere aantasten.

Een veelvoorkomend pad:

1. Een afzender verstuurt mail vanaf sender.com.
2. Een tussenliggende mailbox of gateway ontvangt het bericht.
3. Dat systeem stuurt het automatisch door naar Gmail, Outlook of een andere bestemming.

De eindontvanger ziet dan niet meer het oorspronkelijke afzender-IP als SMTP-client, maar het IP van de doorstuurserver.

Daar kan een DMARC-fout beginnen.

SPF komt als eerste onder druk te staan

SPF is vastgelegd in RFC 7208. Het controleert of het verbindende IP mag versturen voor het envelopdomein.

Na forwarding is het verbindende IP dat van de doorstuurserver. Als dit IP niet voor het oorspronkelijke envelopdomein is toegestaan, faalt SPF. SRS kan de envelopafzender herschrijven naar een domein van de forwarder waarvoor SPF wel slaagt, maar daarmee ontstaat niet automatisch DMARC-afstemming met het oorspronkelijke From-domein.

Oorspronkelijk pad: sender.com verstuurt vanaf IP A. SPF slaagt.
Doorgestuurd pad: een tussenpartij verstuurt vanaf IP B. De ontvanger controleert sender.com tegenover IP B. SPF faalt als dat IP niet is toegestaan.

Dit SPF-resultaat veroorzaakt op zichzelf niet noodzakelijk een DMARC-fout. Als geldige, afgestemde DKIM intact blijft, slaagt DMARC alsnog. Daarom verdient DKIM bij indirecte afleverroutes bijzondere aandacht.

DKIM kan de authenticatieroute behouden

DKIM, beschreven in RFC 6376, ondertekent geselecteerde headers en de body. Het controleert niet welk IP het bericht doorstuurt. Daardoor kan DKIM een geslaagde DMARC-route bieden wanneer SPF verloren gaat.

Dat helpt alleen wanneer beide voorwaarden gelden:

1. De handtekening is na forwarding nog geldig.
2. Het d=-domein is afgestemd op het zichtbare From-domein.

Ontbreekt een van die voorwaarden en is er geen andere afgestemde authenticatieroute, dan kan een DMARC-fout volgen.

Forwarders wijzigen berichten soms op manieren die handtekeningen kunnen breken:

• [EXTERNAL] toevoegen aan het onderwerp
• Disclaimers of juridische voetteksten toevoegen
• MIME-boundaries herschrijven
• Regelafbreking of witruimte wijzigen

Sommige wijzigingen vallen binnen relaxed DKIM-canonicalisatie; andere niet. Het effect hangt af van de ondertekende velden en de concrete wijziging. Een DMARC-fout na forwarding bewijst dus geen spoofing: onderzoek eerst of de implementatie een legitiem bericht heeft veranderd.

De afstemmingsvalkuil zonder forwarding

Een DMARC-fout vereist geen forwarding. Een SaaS-dienst kan bijvoorbeeld met zijn eigen domein authenticeren terwijl je bedrijfsdomein in From staat. Het bericht is legitiem, maar zonder afgestemde SPF of DKIM slaagt DMARC niet.

Dit is een veelvoorkomende configuratievalkuil.

Voorbeeld:

• From: billing@yourcompany.com
• Return-Path: bounce.vendor-mail.com
• DKIM: d=vendor-mail.com

SPF kan slagen voor vendor-mail.com en DKIM kan slagen voor vendor-mail.com. Toch ontstaat een DMARC-fout, omdat geen van beide identiteiten is afgestemd op yourcompany.com.

De oplossing is aangepaste domeinauthenticatie. Laat je ESP bij voorkeur geldig en afgestemd met je domein ondertekenen. Een afgestemd envelopdomein met geslaagde SPF kan ook een DMARC-route bieden; aangepaste DKIM is vooral belangrijk wanneer forwarding SPF kan aantasten.

Overweeg je minder op aliassen te vertrouwen, lees dan domeinalias of mailbox. Onduidelijke afleverroutes kunnen authenticatieproblemen moeilijker te verklaren maken.

Een DMARC-fout onderzoeken via headers

Bij veel DMARC-fouten geven headers snel richting aan het onderzoek. Begin met Authentication-Results die door de vertrouwde ontvangende server zijn toegevoegd, niet met willekeurige gelijknamige headers. Vergelijk daarna SPF, DKIM en de relevante afstemmingsdomeinen.

Vraag de ontvanger om volledige headers en zoek bijvoorbeeld:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=pass header.i=@sender.com header.s=mail;
       dmarc=pass header.from=sender.com

Hier faalt SPF terwijl DKIM en DMARC slagen. Forwarding kan dat verklaren; het resultaat alleen bewijst de route niet. Er is op deze controle geen DMARC-fout, maar beoordeel andere afleverproblemen afzonderlijk.

Deze variant vraagt verder onderzoek:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=fail header.i=@sender.com;
       dmarc=fail header.from=sender.com

Dit kan een DMARC-fout door forwarding zijn. Het gewijzigde pad kan SPF verklaren; voor DKIM onderzoek je inhoudswijzigingen, een ongeldige handtekening, sleutelpublicatie en de oorspronkelijke controle. De headers alleen sluiten andere oorzaken niet uit.

DMARC-fouten bij forwarding beperken

Je kunt niet voorkomen dat ontvangers mail doorsturen. Beperk DMARC-fouten door ermee rekening te houden: geldige, afgestemde DKIM, beheersbare SPF en een route die ondertekende gegevens zo veel mogelijk intact laat. Geen enkele inrichting garandeert dat alle tussenpartijen of ontvangers hetzelfde handelen.

1. Maak DKIM een vaste vereiste voor je verzendstromen

Wil je legitieme mail beter bestand maken tegen forwarding, onderteken dan elke uitgaande stroom. Niet alleen nieuwsbrieven of supportberichten: controleer ook facturatie, appmeldingen en andere bronnen. DKIM is daarvoor een belangrijke route, al kan direct verzonden mail ook via afgestemde SPF DMARC halen.

De handtekening moet bij het zichtbare From-domein passen. Staat daar yourdomain.com, gebruik dan yourdomain.com of een subdomein dat volgens je afstemmingsmodus past. Relaxed afstemming gebruikt het organisatiedomein; strict vereist een exacte match.

Bij TrekMail begint DNS met de waarden in vereiste DNS-records. Onderzoek waarschuwingen in de DNS-status voordat je complexe forwardinggevallen beoordeelt; een statuskleur alleen bewijst geen aflevering.

2. Gebruik passende relaxed DKIM-canonicalisatie

Simple-canonicalisatie is gevoeliger voor bepaalde opmaakwijzigingen. Relaxed canonicalisatie kan toegestane normalisatie van headers en witruimte opvangen en daarmee sommige DMARC-fouten voorkomen. Ze maakt inhoudswijzigingen niet algemeen veilig.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
 c=relaxed/relaxed; h=from:to:subject:date:message-id; ...

Een toegevoegd body-footer kan de handtekening nog steeds breken. Test daarom de daadwerkelijke tussenstappen; relaxed helpt slechts bij de wijzigingen die de canonicalisatieregels normaliseren.

3. Controleer domeinafstemming bij leveranciers

Ondertekent een CRM, helpdesk of nieuwsbriefdienst met d=vendor.com, controleer dan of er een andere geldige, afgestemde DKIM-handtekening of SPF-route is. Zonder zo'n route kan een DMARC-fout ontstaan, ook zonder forwarding. Configureer passende eigen domeinauthenticatie. Aangepaste return-path en DKIM hebben verschillende functies; DMARC vereist niet automatisch beide, maar forwarding kan een SPF-afhankelijke oplossing aantasten.

4. Houd SPF binnen de evaluatielimieten

SPF kan ook los van forwarding falen als oude diensten en geneste includes zich opstapelen. RFC 7208 stelt een grens van 10 DNS-opzoekende mechanismen en modifiers tijdens evaluatie, inclusief relevante geneste paden. Overschrijding kan permerror geven, waardoor SPF geen geslaagde DMARC-route biedt.

dig +short TXT example.com

dig +short TXT _dmarc.example.com

Heb je Google, Microsoft, Mailgun, SendGrid, Zendesk en oude hosts in één record verzameld, inventariseer dan wat nog actief is. Verwijder ongebruikte bronnen en gebruik waar passend subdomeinen. Flattening kan onderhoud vereisen wanneer provider-IP's veranderen.

5. Begrijp de grenzen van SRS en ARC

SRS herschrijft de envelopafzender zodat SPF voor het domein van de forwarder kan slagen; dat herstelt niet automatisch de afstemming op het oorspronkelijke From-domein. ARC kan eerdere authenticatieresultaten vastleggen in een verifieerbare keten. Een ontvangende provider kan die meewegen als hij de tussenpartij vertrouwt. Beide vervangen geen goede DKIM en garanderen geen DMARC-succes of aflevering.

Googles huidige richtlijnen maken onderscheid tussen indirecte en directe mail en adviseren ARC voor forwardingdiensten. Dat betekent niet dat DMARC-domeinafstemming technisch verdwijnt bij forwarding. Controleer de actuele toepassing van de providerregels; in 2025 en 2026 blijft indirecte mail een belangrijk aandachtspunt.

Verwerk je veel doorgestuurde mail, beoordeel dan de functies en route van je platform. Volgens het huidige aanbod ondersteunt TrekMail mailboxforwarding en DNS-begeleiding. De documentatie voor eigen SMTP gebruiken helpt de verantwoordelijkheden voor afstemming te controleren; test je concrete combinatie.

Oude en nieuwe aanpak bij veel domeinen

De oude aanpak van DMARC-fouten was steeds meer tools toevoegen totdat niemand meer wist welk systeem ondertekende. Een beter model maakt mailboxhosting, verzending en DNS-status duidelijk zichtbaar. De vergelijking hieronder beschrijft mogelijke beheerkeuzes, geen universele nadelen van elk prijsmodel.

Dat is de praktische TrekMail-insteek: volgens de huidige voorwaarden kun je meerdere domeinen centraal hosten, opslag delen en kiezen tussen beheerde SMTP en een eigen provider. Bekijk voor deze modellen e-mailhosting voor meerdere domeinen en voor mailboxverplaatsing imapsync.

Wat te doen bij een DMARC-foutmelding

Begin bij een DMARC-fout niet automatisch met het terugzetten van reject naar none. Stel eerst vast of forwarding, ongeldige DKIM of ontbrekende afstemming de oorzaak is. Inventariseer legitieme bronnen en test herstel; kies waar nodig een gecontroleerde beleidswijziging met monitoring en rollback.

1. Vraag volledige headers op bij de ontvanger.
2. Controleer of SPF faalde doordat het verbindende IP bij een bekende forwarder hoort.
3. Controleer of DKIM slaagde of faalde en welk d=-domein ondertekende.
4. Controleer de afstemming van het ondertekenende domein met het zichtbare From-domein.
5. Zoek naar arc=pass en beoordeel de keten als het bericht via een vertrouwde tussenpartij liep.
6. Controleer SPF op te veel DNS-opzoekingen en verouderde includes.

Bij TrekMail zijn een domein toevoegen en ik ontvang geen e-mails nuttige startpunten, vooral als mail stil ontbreekt in plaats van zichtbaar terug te komen. DMARC-rapporten kunnen aanvullen, maar hun dekking is niet volledig.

Conclusie: DMARC-fouten vragen onderzoek naar het ontwerp

Een terugkerende DMARC-fout betekent niet dat e-mail onherstelbaar kapot is. Je inrichting kan te afhankelijk zijn van SPF, DKIM kan niet afgestemd of ongeldig zijn, of tussenpartijen wijzigen de mail. Sluit ook ongeautoriseerde bronnen en spoofing niet zonder onderzoek uit.

Het herstel is meestal zorgvuldig basiswerk: zorg voor afgestemde authenticatie, houd DKIM geldig, beperk SPF-complexiteit en test forwarding. Bouw die controles in je beheerproces in.

Volgens het huidige aanbod biedt TrekMail multi-domeinhosting met vaste tarieven, gedeelde opslag, IMAP-migratie, catch-all en flexibele verzending binnen de planvoorwaarden. IMAP verhuist mailboxgegevens, niet DNS, apps of reputatie, en garandeert geen onderbrekingsvrije overstap. Betaalde plannen beginnen momenteel bij $3.50 per maand met jaarlijkse facturering. Er kan een gratis proefperiode van 14 dagen gelden; Nano is onder zijn voorwaarden gratis zonder kaart. Controleer actuele prijzen of bekijk TrekMail.

Kortom: als forwarding deel van je omgeving is, hoort een DMARC-fout in je testplan. Goed geteste routes en duidelijke verantwoordelijkheden kunnen je mailbeheer robuuster maken, zonder aflevering te garanderen.