DMARC-beleid: none, quarantine en reject kiezen

Een DMARC-beleid beschrijft welke behandeling u ontvangers vraagt toe te passen op mail die DMARC niet doorstaat. Het kan helpen bij het beperken van direct domeinmisbruik, maar ontvangers bepalen uiteindelijk zelf de verwerking. Te vroege handhaving kan ook facturen, supportreacties en doorgestuurde berichten raken. Voor de volledige mailconfiguratie begint u bij zakelijke e-mail.

Het probleem is vaak niet de ingewikkeldheid van DMARC, maar onvoldoende voorbereiding. Teams laten p=none zonder evaluatie staan of schakelen meteen p=reject in voordat alle legitieme verzenders correct zijn geconfigureerd. Daardoor kan echte mail worden geweigerd.

Een gebruikelijke aanpak is met p=none verzendbronnen onderzoeken, daarna p=quarantine invoeren zodra legitieme mail via geslaagde, uitgelijnde authenticatie wordt herkend, en uiteindelijk p=reject overwegen. Onderzoek resterende fouten: niet iedere mislukking is spoofing. Het juiste tempo hangt af van uw mailstromen en de beschikbare gegevens.

Wat is een DMARC-beleid?

Een DMARC-beleid vraagt ontvangers hoe zij berichten met uw domein in From behandelen als DMARC faalt. De opties zijn none, quarantine en reject. De keuze hangt vooral af van de authenticatie en domeinuitlijning van uw legitieme verzenders.

De ontvanger controleert SPF en DKIM en vergelijkt de daarbij gebruikte domeinen met het zichtbare From-domein. Uitlijning alleen is niet genoeg: de bijbehorende authenticatie moet ook slagen.

Als SPF slaagt én uitgelijnd is, slaagt DMARC.

Als DKIM slaagt én uitgelijnd is, slaagt DMARC.

Als geen van beide succesvol en uitgelijnd is, faalt DMARC en wordt het gepubliceerde beleid betrokken bij de ontvangstbeslissing.

Welk DMARC-beleid kiest u eerst?

Begin doorgaans met p=none, tenzij u al representatieve gegevens hebt en alle legitieme bronnen aantoonbaar geslaagde, uitgelijnde SPF of DKIM gebruiken. Monitoring helpt onbedoelde gevolgen van handhaving te beoordelen.

Een voorbeeld van een startrecord:

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

Dit beleid vraagt op zichzelf niet om blokkering van domeinmisbruik. Rapporten kunnen inzicht geven, maar niet iedere ontvanger rapporteert en de gegevens zijn niet noodzakelijk volledig.

Vaak vergeten verzendbronnen zijn:

1. Boekhoudsoftware die facturen verstuurt.
2. HR- of wervingstools die aanbiedingen versturen.
3. CRM- en marketingplatforms voor campagnes.
4. Helpdesksoftware die uw hoofddomein als afzender gebruikt.
5. Doorstuurregels die SPF op een volgende hop kunnen verstoren.

Wie monitoring overslaat, kan echte zakelijke processen treffen. De fouten zijn dan geen theoretische risico's, maar berichten van legitieme systemen.

Voor bulkverzenders is een DMARC-record onderdeel van toepasselijke verzendeisen, onder meer bij Google. Controleer de relevante authenticatie- en uitlijningsvoorwaarden voor uw verkeer. DMARC is beschreven in RFC 7489.

Hoelang blijft DMARC op none?

Een monitoringperiode met none van enkele weken kan een eerste beeld geven, maar de benodigde duur hangt af van uw verzendcycli. Een maandelijkse of incidentele stroom moet daadwerkelijk in de gegevens voorkomen voordat u handhaving beoordeelt.

Enkele dagen zijn vaak niet representatief. Ook een korte periode van weken dekt niet vanzelf maandfacturen, kwartaalupdates of een oude toepassing die zelden wachtwoordherstel verstuurt.

Neem in uw onderzoek mee:

1. Reguliere zakelijke mail.
2. Marketingverzendingen.
3. Facturatiecycli.
4. Supportescalaties.
5. Doorgestuurde mail.
6. Automatiseringen van derden.

Analyseer aggregatierapporten en onderzoek welke fouten van legitieme systemen komen en welke aanwijzingen voor misbruik bevatten. Houd ook rekening met onbekende bronnen, ontbrekende rapporten en doorstuurproblemen; classificatie is niet altijd eenduidig.

Voorbeeld: uw nieuwsbriefplatform ondertekent met zijn eigen domein. SPF kan daarvoor slagen, maar als ook SPF niet met uw From-domein is uitgelijnd en DKIM evenmin, faalt DMARC. Herstel dan eerst de uitlijning in plaats van reject in te schakelen.

Voor TrekMail-domeinen kunnen de DNS-instructies en ingebouwde controles helpen bij de configuratie. Zij vervangen geen beoordeling van alle verzendroutes. Zie een domein toevoegen en vereiste DNS-records.

