"Voldoet niet aan DMARC-verificatie en heeft een DMARC-beleid van weigeren": wat dit betekent en hoe u dit kunt oplossen
door
Laatst bijgewerkt: 7 leestijd: 7 minuten
Belangrijkste Conclusies
- DMARC-afwijzingsfouten treden op wanneer SPF of DKIM de domeinaanpassing met het "Van"-adres niet kan uitvoeren.
- Een p=reject-beleid geeft ontvangende servers de instructie om ongeautoriseerde e-mails volledig te blokkeren.
- Alleen SPF doorstaan is niet voldoende; SPF of DKIM moet overeenkomen met uw zichtbare afzenderdomein.
- E-mailforwarding breekt vaak SPF, waardoor DKIM-afstemming cruciaal is voor een stabiele levering.
- Het verwijderen van p=reject verzwakt de domeinbeveiliging en verhoogt het risico op spoofing.
Bekijk wekelijks DMARC RUA-rapporten om verkeerd geconfigureerde services en ongeautoriseerde afzenders te identificeren.
Een foutmelding 'Voldoet niet aan DMARC-verificatie en heeft een DMARC-beleid van weigeren' betekent dat uw e-mail niet door de DMARC-authenticatie is gekomen en dat de ontvangende server de bezorging heeft geblokkeerd. Dit probleem doet zich voor wanneer SPF of DKIM niet overeenkomt met uw 'Van'-domein en uw DMARC-beleid is ingesteld op p=reject. Los DMARC-weigeringfouten op door SPF-records te corrigeren, DKIM-ondertekening in te schakelen en te zorgen voor strikte domeinuitlijning om de e-mailbezorgbaarheid te herstellen en spoofing te voorkomen.
Wat deze DMARC-fout eigenlijk betekent
Wanneer een ontvangende server uw e-mail verwerkt, voert deze verschillende controles uit om te verifiëren of de afzender geautoriseerd is. Als deze controles mislukken, kijkt de server naar het DMARC-record van uw domein voor instructies over wat er vervolgens moet gebeuren.
Uitleg over 'Voldoet niet aan DMARC-verificatie'
Er is sprake van een DMARC-fout wanneer een e-mail niet voldoet aan de DMARC-richtlijnen. Het is onjuist om te denken dat het voldoende is om te voldoen aan SPF of DKIM. DMARC vereist dat het domein in de 'Van'-header, dat is wat de gebruiker ziet, overeenkomt met het domein dat is gevalideerd door SPF en/of DKIM. Als de technische handtekeningen niet overeenkomen met het zichtbare afzenderadres, faalt DMARC.
Wat "DMARC-beleid van afwijzing" inhoudt
De p=reject-tag is het strengste DMARC-beleid. Het vertelt de ontvangende server: "Als deze e-mail de verificatie niet doorstaat, bezorg hem dan niet. Verwijder hem volledig."
Hoe DMARC-verificatie werkt (kort overzicht)
Om DMARC te doorstaan, moet een e-mail voldoen aan:
- De technische pas: SPF of DKIM moet geldig zijn.
- De afstemming: Het domein dat wordt gebruikt in SPF of DKIM moet overeenkomen met het domein in het 'Van'-adres.
Afstemming is belangrijker dan een simpele goedkeuring. Als u bijvoorbeeld een e-mail verstuurt vanaf een subdomein, maar uw SPF-record alleen het domein van uw webhost autoriseert, kan de SPF-controle voor de host 'goedgekeurd' worden, maar DMARC zal 'afgekeurd' worden omdat de domeinen niet op elkaar zijn afgestemd.
Waarom e-mails DMARC niet doorstaan en worden geweigerd
1. Authenticatiefouten
- SPF-fout of ongeautoriseerd verzendend IP-adres: Beschouw SPF als een VIP-gastenlijst voor uw domein. Als u een nieuwe tool gaat gebruiken, zoals een CRM- of e-mailmarketingplatform, maar vergeet deze toe te voegen aan die lijst (uw SPF-record), ziet de ontvangende server een niet-vermeld IP-adres dat probeert binnen te komen en slaat hij de deur dicht.
- DKIM ontbreekt of is defect: DKIM is in feite een digitaal lakzegel. Als uw server de e-mail niet 'ondertekent' of als de 'sleutel' die u in uw DNS-instellingen hebt opgegeven oud of defect is, kan de ontvanger niet verifiëren of de e-mail daadwerkelijk van u afkomstig is. Geen zegel, geen toegang.
2. Uitlijningsproblemen
- DKIM-domeinmisalignment: Dit is een beetje zoals het tonen van een identiteitsbewijs waarop de naam niet overeenkomt met de persoon die voor je staat. Als je e-mail zegt dat deze afkomstig is van joudomein.com, maar de DKIM-handtekening is ondertekend door willekeurige-service.com, wordt DMARC achterdochtig. Alles moet naar dezelfde thuisbasis verwijzen.
- SPF-afstemming verbroken door doorsturen: Dit is het klassieke 'tussenpersoon'-probleem. Wanneer een e-mail wordt doorgestuurd, wordt het 'Return-Path' vaak vervangen door de gegevens van de doorstuurder, waardoor SPF volledig wordt verbroken. Dit komt heel vaak voor en daarom is DKIM zo belangrijk: DKIM blijft aan de e-mail gekoppeld, zelfs wanneer deze wordt doorgestuurd, terwijl SPF meestal niet meer werkt.
Waarom het beleid p=reject deze fout kritiek maakt
DMARC-beleidsregels werken volgens een handhavingsladder:
- p=none: Bewakingsmodus. Er wordt geen e-mail geblokkeerd.
- p=quarantaine: Verdachte e-mails worden naar de map Ongewenste e-mail verplaatst.
- p=reject: Nultolerantie. Ongeautoriseerde e-mail wordt verwijderd.
Wanneer u zich in de fase p=afwijzen bevindt, is er geen ruimte voor fouten. Als uw externe afzenders niet perfect zijn geconfigureerd, worden uw legitieme zakelijke communicatieberichten op dezelfde manier behandeld als een phishingaanval en geblokkeerd.
De verborgen factor: subdomeinbeleid (sp=)
Een detail dat beheerders vaak overvalt, is hoe DMARC omgaat met subdomeinen (bijvoorbeeld marketing.uwdomein.com). Als u uw hoofddomein standaard instelt op p=reject, erft elk subdomein automatisch dat 'Block'-commando.
Als u een oudere tool hebt die vanaf een subdomein verzendt dat nog niet volledig is ingesteld, wordt deze onmiddellijk gedempt. Om dit te beheren, kunt u de sp-tag in uw DMARC-record gebruiken:
- sp=none: Houdt uw subdomeinen in de "bewakingsmodus", zelfs als uw hoofddomein op p=reject staat.
- sp=reject: Geeft servers expliciet de opdracht om ongeautoriseerde e-mail van elk subdomein te blokkeren.
Pro-tip: als u niet 100% zeker bent van elke dienst die uw subdomeinen gebruikt, begin dan met p=reject; sp=none; om uw hoofdmerk te beschermen terwijl u uw submerken controleert.
Veelvoorkomende situaties waarin deze foutmelding verschijnt
Gmail en Google Workspace
Google heeft onlangs zijn vereisten voor bulkverzenders aangescherpt. Mogelijk krijgt u een bouncebericht te zien met de volgende tekst: "Bericht geweigerd omdat het niet voldoet aan het DMARC-beleid van Google."
Microsoft 365 en Outlook
Microsoft maakt vaak gebruik van 'Advanced Threat Protection'. Als DMARC faalt en het beleid wordt afgewezen, genereren Outlook-servers vaak een 5.7.1 NDR, wat staat voor Non-Delivery Report (rapport over niet-bezorging).
Tools van derden
Veel bedrijven vergeten hun CRM- of HR-platforms te autoriseren. Omdat deze tools e-mails 'namens' uw domein versturen, zijn ze de meest voorkomende oorzaak van DMARC-afwijzingen.
Hoe 'Voldoet niet aan DMARC-verificatie' te verhelpen
Volg deze stappen om de fout op te lossen:
- Identificeer de bron: Allereerst: controleer de opmerking 'retour afzender'. Bekijk het teruggestuurde bericht om het specifieke IP-adres of de specifieke dienst te vinden die de e-mail heeft geprobeerd te verzenden. Dit is meestal het doorslaggevende bewijs dat u precies vertelt wie er bij de poort is geblokkeerd.
- Controleer SPF-autorisatie: Beschouw uw SPF-record als de lijst met 'goedgekeurde afzenders' van uw domein. U moet ervoor zorgen dat de dienst die u gebruikt daadwerkelijk op deze lijst staat. Als dat niet het geval is, moet u hun 'include'-verklaring toevoegen aan uw DNS-record, zodat de ontvangende server weet dat zij toestemming hebben om namens u te spreken.
- DKIM-ondertekening repareren: u wilt er zeker van zijn dat de dienst uw e-mails daadwerkelijk 'ondertekent' met een DKIM-sleutel die naar uw domein verwijst. Als de digitale handtekening ontbreekt of tot een heel ander domein behoort, zal de ontvanger deze als een valse identiteit behandelen.
- Zorg voor domeinaanpassing: alles moet overeenkomen. Controleer of het domein in uw 'Van'-adres hetzelfde is als het domein dat wordt gebruikt voor uw SPF en DKIM. Als uw e-mail zegt dat deze afkomstig is van company.com, maar uw SPF staat garant voor random-app.net, klopt de berekening voor DMARC niet.
- DMARC-rapporten bekijken: Gebruik een DMARC-monitoringtool om 'RUA'-rapporten te bekijken. Deze laten precies zien welke services niet werken en waarom.
- Test voordat u opnieuw verzendt: gebruik een online header-analysator om een testmail te verzenden en de status 'DMARC Pass' te controleren.
Tijdelijke oplossingen versus definitieve oplossingen
Waarom het verwijderen van p=reject riskant is
Je zou in de verleiding kunnen komen om je beleid weer te wijzigen naar p=none om de bezorging te 'repareren'. Hoewel dit de bounces stopt, maakt het je domein kwetsbaar voor spoofing door hackers. Het geeft een vals gevoel van veiligheid, terwijl de reputatie van je merk kwetsbaar blijft.
Veiligere manieren om te herstellen
In plaats van de beveiliging te verlagen, kunt u monitoringtools gebruiken om falend legitiem verkeer te identificeren. U kunt ook een 'percentage'-tag gebruiken (bijv. p=reject; pct=50) om het beleid geleidelijk af te dwingen terwijl u controleert of al uw verzendbronnen correct zijn afgestemd.
Hoe PowerDMARC helpt bij het voorkomen van DMARC-afwijzingsfouten
Hoewel een strikt 'Reject'-beleid een bot instrument is, biedt PowerDMARC de precisietools die nodig zijn om ervoor te zorgen dat alleen de slechte actoren worden getroffen.
1. Totale zichtbaarheid en AI-dreigingsinformatie: Het handmatig lezen van XML-rapporten is als het proberen te lezen van Matrix-code. De DMARC Report Analyzer van PowerDMARC zet deze complexe bestanden om in een voor mensen leesbaar dashboard.
2. AI-gestuurde dreigingsmapping: onze AI-aangedreven dreigingsinformatie identificeert de geografische locatie en reputatie van ongeautoriseerde IP's, waardoor u onderscheid kunt maken tussen een verkeerd geconfigureerde interne tool en een kwaadaardige poging tot spoofing.
3. Vereenvoudigd recordbeheer (gehoste diensten): De meest voorkomende oorzaak van DMARC-fouten is 'misalignment', waarbij uw SPF- of DKIM-records niet overeenkomen met uw domein. PowerDMARC biedt gehoste diensten (waaronder gehoste DMARC) waarmee u deze records rechtstreeks vanuit ons dashboard kunt bijwerken zonder dat u hoeft in te loggen bij uw DNS-provider.
Best practices om DMARC-beleidafwijzingsfouten te voorkomen
Het handhaven van een 'Reject'-beleid vereist voortdurende hygiëne. Om ervoor te zorgen dat uw legitieme e-mails niet in uw eigen beveiligingsnet terechtkomen, volgt u deze best practices uit de branche:
Authenticatie en afstemming Hygiëne
- Controleer altijd nieuwe afzenders: voordat uw marketing- of HR-afdeling zich aanmeldt voor een nieuwe e-mailtool, moet u controleren of deze Custom DKIM of SPF Alignment ondersteunt. Laat nooit een derde partij 'namens' uw domein e-mails versturen zonder de juiste DNS-configuratie.
- Geef de voorkeur aan DKIM voor veerkracht: SPF kan gemakkelijk worden omzeild door e-mails door te sturen. DKIM is veel robuuster omdat de digitale handtekening aan de e-mailheader blijft hangen, zelfs als deze door verschillende servers wordt verzonden.
Voortdurende monitoring en veranderingsmanagement
- Regelmatige DMARC-rapportbeoordelingen: DMARC genereert XML-rapporten waarin gedetailleerd wordt weergegeven wie er e-mail verstuurt via uw domein. Door deze rapporten minstens één keer per week te bekijken, kunt u ongeoorloofde pogingen tot spoofing of legitieme diensten die plotseling niet meer overeenkomen, opsporen.
- E-mailinfrastructuurwijzigingen bijhouden: behandel uw e-mail DNS-records als code. Houd een logboek bij van elke wijziging die u aanbrengt in uw SPF-, DKIM- en DMARC-records. Als er na een servermigratie of een leverancierswijziging bezorgingsproblemen optreden, kunt u snel de specifieke configuratie identificeren en terugdraaien die de foutmelding 'Policy Reject' heeft veroorzaakt.
Het komt erop neer: laat 'afwijzing' je bereik niet verpesten.
De foutmelding 'DMARC Policy of Reject' is een beetje te vergelijken met een bewaker die je per ongeluk buitensluit uit je kantoor. Dat is natuurlijk vervelend, maar het bewijst wel dat het slot echt werkt.
De oplossing is niet om het slot weg te gooien en terug te gaan naar p=none, maar om ervoor te zorgen dat u de juiste sleutels bij u heeft. Door ervoor te zorgen dat uw SPF en DKIM goed zijn afgestemd op uw domein, voorkomt u bounces en kunt u met een gerust hart e-mails versturen. Houd uw rapporten in de gaten, verifieer uw nieuwe tools voordat u live gaat, en u hoeft zich nooit meer zorgen te maken dat uw legitieme e-mails in de digitale prullenbak terechtkomen.
Start vandaag nog uw gratis proefperiode van 15 dagen met onze experts om te zien hoe wij uw domeinbeveiliging kunnen vereenvoudigen.
Veelgestelde Vragen
Waarom voldoet mijn e-mail niet aan DMARC, maar wel aan SPF?
Dit is meestal een kwestie van afstemming. Uw SPF is 'goedgekeurd' voor het domein van de mailserver, maar dat domein komt niet overeen met het domein van uw 'Van'-adres.
Moet ik p=reject verwijderen om de levering te herstellen?
Nee. Dit is een noodoplossing die de veiligheid in gevaar brengt. Identificeer in plaats daarvan de dienst die niet werkt en geef deze correct toestemming in uw SPF/DKIM-instellingen.
Hoe lang duurt het voordat DMARC-oplossingen werken?
DNS-wijzigingen kunnen 24 tot 48 uur duren voordat ze wereldwijd zijn doorgevoerd, hoewel de meeste moderne systemen wijzigingen binnen een uur doorvoeren.
Heeft DMARC invloed op interne of doorgestuurde e-mails?
Ja. Doorsturen breekt vaak SPF, daarom is het zo belangrijk om een geldige DKIM-handtekening te hebben om ervoor te zorgen dat doorgestuurde e-mails nog steeds de DMARC-verificatie doorstaan.
Expert domein- en e-mailbeveiliging bij PowerDMARC
Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.
Laatste berichten van Yunes Tarada (Bekijk alle berichten)
