DMARC van p=none naar p=quarantine zonder legitieme mail te verliezen
Een DMARC-record met p=none vraagt mailboxproviders om te rapporteren over mail die niet door de authenticatie komt, maar die mail gewoon af te leveren. Het is de juiste plek om te beginnen en de verkeerde plek om te blijven: iedereen kan nog steeds mail versturen met uw domein in het From-veld, en ontvangers krijgen van u geen instructie om die als verdacht te behandelen.
Met p=quarantine laat u ontvangers weten dat falende mail als verdacht moet worden behandeld, wat in de praktijk meestal de spammap betekent. Het risico zit niet in de wijziging zelf. Het risico is een legitieme dienst (facturatie, helpdesk, CRM, nieuwsbrief) die op de dag van de overstap nog steeds faalt voor DMARC, waardoor uw eigen berichten in spam belanden.
Het korte antwoord: lees uw aggregaatrapporten tot elke legitieme afzender slaagt met aligned DKIM, schakel eerst over naar p=quarantine met testmodus, vergelijk de rapporten en verwijder daarna de testmodus. De details volgen hieronder. Wilt u de 3 records nog eens opfrissen, lees dan SPF, DKIM en DMARC uitgelegd.
Wat p=none echt doet
DMARC is nu vastgelegd in RFC 9989, gepubliceerd in mei 2026, die RFC 7489 heeft vervangen. Die noemt p=none Monitoring Mode en legt uit waarom die modus bestaat: behalve in de eenvoudigste omgevingen kan een domeineigenaar een server of een afspraak met een externe verzender over het hoofd zien, en de rapporten brengen dat aan het licht.
De waarde quarantine betekent dat de domeineigenaar falende mail als verdacht beschouwt. De uiteindelijke beslissing ligt bij de ontvanger, maar bij de meeste mailboxproviders betekent dat de spammap. Google zegt het duidelijk in zijn aanbevolen uitrol van DMARC: berichten die niet slagen voor DMARC gaan naar de spammap van de ontvanger.
Stap 1: zorg dat elke legitieme afzender slaagt
RFC 9989 is duidelijk over de volgorde. Legitieme mailstromen die falen omdat hun identifiers niet aligned zijn of ontbreken, MOETEN worden opgelost voordat u een afdwingend beleid publiceert.
Werk uw aggregaatrapporten door (onze uitleg over hoe u een DMARC-aggregaatrapport leest loopt de XML stap voor stap door) en maak een lijst van elke bron:
- Uw belangrijkste mailprovider: hoort te slagen met aligned DKIM en SPF.
- Elke externe tool die als uw domein verstuurt: schakel in de instellingen DKIM-ondertekening met uw eigen domein in. Een tool die alleen voor SPF slaagt op zijn eigen envelopdomein, is niet aligned en faalt voor DMARC.
- Doorstuurdiensten en mailinglijsten: die breken vaak SPF. DKIM-handtekeningen blijven doorgaans geldig wanneer mail wordt doorgegeven, nog een reden om op DKIM te vertrouwen en niet alleen op SPF.
- Onbekende bronnen die falen: precies die wil het nieuwe beleid tegenhouden.
Hoe lang u observeert, beslist u zelf. Google raadt minstens 1 week met p=none aan, omdat dat meestal genoeg is om al uw mailstromen in de rapporten te zien. RFC 9989 merkt op dat het, afhankelijk van hoe vaak u verstuurt, vele maanden kan duren. Denk aan mail die u 1 keer per kwartaal of per jaar verstuurt: loonstroken, jaarfacturen, herinneringen voor verlengingen. Staan die nog niet in uw rapporten, dan hebt u ze ook nog niet zien slagen.
Stap 2: schakel eerst over met testmodus
Onder RFC 7489 was de pct-tag de gebruikelijke manier om geleidelijk over te stappen (het beleid toepassen op een percentage van de falende mail). RFC 9989 heeft pct geschrapt, omdat ontvangers andere waarden dan 0 en 100 niet consequent toepasten. In de plaats daarvan is er een testmodustag, t:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"
Met t=y vraagt u ontvangers 1 niveau onder het opgegeven beleid toe te passen, dus p=quarantine; t=y wordt behandeld als none, terwijl tussenpartijen zoals mailinglijsten hun verwerking van uw mail al kunnen aanpassen. De tag verandert niets aan de rapportage. Vergelijk uw rapporten van voor en na: ze laten zien hoeveel van uw mail via doorgiftes loopt die zouden falen zodra het beleid wordt afgedwongen.
Sommige providers beschrijven nog de oudere aanpak met percentages; de uitrolgids van Google toont bijvoorbeeld pct=5 als startwaarde. Ontvangers die t nog niet ondersteunen, negeren de tag gewoon, dus zie de testmodus als een zachte start en niet als vangnet.
Stap 3: handhaaf en blijf opletten
Zien de rapporten in testmodus er goed uit, verwijder dan de tag:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
In de eerste weken na de wijziging:
- Lees de rapporten dagelijks en zoek naar
disposition-waardenquarantinebij bronnen die u herkent. - Vraag de teams die naar klanten mailen (financiën, verkoop, support) om het te melden als er minder antwoorden komen of klanten zeggen dat mail in spam belandde.
- Behandel elke nieuwe tool die als uw domein verstuurt als een wijzigingsverzoek: eerst DKIM met uw domein, dan pas live.
- Houd de toegang tot DNS overzichtelijk. Een DMARC-record dat een behulpzame externe partij stilletjes terugzet naar
p=none, maakt al het werk ongedaan.
Subdomeinen en domeinen die niets versturen
Zonder sp-tag geldt het p-beleid ook voor subdomeinen. Verstuurt een subdomein marketingmail via een apart platform, controleer het dan in de rapporten voor de overstap, of geef het een eigen _dmarc-record. De np-tag stelt een beleid in voor subdomeinen die helemaal niet bestaan, een gangbare keuze voor namen waarvandaan nooit iemand zou mogen versturen.
Domeinen die u bezit maar nooit voor mail gebruikt (oude merknamen, defensieve registraties) zijn het eenvoudige geval: zonder legitieme afzenders kunnen ze meteen naar een afdwingend beleid. Juist zulke domeinen zijn aantrekkelijk voor fraude met valse facturen, omdat niemand ze in de gaten houdt.
Voordat u verder gaat naar p=reject
p=reject is de volgende stap, maar RFC 9989 is daar voorzichtig mee bij domeinen waarvan de gebruikers naar mailinglijsten posten. Het raadt aan p=none minstens een maand te gebruiken, daarna p=quarantine even lang, en eerst de resultaten te vergelijken. Grote mailboxproviders verwachten al DMARC van afzenders met grote volumes, zoals beschreven in de afzendervereisten van Gmail en Yahoo, dus een stabiel p=quarantine is op zichzelf al een sterke positie.
Korte checklist
- Aggregaatrapporten lang genoeg verzameld om ook zeldzame mailstromen te bevatten.
- Elke legitieme afzender slaagt voor DMARC met aligned DKIM.
p=quarantine; t=ygepubliceerd en de rapporten van voor en na vergeleken.- Testmodus verwijderd, rapporten de eerste weken dagelijks gelezen.
- Subdomeinen en ongebruikte domeinen afgedekt met
sp,npof eigen records.
De rol van Guarding
Zodra uw beleid wordt afgedwongen, is het grootste risico dat het stilletjes weer verandert. Wij bewaken dagelijks van buitenaf uw SPF-, DKIM- en DMARC-records en de rest van wat wij bewaken, zonder uw systemen binnen te gaan. Wordt een record afgezwakt of verdwijnt een DKIM-selector, dan beoordeelt een mens dat en krijgt u de precieze wijziging die u moet doorvoeren, zoals beschreven bij wat er gebeurt als we iets vinden. Hoe dat eruitziet, ziet u in het voorbeelddashboard.
Meer artikelen
Zo leest u een DMARC-aggregaatrapport (rua) en wat u ermee doet
DMARC-aggregaatrapporten tonen elke server die mail onder uw domein verstuurde en of die slaagde. Zo leest u de XML en maakt u er een lijst met verbeteringen van.
Vastgezet
Guarding bewaakt nu ook InvestTimes.com
Invest Times, een Engelstalig financieel dagblad over startups en beleggen uit onze groep, wordt nu bewaakt door Guarding. Wij bewaken InvestTimes.com van buitenaf, de klok rond.
PHP2Shell: welke PHP-versies zijn gepatcht en hoe controleert u de uwe
Het PHP-project dichtte op 21 oktober 2026 2 kritieke lekken. Welke versies de oplossing bevatten, hoe u ziet wat uw server meldt en wat u uw hostingprovider vraagt.