Waarom kan doorsturen DMARC beïnvloeden?

Bij doorsturen verzendt een andere server, waardoor SPF voor de oorspronkelijke envelopafzender vaak faalt. Geslaagde, uitgelijnde DKIM kan DMARC dan laten slagen. Onderzoek daarom of de handtekening intact blijft voordat u strenger beleid invoert.

Hier kunnen ook ervaren beheerders een belangrijk onderscheid missen.

De zichtbare From-afzender is niet dezelfde identiteit als de envelopafzender voor retourberichten. SPF controleert de verzendende IP-adressen voor de envelopidentiteit. DMARC beoordeelt vervolgens of geslaagde SPF met From is uitgelijnd.

Doorsturen verandert het verzendende IP-adres, zodat de oorspronkelijke SPF-autorisatie mogelijk niet meer past. DKIM kan behouden blijven als de ondertekende koppen en body niet op een verificatierelevante manier veranderen.

Daarom kunnen beide uitspraken tegelijk kloppen:

1. SPF faalt na doorsturen.
2. DMARC slaagt alsnog omdat DKIM slaagt en uitgelijnd is.

Test belangrijke doorstuurstromen voordat u handhaving activeert. Controleer geslaagde, uitgelijnde DKIM bij de legitieme verzenders en de verwerking onderweg. Voor Gmail helpt domeinmail doorsturen naar Gmail; voor algemene problemen leest u e-mail doorsturen.

ARC draagt authenticatiecontext over langs tussenliggende systemen en mailinglijsten. De ontvanger beslist of hij die context vertrouwt en gebruikt; ARC vervangt uw eigen uitlijningswerk niet. Zie RFC 8617.

Wanneer schakelt u over op quarantine?

Overweeg quarantine wanneer representatieve gegevens en tests bevestigen dat legitieme bronnen geslaagde, uitgelijnde SPF of DKIM gebruiken. U vraagt ontvangers mislukte berichten als verdacht te behandelen, maar zij kunnen daarvan afwijken. Dit is geen gegarandeerd veilige tussenstap.

Het record kan er zo uitzien:

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

Een gemiste verzender kan zichtbaar worden doordat gebruikers mail in spam aantreffen. Reken daar niet als enige controle op: berichten kunnen ook anders worden verwerkt en gebruikers melden niet alles.

Gebruik bij problemen deze aanpak:

1. Een gebruiker meldt ontbrekende mail.
2. U onderzoekt verzender en uitlijning.
3. U herstelt SPF, DKIM of beide.
4. U test opnieuw voordat u reject overweegt.

Sommige teams gebruiken pct=25 of pct=50 voor een gefaseerde invoering. De ondersteuning en toepassing verschillen echter per ontvanger. Beschouw dit niet als een nauwkeurige verkeerssplitsing of veiligheidsgarantie. Ook quarantine voor 100% van het verkeer vereist een zorgvuldig beoordeelde invoering.

Bij TrekMail's beheerde SMTP controleert u de DKIM-configuratie voor uw domein en het daadwerkelijke resultaat. Doorgestuurde berichten kunnen SPF-fouten hebben terwijl DKIM geldig en uitgelijnd blijft. Zie mijn e-mails komen in spam terecht.

Wanneer schakelt u over op reject?

Overweeg reject wanneer u de relevante legitieme verzendroutes hebt gecontroleerd en resterende fouten voldoende hebt onderzocht. Hiermee vraagt u ontvangers DMARC-falende mail te weigeren. Zij kunnen het beleid wegens lokale omstandigheden alsnog overrulen.

Een voorbeeldrecord:

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

Voor veel domeinen is dit een mogelijk einddoel, na zorgvuldige voorbereiding.

De mogelijke voordelen:

1. Direct misbruik van uw domein als afzender beperken bij ontvangers die het beleid toepassen.
2. Een deel van phishing- en fraudeaanvallen met uw domein bemoeilijken.
3. Uw gewenste verwerking van authenticatiefouten duidelijk maken aan ontvangers.
4. Onderdeel vormen van domein- en merkbescherming, zonder volledige bescherming te bieden.

Google beschrijft afwijzingen en snelheidsbeperkingen voor niet-geauthenticeerde of niet-uitgelijnde mail. Voorbeelden van meldingen zijn 4.7.31 voor DMARC-gerelateerde problemen en 4.7.32 voor uitlijning. Ook 5.7.26 kan in Gmail-retourberichten voorkomen. Onderzoek de volledige melding en raadpleeg Google's veelgestelde vragen over verzendrichtlijnen.

Let op: een legitieme factuurstroom uit oude software kan onder reject worden geweigerd als geen geslaagde, uitgelijnde authenticatie beschikbaar is. Zorg voor tests, monitoring en een herstelplan.

Welk DMARC-record publiceert u in DNS?

