Belangrijkste Conclusies
- Met e-mailverificatiemethoden wordt gecontroleerd of een bericht daadwerkelijk afkomstig is van uw domein en niet is vervalst.
- SPF, DKIM en DMARC vormen de drie belangrijkste. Elk controleert iets anders, en ze werken het beste in combinatie met elkaar.
- Samen voorkomen ze spoofing, zorgen ze ervoor dat je e-mail niet in de spam terechtkomt en beschermen ze je merk in Gmail, Outlook en Yahoo.
- ARC, MTA-STS, TLS-RPT en BIMI breiden die bescherming uit naar doorgestuurde e-mail, versleuteld transport en merklogo’s.
- Zonder deze maatregelen kan iedereen je domein misbruiken en heb je geen inzicht in hoe het wordt gebruikt.
- Met DMARC-rapportage kunt u ongeautoriseerde afzenders en fouten veel sneller opsporen dan wanneer u DNS of headers handmatig controleert.
E-mailverificatiemethoden zijn de protocollen – met name SPF, DKIM en DMARC – waarmee ontvangende servers kunnen controleren of een bericht daadwerkelijk afkomstig is van uw domein. Zonder deze methoden kan iedereen uw afzenderadres vervalsen, waardoor de kans groter wordt dat uw legitieme e-mails in de spamfolder terechtkomen.
Als deze methoden correct worden geconfigureerd, beschermen ze uw merk tegen identiteitsfraude, zorgen ze ervoor dat legitieme e-mails in de inbox terechtkomen en laten ze u precies zien hoe uw domein wordt gebruikt. Nu Google, Yahoo, Microsoft en Apple authenticatie voor bulkverzenders verplicht stellen, is het instellen hiervan niet langer optioneel. In deze handleiding worden de belangrijkste methoden voor e-mailauthenticatie besproken, hoe ze werken, waarom ze van invloed zijn op de afleverbaarheid en hoe u ze kunt implementeren.
Voor teams die meerdere domeinen beheren of verzendservices gebruiken, is het moeilijkste deel niet het eenmalig publiceren van records. Het gaat erom het overzicht te behouden, aangezien elk nieuw CRM-systeem, marketingplatform, helpdesk of regionaal domein de SPF-, DKIM- en DMARC- onderliggende structuur verandert.
Wat is e-mailverificatie?
E-mailverificatie is een reeks methoden waarmee wordt gecontroleerd of een bericht daadwerkelijk afkomstig is van het domein dat het opgeeft en of het tijdens de verzending niet is vervalst. Deze methoden, voornamelijk SPF, DKIM en DMARC, worden als TXT-records in het DNS gepubliceerd. Wanneer een ontvangende server een binnenkomend bericht controleert, raadpleegt deze de DNS-records om het domeineigendom te verifiëren en te beslissen of het bericht moet worden afgeleverd, naar de spamfolder moet worden doorgestuurd of moet worden geweigerd.
Goed om te weten
Authenticatie wordt vaak verward met drie verwante begrippen. Bij authenticatie wordt gecontroleerd wie het bericht heeft verzonden. Autorisatie bepaalt wat een afzender mag doen. Versleuteling beschermt de inhoud tijdens het verzenden. De reputatie van de afzender geeft de verzendgeschiedenis en het aantal klachten van een domein weer. Alle vier zijn van invloed op de afleverbaarheid, hoewel authenticatie de basis vormt waarop de andere drie voortbouwen.
Belangrijkste methoden voor e-mailverificatie: SPF, DKIM en DMARC
Dit zijn de methoden die ervoor zorgen dat e-mailverificatie werkt; elke methode is verantwoordelijk voor een ander onderdeel van de verificatie.
Beschouw SPF, DKIM en DMARC als drie lagen van identiteitscontrole. SPF controleert of de verzendende server bevoegd is om namens uw domein te verzenden. DKIM controleert of het bericht tijdens het verzenden niet is gewijzigd. DMARC controleert of deze resultaten overeenkomen met het zichtbare ‘Van’-adres en geeft providers aan wat ze moeten doen als dat niet het geval is.
| Protocol | Wat er wordt gecontroleerd | Waarom het belangrijk is | Belangrijkste beperking |
|---|---|---|---|
| SPF | Of het verzendende IP-adres geautoriseerd is | Beperkt spoofing en misbruik door afzenders | Limiet van 10 DNS-opzoekingen; wordt onderbroken bij doorsturen |
| DKIM | Of het bericht tijdens de verzending is gewijzigd | Waarborgt de integriteit van berichten | Controleert het zichtbare ‘Van’-adres niet |
| DMARC | Of SPF of DKIM overeenkomen met het ‘From’-domein | Maakt het handhaven van beleid en rapportage mogelijk | SPF of DKIM is vereist om te werken |
| BIMI | Weergave van het merklogo bij geverifieerde e-mail | Verhoogt het vertrouwen in het merk en de herkenbaarheid in de inbox | DMARC moet zijn ingesteld op p=quarantine of p=reject |
| MTA-STS | Verplichte TLS-beveiliging voor het dataverkeer | Voorkomt downgrade- en onderscheppingsaanvallen | Hiervoor moet een HTTPS-beleidsbestand worden gehost |
| TLS-RPT | Rapportage van mislukte TLS-leveringen | Biedt inzicht in problemen op de transportlaag | Ruwe JSON-rapporten zijn moeilijk handmatig te ontleden |
| ARC | Verificatieketen voor doorgestuurde e-mail | Behoudt authenticatie bij doorsturen | Werkt alleen als de ontvangende server ARC ondersteunt |
SPF (Sender Policy Framework)