Publiceer uw beleid als TXT-record op _dmarc.yourdomain.com. Zorg voor één DMARC-beleidsrecord per domein; meerdere beleidsrecords kunnen de ontdekking ongeldig maken.

De volgende records zijn alternatieven. Publiceer niet alle varianten tegelijk:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

De DNS-configuratie voor een TrekMail-domein kan MX, SPF, DKIM en DMARC omvatten. Het onderstaande patroon is illustratief, niet voor iedere verzendroute geschikt. De quarantine-waarde is geen advies om monitoring over te slaan:

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

Publiceer geen dubbele SPF-records, gebruik de werkelijke DKIM-waarden en beoordeel bestaande MX-records bij een wijziging. Bij een eigen uitgaande provider volgt u diens SPF- en DKIM-instructies; de TrekMail-SPF-include is daarvoor niet universeel toepasbaar. Zie eigen SMTP (BYO).

Veelgemaakte fouten met DMARC-beleid

Veelgemaakte fouten zijn p=none zonder verdere evaluatie laten staan, te vroeg handhaven, alleen op SPF vertrouwen en subdomeinen vergeten. Ze kunnen de bescherming beperken of legitieme mail raken.

Let vooral op:

1. none blijven gebruiken zonder de rapporten te onderzoeken of handhaving te beoordelen. Het beleid vraagt geen blokkering.
2. DKIM-uitlijning overslaan omdat SPF lijkt te slagen. Doorsturen kan die afhankelijkheid zichtbaar maken.
3. Subdomeinen vergeten. Met sp= kunt u het geërfde subdomeinbeleid aanpassen.
4. SPF-limieten negeren. Meer dan 10 tijdens evaluatie gebruikte DNS-opzoekende termen kan PermError veroorzaken; dit is niet simpelweg het aantal losse DNS-pakketten.
5. Een verzendplatform vertrouwen zonder de domeinondertekening te controleren.

Een voorbeeld voor subdomeinen:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

Dit vraagt reject voor het hoofddomein en none voor subdomeinen die dit beleid erven. Het geldt niet alleen voor één gekozen testsubdomein; een expliciet beleidsrecord op een subdomein kan voorgaan.

Hoe TrekMail bij de voorbereiding kan helpen

TrekMail kan domeinbeheer, DNS-controles en verzendconfiguratie samenbrengen. Een dashboard voor meerdere domeinen en gedeelde opslag kan versnipperd beheer beperken. Daarmee zijn echter niet automatisch alle externe verzenders geïnventariseerd of alle DMARC-risico's opgelost.

De hier genoemde betaalde TrekMail-abonnementen beginnen bij $3.50/maand voor Starter en omvatten beheerde SMTP. Nano wordt als gratis optie met eigen SMTP beschreven. Controleer actuele tarieven, limieten en beschikbaarheid. TrekMail biedt IMAP-postvakken en, afhankelijk van het abonnement, eigen domeinen, catch-all, doorsturen, migratie en API-toegang.

Voor DMARC is niet het TXT-record alleen lastig, maar vooral het beheren van de systemen die namens uw domein mogen verzenden.

Afhankelijk van uw configuratie kunt u met TrekMail:

1. Meerdere domeinen vanuit één dashboard beheren.
2. Vereiste DNS-records vóór ingebruikname controleren.
3. Beheerde SMTP gebruiken op passende betaalde abonnementen of eigen SES/SendGrid op Nano instellen.
4. Postvakhosting scheiden van de keuze voor een uitgaande provider.
5. Oude mail met IMAP-migratie ophalen, binnen de mogelijkheden en toegangsrechten van de bron.

Voor de volledige configuratie leest u e-mail op uw domein instellen. Voor meerdere merken of klantdomeinen helpt e-mailhosting voor meerdere domeinen.

Conclusie: een gefaseerde, gecontroleerde aanpak

Een gebruikelijke route is beginnen met none, authenticatie en uitlijning herstellen, quarantine beoordelen en daarna reject overwegen. DMARC vraagt onderhoud en onderbouwde beslissingen, geen eenmalige afvinkstap.

Kort samengevat:

1. Gebruik p=none bijvoorbeeld 2 tot 4 weken als eerste onderzoeksperiode, maar verleng die waar verzendcycli dat vereisen.
2. Laat iedere legitieme bron geslaagde, uitgelijnde SPF of bij voorkeur ook DKIM gebruiken.
3. Voer p=quarantine in na beoordeling van legitieme stromen en risico's.
4. Overweeg p=reject zodra resterende fouten zijn onderzocht en onbedoelde gevolgen voldoende zijn beperkt.

Deze aanpak kan direct domeinmisbruik helpen beperken en risico's voor echte mail beheersbaarder maken, zonder aflevering of volledige bescherming te garanderen. Bekijk TrekMail's documentatie en de actuele mogelijkheden en prijsopzet op https://trekmail.net/pricing.