Sender Policy Framework vormt de eerste verdedigingslaag. SPF voorkomt spoofing door de geautoriseerde IP-adressen aan te geven die e-mail mogen verzenden vanuit een domein. Het controleert uitsluitend de afzender in het MAIL FROM-domein en houdt geen rekening met het ‘Van’-adres dat de ontvanger ziet, omdat SPF zich richt op de bericht-envelop, het Return-Path, in plaats van op de zichtbare header. Een IP-adres dat overeenkomt, wordt geaccepteerd; alle andere worden afgewezen.
DKIM (DomainKeys Identified Mail)
Terwijl SPF de afzender-server verifieert, controleert DKIM of de inhoud tijdens het verzenden niet is gemanipuleerd. Hierbij wordt een digitale handtekening toegevoegd met behulp van cryptografische sleutels: de server van de afzender ondertekent elk bericht met een privésleutel, waardoor een DKIM-handtekening die aan de headers wordt toegevoegd, en de ontvangende server haalt de bijbehorende openbare sleutel op uit het DNS om deze te verifiëren. Als de handtekening overeenkomt en de inhoud ongewijzigd is, slaagt DKIM, waarmee wordt bevestigd dat het bericht daadwerkelijk afkomstig is van het opgegeven domein en onderweg niet is gewijzigd.
DMARC (domeingebaseerde berichtenauthenticatie, -rapportage en -conformiteit)
DMARC is het protocol dat alles samenbrengt. Het controleert of een inkomende e-mail voldoet aan SPF of DKIM en of het domein dat bij die controles wordt gebruikt, overeenkomt met het ‘Van’-adres. Juist dankzij die vereiste van overeenstemming is DMARC effectief in het opsporen van vervalste berichten die langs SPF of DKIM alleen glippen, en het bepaalt welke actie het ontvangende systeem moet ondernemen bij fouten.
De DMARC-beleidsopties worden in een weloverwogen volgorde uitgevoerd:
- p=none: alleen monitoren. Berichten worden niet beïnvloed, terwijl u geaggregeerde rapporten ontvangt over authenticatieresultaten voor alle afzenders. Dit is het aanbevolen startpunt.
- p=quarantaine: mislukte berichten komen in de spam- of junkmap terecht. Gebruik deze optie pas als u er zeker van bent dat alle legitieme afzenders worden doorgelaten.
- p=afwijzen: mislukte berichten worden op de ontvangende server geblokkeerd. Dit is het strengste niveau en beschermt uw domein volledig tegen spoofing.
DMARC genereert ook twee soorten rapporten: RUA-geaggregeerde rapporten, waarin de resultaten van alle afzenders worden samengevat, en RUF-forensische rapporten, die gedetailleerde informatie op berichtniveau geven over fouten. Beide rapporten worden in XML-formaat verzonden naar de adressen in uw DMARC-record.
Aanvullende methoden: ARC, MTA-STS, TLS-RPT en BIMI
Het kerntrio voorziet in de meeste behoeften. Vier aanvullende protocollen breiden de bescherming uit voor specifieke scenario’s: doorsturen, versleuteld transport, transportzichtbaarheid en merkweergave.
ARC (Authenticated Received Chain)
Als je e-mails doorstuurt via mailinglijsten, ticketsystemen of andere tussenpersonen, kunnen doorgestuurde berichten soms niet voldoen aan de SPF- of DKIM-verificatie. ARC lost dit op door de oorspronkelijke authenticatieresultaten bij elke tussenstap te behouden. Wanneer een bericht via een vertrouwde tussenpersoon wordt doorgestuurd, registreert ARC de resultaten bij elke stap en creëert het een cryptografisch ondertekende keten, die de eindserver verifieert om te bevestigen dat de e-mail oorspronkelijk geauthenticeerd was, zelfs nadat het doorsturen de oorspronkelijke handtekening had verbroken. Dit is een veelvoorkomende oorzaak van DMARC-fouten.
MTA-STS (Mail Transfer Agent Strict Transport Security)
MTA-STS vereist versleutelde SMTP-verbindingen tussen mailservers, waardoor wordt voorkomen dat aanvallers het verkeer kunnen onderscheppen of omzetten naar leesbare tekst bij man-in-the-middle-aanvallen. Wanneer dit is geconfigureerd, geeft het aan verzendende servers door dat ze TLS -versleuteling moeten gebruiken om e-mail naar uw domein te verzenden, en de bezorging moeten weigeren als er geen beveiligde verbinding tot stand kan worden gebracht.
Gehoste MTA-STS- en TLS-RPT-diensten vereenvoudigen de implementatie doordat het niet langer nodig is om beleidsbestanden handmatig te hosten en transportrapporten te analyseren. Dit biedt voordelen voor organisaties in de financiële sector, de gezondheidszorg en de publieke sector die versleutelde gegevensoverdracht vereisen als nalevingsmaatregel.
TLS-RPT (SMTP TLS-rapportage)
TLS-RPT biedt domeineigenaren inzicht in bezorgingsproblemen die verband houden met TLS-versleuteling, en laat zien wanneer berichten niet veilig konden worden bezorgd. In combinatie met MTA-STS helpt het teams om downgrade-aanvallen, verkeerde beleidsinstellingen en certificaatfouten sneller op te sporen. Zonder deze functie vinden versleutelingsfouten onopgemerkt plaats, zonder dat er een signaal is dat er geen veilige verbinding tot stand kon worden gebracht.
BIMI (merkindicatoren voor berichtidentificatie)
BIMI toont een geverifieerd merklogo in de inbox van de ontvanger naast geauthenticeerde berichten, wat een visueel bewijs van legitimiteit biedt. Om dit te laten werken, heeft uw domein een DMARC-beleid met ten minste p=quarantine. Het logo zorgt voor merkherkenning, waardoor ontvangers echte e-mails direct kunnen herkennen, wat de open rates kan verhogen. BIMI is ook een doelwit voor logo-spoofing wanneer domeinen niet goed beveiligd zijn.
Voor de weergave van het blauwe vinkje in Gmail is een Verified Mark Certificate (VMC) vereist, en met gehoste BIMI in combinatie met VMC-ondersteuning hoef je minder handmatig in te stellen. Als je klaar bent om dit in te stellen, kun je deze handleiding over het publiceren van een BIMI-record bevat de stappen die u moet volgen.
Hoe e-mailverificatie werkt
Authenticatie verloopt als een reeks automatische controles tussen de verzendende en de ontvangende server. Het end-to-end-proces ziet er als volgt uit.
- De afzender verstuurt een bericht. Uw mailserver verstuurt een e-mail namens uw domein.
- De ontvangende server voert een DNS-zoekopdracht uit. Hij zoekt de DNS-records van het verzendende domein op om de SPF-, DKIM- en DMARC-configuratie te vinden.
- SPF-controle. De server controleert of het verzendende IP-adres als geautoriseerd is opgenomen in het SPF-record van het domein. Als er een overeenkomst is, is de controle geslaagd.
- DKIM-controle. De server haalt de openbare DKIM-sleutel op uit DNS en controleert de cryptografische handtekening in de berichtkoppen. Een geldige handtekening op ongewijzigde inhoud wordt geaccepteerd.
- DMARC-afstemming en beleidscontrole. DMARC controleert of het domein dat de SPF- of DKIM-controle heeft doorstaan, overeenkomt met het zichtbare ‘Van’-domein. Als dat niet het geval is, past het het beleid van het domein toe: geen actie, in quarantaine plaatsen of afwijzen.
- Definitieve afleveringsbeslissing. De provider bezorgt het bericht, plaatst het in quarantaine of weigert het, en stuurt DMARC-geaggregeerde rapporten terug naar de domeineigenaar.
Waarom is e-mailverificatie belangrijk?
Het overslaan van authenticatie leidt tot reële bedrijfsrisico’s op vijf gebieden die elkaar vaak versterken. Zwakke authenticatie leidt zelden tot slechts één op zichzelf staand probleem.
Beschermt de reputatie van uw merk
Authenticatie voorkomt dat oplichters je domein gebruiken om frauduleuze berichten te versturen. Wanneer aanvallers uw domein vervalsen, associëren ontvangers de de phishingpoging met uw merk, ook al had u er niets mee te maken. Het voorkomen daarvan is essentieel om het vertrouwen van klanten te behouden.
Voorkomt phishing en spoofing
SPF, DKIM en DMARC werken samen om de identiteit van een afzender te verifiëren voordat het bericht de ontvanger bereikt, waardoor het veel moeilijker wordt om zich voor te doen als een vertrouwd merk. Zonder deze controles kunnen aanvallers naar believen afzenderadressen vervalsen en campagnes opzetten waarbij zakelijke e-mailaccounts worden gekaapt. Het verschil tussen phishing en spoofing is hier van belang, aangezien authenticatie de spoofing aanpakt die phishing overtuigend maakt.
Verbetert de bezorgbaarheid van e-mail
Geverifieerde e-mails worden minder snel als spam gemarkeerd door providers zoals Gmail of Outlook, waardoor legitieme berichten de inbox bereiken. Veel providers eisen tegenwoordig DKIM en DMARC voor een succesvolle bezorging, en het voldoen aan die normen verhoogt de kans dat berichten in de inbox terechtkomen.
Voldoet aan de nalevingsvereisten
Google, Yahoo, Microsoft en Apple stellen allemaal SPF, DKIM en DMARC verplicht voor domeinen die meer dan 5.000 e-mails per dag versturen, waarbij Google dit vanaf november 2025 strikt zal handhaven door e-mails die niet aan de vereisten voldoen te weigeren.
Voor gereguleerde sectoren zoals de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de publieke sector draagt authenticatie ook bij aan bredere compliance- en risicobeheerprogramma’s. In de vereisten van Google, Microsoft, PCI DSS, op de AVG afgestemde programma’s en regionale overheidsvoorschriften worden SPF, DKIM en DMARC steeds vaker beschouwd als essentiële controlemaatregelen in plaats van als best practices.
Geeft u zichtbaarheid en controle
Met name DMARC rapporteert hoe uw domein wordt gebruikt voor het verzenden van e-mail. Deze rapporten brengen ongeautoriseerde afzenders, authenticatiefouten en pogingen tot spoofing aan het licht – gegevens waarop u actie kunt ondernemen. Zonder authenticatie hebt u geen inzicht in de prestaties of beveiliging van e-mail binnen uw verzendinfrastructuur.
Dient als strategisch voordeel
Aanbieders van e-maildiensten belonen steeds vaker afzenders die zich op de juiste manier hebben geauthenticeerd. Organisaties die dit goed aanpakken, bouwen meer vertrouwen op bij hun ontvangers, hebben minder problemen met de bezorging en beschermen hun verzendinfrastructuur tegen misbruik, waardoor ze een voorsprong hebben op concurrenten die dit niet doen.
Hoe e-mailverificatie te implementeren
De implementatie komt neer op het configureren van de DNS-records die ontvangende servers gebruiken om elk bericht dat uw domein verstuurt te valideren. Doorloop de vijf stappen in de juiste volgorde, vanaf uw eerste TXT-record tot de volledige implementatie.
- Controleer uw verzendinfrastructuur. Breng alle bronnen in kaart die namens uw domein e-mails versturen: primaire mailservers, marketingautomatisering, CRM, helpdesk, facturering en eventuele transactieproviders. De meeste authenticatiefouten zijn terug te voeren op een over het hoofd geziene afzender, dus deze stap bepaalt hoe schoon de implementatie is.
- Publiceer je SPF-record. Maak één TXT-record aan waarin alle geautoriseerde IP-adressen en verzendservices worden vermeld. Elke vermelding telt mee voor de limiet van 10 lookups; als deze limiet wordt overschreden, mislukt de SPF-controle voor alle berichten.
- Configureer DKIM -ondertekening. Genereer een sleutelpaar via uw provider of mailserver. De privésleutel blijft op de verzendende server staan en ondertekent uitgaande e-mail; de openbare sleutel wordt als TXT-record in DNS opgenomen, zodat ontvangers elke handtekening kunnen verifiëren.
- Voeg je DMARC-record toe. Publiceer een DMARC TXT-record, te beginnen met een beleid dat uitsluitend op monitoring is gericht (p=none), zodat u de resultaten kunt observeren voordat u het beleid afdwingt. Een basisrecord ziet er als volgt uit: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1.
- Testen en valideren. Verzend een testmail vanuit elke bron die in stap één is geïdentificeerd en controleer de header 'Authentication-Results' op de SPF-, DKIM- en DMARC-uitspraken.
Veelgemaakte fout
Een voorbeeld van een SPF- of DMARC-record rechtstreeks in DNS kopiëren. De bovenstaande voorbeelden zijn sjablonen, geen kant-en-klare records. Een SPF-regel die diensten bevat die u niet gebruikt, verspilt lookups ten koste van het maximum van 10 lookups, en een DMARC-record dat verwijst naar een rapportage-mailbox waarvan niemand de eigenaar is, betekent dat de verzamelde gegevens nergens terechtkomen. Pas beide aan voor uw eigen afzenders en rapportageadressen voordat u ze publiceert.
Voor records die de opzoeklimiet overschrijden naarmate SaaS-platforms groeien, is een SPF-afvlakkingstool zorgt ervoor dat ze automatisch binnen de grenzen blijven. Zodra de records live zijn, gebruik je een domeinanalysator om de volledige SPF-, DKIM- en DMARC-configuratie binnen enkele seconden te valideren.
| Opdracht | Protocol | Vereist | Gereedschap |
|---|---|---|---|
| Controleer alle bronnen waaruit e-mails worden verzonden | Alle | Ja | Handmatige of DMARC-rapporten |
| SPF TXT-record in DNS publiceren | SPF | Ja | SPF Generator of PowerSPF |
| DKIM-ondertekening configureren en sleutel publiceren | DKIM | Ja | DKIM-generator of gehoste DKIM |
| DMARC-record publiceren met p=none | DMARC | Ja | DMARC generator |
| Bekijk de DMARC-rapporten en los de fouten op | DMARC | Ja | PowerDMARC-dashboard |
| DMARC naar quarantaine verplaatsen en vervolgens afwijzen | DMARC | Aanbevolen | Handhavingswizard |
| MTA-STS en TLS-RPT implementeren | MTA-STS / TLS-RPT | Aanbevolen | Gehoste MTA-STS / TLS-RPT |
| BIMI instellen met VMC of CMC | BIMI | Optioneel | PowerBIMI / VMC-ondersteuning |
Veelvoorkomende fouten bij authenticatie en hoe je deze kunt oplossen
Er treden meestal problemen op wanneer de verzendomgeving verandert. Nieuwe SaaS-tools, regionale afzenders, doorstuurservices en DNS-wijzigingen hebben allemaal invloed op SPF, DKIM, DMARC en de transportbeveiliging. Hieronder volgen de meest voorkomende scenario’s en de bijbehorende oplossingen.
| Mislukking | Hoe dit te verhelpen |
|---|---|
| SPF-opzoekingen overschrijden 10 DNS-opzoekingen | Gebruik SPF-afvlakking of geautomatiseerd beheer om onder de limiet te blijven zonder bestaande records te verbreken |
| Afzender van een derde partij die niet in de SPF is opgenomen | Controleer de bronnen waaruit wordt geïmporteerd en voeg het ‘include’-mechanisme van de ontbrekende service toe |
| DKIM-selector ontbreekt of is verouderd | DKIM-sleutels rouleren en controleren; zorg ervoor dat de ondertekeningsselector overeenkomt met die in DNS |
| DMARC-afstemmingsfout | Zorg ervoor dat het SPF Return-Path of het DKIM-ondertekeningsdomein overeenkomt met het zichtbare „Van”-domein |
| Doorgestuurde e-mails slagen niet voor de authenticatie | Implementeer ARC waar dit wordt ondersteund om resultaten te behouden bij het doorsturen via tussenliggende partijen |
| Fouten bij de levering via TLS | Implementeer MTA-STS om versleutelde verzending af te dwingen en houd TLS-RPT in de gaten om storingen op te sporen |
| SPF of DKIM wordt goedgekeurd, maar DMARC mislukt | Het geverifieerde domein komt niet overeen met het „Van”-domein; controleer de afstemmingsmodus en het ondertekeningsdomein |
Best Practices voor e-mailverificatie
Het publiceren van de gegevens is de eerste stap. Om de authenticatie op de lange termijn sterk te houden, zijn een paar vaste gewoontes nodig.
Begin met monitoren, en vervolgens handhaven
Begin met p=none om gegevens te verzamelen zonder de bezorging te beïnvloeden. Analyseer de rapporten om alle legitieme afzenders te identificeren, corrigeer verkeerde instellingen en schakel vervolgens geleidelijk over naar p=quarantine en p=reject naarmate het vertrouwen toeneemt.
Zorg ervoor dat de SPF-gegevens actueel blijven en binnen de limiet blijven
Werk je SPF-record telkens bij wanneer je een verzendservice toevoegt of verwijdert, aangezien een verouderd record legitieme e-mail tegenhoudt. Let op de limiet van 10 lookups naarmate je stack groeit, want als je deze overschrijdt, wordt de gehele SPF-controle voor elk bericht mislukt. Organisaties die veel SaaS-platforms gebruiken, moeten de SPF-complexiteit continu in de gaten houden en geautomatiseerd beheer of ‘flattening’ toepassen om fouten te voorkomen naarmate het aantal afzenders toeneemt.
Draai DKIM-sleutels regelmatig
Het rouleren van DKIM-sleutels vermindert het risico dat sleutels in verkeerde handen vallen. Het wordt aanbevolen om dit elke 6 tot 12 maanden te doen, en onmiddellijk als u vermoedt dat de privésleutel is gelekt.
Veelgestelde Vragen
Heb ik SPF, DKIM en DMARC nodig als ik gebruikmaak van een e-mailserviceprovider?
Ja. De meeste e-maildienstverleners (ESP’s) gebruiken voor veel klanten dezelfde verzendinfrastructuur, waardoor hun standaardconfiguratie je domein mogelijk niet volledig verifieert. Je publiceert je eigen SPF-, DKIM- en DMARC-records; de ESP helpt je bij het configureren van DKIM-ondertekening.
Welk protocol moet ik als eerste instellen?
Eerst SPF, dan DKIM en vervolgens DMARC met p=none. DMARC is voor zijn werking afhankelijk van de resultaten van SPF of DKIM; als je het dus als eerste implementeert zonder dat de andere twee al zijn ingesteld, heb je geen referentiepunt om je aan te spiegelen.
Wat is het verschil tussen authenticatie en versleuteling?
Authenticatie controleert wie een bericht heeft verzonden en of het is gewijzigd. Versleuteling beschermt de inhoud tijdens het verzenden. MTA-STS en TLS-RPT zorgen voor de versleuteling; SPF, DKIM en DMARC zorgen voor de identiteitscontrole.
Waarom slagen mijn doorgestuurde e-mails niet voor de authenticatie?
Het doorsturen via mailinglijsten of ticketsystemen kan de oorspronkelijke SPF- of DKIM-handtekening beschadigen. ARC behoudt de oorspronkelijke resultaten bij elke tussenstap, zodat een ontvangende server die ARC ondersteunt het bericht nog steeds kan vertrouwen.
Hoe lang duurt het voordat de authenticatie van kracht wordt?
DNS-wijzigingen worden binnen enkele minuten tot enkele uren doorgevoerd, afhankelijk van de TTL. Het duurt enkele dagen tot een paar weken voordat er voldoende DMARC-rapportagegegevens zijn verzameld voor al uw verzendbronnen.
Kan ik direct naar p=reject gaan?
Dit wordt ten zeerste afgeraden. Zonder een controleperiode bij p=none kun je niet zien welke legitieme afzenders er problemen ondervinden, en als je te snel overgaat tot afwijzing, kun je je eigen facturen en transactiemails blokkeren.




