# DMARC van p=none naar p=reject in 30 dagen Canonieke URL: https://brew.new/nl/blog/dmarc-p-none-to-reject-in-30-days Auteur: Thomas Park Gepubliceerd: 2026-10-04 Bijgewerkt: 2026-10-04 DMARC is een TXT-record op `_dmarc.` dat ontvangende servers vertelt wat ze moeten doen met mail die jouw domein in de From-header gebruikt maar zowel de SPF- als de DKIM-controle met alignment niet doorstaat, en waar ze rapporten naartoe moeten sturen. `p=none` vraagt alleen om rapporten, `p=quarantine` vraagt ontvangers om falende mail als verdacht te behandelen, en `p=reject` vraagt ze die te weigeren. Gmail, Yahoo en Microsoft accepteren `p=none` van bulkverzenders, dus veel domeinen publiceren dat en laten het daarbij: ze krijgen rapporten over spoofers, maar blokkeren ze niet. Uit de analyse van Red Sift van 73,3 miljoen domeinen, aangehaald in [april 2026](https://redsift.com/blog/email-authentication-bespinlabs-redsift), bleek dat 14,9% überhaupt een DMARC-beleid had en 2,5% `p=reject` handhaafde. EasyDMARC, ook een DMARC-leverancier, [meldde in 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) dat 62,7% van de Fortune 500-bedrijven met DMARC `p=reject` gebruikte, tegenover 15,2% van de Inc. 5000-bedrijven. Hier is een plan van 30 dagen naar `p=reject`, record voor record, voor een domein dat mail verstuurt vanuit zakelijke mailboxen, een of twee ESP’s, een helpdesk en een factureringstool. Dertig dagen past bij een verzendsubdomein. Een domein dat je medewerkers voor hun dagelijkse mail gebruiken, heeft meer tijd nodig. ## De belangrijkste punten - Publiceer op dag 1 `v=DMARC1; p=none; rua=mailto:...`. Zonder `rua` mogen ontvangende servers geen geaggregeerde rapporten sturen. - Elke legitieme afzender moet slagen voor SPF of DKIM met alignment op je From-domein. Voor de meeste tools betekent dat: DKIM-ondertekening met jouw domein. - Houd SPF binnen 10 termen die een DNS-lookup vereisen, geneste includes meegeteld, anders krijgt al je mail `permerror`. - Ga op dag 15 naar `p=quarantine` en op dag 22 naar `p=reject`, telkens na een week met schone rapporten. Voor een domein dat medewerkers voor hun dagelijkse mail gebruiken, vraagt RFC 9989 om een maand voor elk van de eerste twee fases. - RFC 9989 (mei 2026) markeert `pct` als historisch. Sla de opbouw via `pct=10` en `pct=50` over. - BIMI vereist `p=quarantine` of `p=reject` op het organisatiedomein, geen `sp=none`, een logo in SVG Tiny PS en, voor Gmail, een VMC of CMC. ## Wat er in 2026 veranderde aan DMARC In mei 2026 verving de IETF RFC 7489, een informatief document (Informational) uit 2015, door DMARCbis: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), een Proposed Standard die ook RFC 9091 vervangt, plus [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) voor geaggregeerde rapportage. Drie veranderingen zijn hier van belang: - **`pct` is historisch.** Bijlage A.6 zegt dat de tag “meestal niet nauwkeurig werd toegepast, tenzij de opgegeven waarde 0 of 100 was”. - **`t=y` vervangt `pct=0`.** Ontvangers passen dan één niveau lager toe dan je beleid, dus `p=reject; t=y` werkt als quarantine. Het is een testschakelaar. - **`np` is nieuw.** Deze tag geldt voor subdomeinen die niet in de DNS bestaan, en oudere ontvangers moeten hem negeren. Voor het bepalen van het organisatiedomein vervangt een DNS tree walk bovendien de Public Suffix List. ## De drie records waar DMARC op steunt DMARC slaagt als SPF of DKIM slaagt **en** het geslaagde domein in lijn is met het From-domein. Eén geslaagde controle met alignment is genoeg. ### SPF en de limiet van 10 lookups SPF autoriseert servers voor het envelopedomein (`MAIL FROM` of return-path), de enige identiteit die DMARC gebruikt, niet HELO. [RFC 7208, sectie 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) beperkt het aantal termen dat een DNS-lookup vereist tot 10: `include`, `a`, `mx`, `ptr`, `exists` en `redirect`, geteld door alle geneste includes heen. `ip4`, `ip6` en `all` tellen niet mee. Ga je erboven, dan is het resultaat `permerror`. Dezelfde sectie staat ook maximaal twee “void lookups” toe, meestal een include voor een hostnaam die niet meer bestaat. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` Daarmee zitten er al 4 lookups op voordat je meetelt wat elke leverancier nest, dus los ze allemaal op met `dig +short TXT `, de hele keten af. Om binnen de 10 te blijven, schrap je tools die je niet meer gebruikt of geef je elke ESP een eigen return-path-subdomein, zoals `bounce.example.com`, met een eigen budget van 10. De [SPF-handleiding](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) van Microsoft raadt aan om te eindigen met `-all` op domeinen die ook DKIM en DMARC gebruiken. Veel ESP’s gebruiken standaard hun eigen return-path-domein, en dat is niet in lijn met het jouwe. Stel een eigen return-path in of vertrouw op DKIM. ### DKIM: 2048-bitsleutels, selectors en rotatie DKIM ondertekent elk bericht met een domein `d=` en een selector `s=`; de ontvangende server haalt de sleutel op bij `._domainkey.`. Een tool die ondertekent met `d=vendor-mail.example` slaagt voor DKIM en zakt voor DMARC. Volgens [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) moeten ondertekenaars RSA-sleutels van minstens 1024 bits gebruiken, en zouden ze 2048 bits moeten gebruiken. [De richtlijnen van Google voor afzenders](https://support.google.com/mail/answer/81126) zeggen hetzelfde voor mail naar persoonlijke Gmail-accounts. Een sleutel van 2048 bits is langer dan de limiet van 255 tekens voor een TXT-string, dus je zet hem als meerdere strings tussen aanhalingstekens in één record. De meeste DNS-hosts splitsen dat voor je op. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Geef elk verzendsysteem een eigen selector en gebruik een naam nooit opnieuw. Een datum, zoals `s202610`, houdt de geschiedenis leesbaar. Volgens de [praktijken voor sleutelrotatie](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) van M3AAWG roteer je minstens elke zes maanden: 1. Publiceer de nieuwe selector en wacht tot die is doorgevoerd. 2. Schakel de ondertekening over op de nieuwe sleutel. 3. Laat de oude publieke sleutel 7 tot 30 dagen in de DNS staan, zodat mail die nog onderweg is kan worden geverifieerd. 4. Zet de oude selector buiten gebruik met een lege `p=`. Verwijder hem niet. ### Alignment: relaxed of strict RFC 9989 definieert twee modi: | Modus | Tag | Geslaagd SPF/DKIM-domein | From-domein | In lijn? | |---|---|---|---|---| | Relaxed (standaard) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Ja, hetzelfde organisatiedomein | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Nee, de namen moeten exact overeenkomen | | Beide | | `vendor.example.net` | `example.com` | Nee | RFC 9989 merkt op dat “bijna alle domeineigenaren relaxed alignment voldoende hebben gevonden”. Laat `aspf` en `adkim` weg. Strikte SPF-alignment breekt het gebruikelijke return-path op een subdomein. ## Het 30-dagenplan ![Een DMARC-tijdlijn van 30 dagen in vier fases: dag 1 t/m 7 op p=none met rua-rapportage, dag 8 t/m 14 afzenders repareren, dag 15 op p=quarantine, dag 22 op p=reject en daarna BIMI vanaf dag 30, met het exacte TXT-record voor elke fase.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Het record voor elke fase. Ga pas door na een week met schone rapporten.* | Dagen | Beleid | Wat je doet | Voorwaarde om door te gaan | |---|---|---|---| | 1 t/m 7 | `p=none` | Publiceren met `rua`, elke bron in kaart brengen | 7 dagen rapporten van Google, Yahoo en Microsoft | | 8 t/m 14 | `p=none` | DKIM en SPF repareren, ongebruikte afzenders opruimen | Elke legitieme bron slaagt voor SPF of DKIM met alignment | | 15 t/m 21 | `p=quarantine` | Letten op legitieme mail die in quarantaine belandt | 7 dagen zonder falende legitieme bron | | 22 t/m 30 | `p=reject` | Rapporten blijven lezen, `np=reject` toevoegen | Een week stabiel | | 30+ | `p=reject` | Met BIMI beginnen | Certificaat uitgegeven | Duikt er in week 2 een bron op die niemand kan repareren, blijf dan op `p=none`. Je eigen facturen weigeren is erger dan later handhaven. ### Dag 1 tot en met 7: publiceer p=none met rapportage ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Rapporten zijn met gzip gecomprimeerde XML-bestanden, minstens dagelijks van elke ontvangende server, dus laat `rua` naar een rapportverwerker wijzen, niet naar een persoon. Staat het adres op een ander organisatiedomein, dan negeren ontvangers het volgens RFC 9990, tenzij `example.com._report._dmarc.` het autoriseert. Rapportverwerkers publiceren dat record zelf; voor je eigen domeinen voeg je het zelf toe. Publiceer precies één DMARC-record. Laten installatiewizards twee `v=DMARC1`-records achter op `_dmarc.example.com`, dan negeren ontvangers ze allebei. Sla `ruf` over. RFC 9989 merkt op dat privacybewuste ontvangers foutrapporten zwaar redigeren of helemaal niet versturen, en volgens de FAQ in de [aankondiging van Microsoft voor afzenders met hoge volumes](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) stuurt Microsoft wel `rua`-rapporten, maar is het niet van plan `ruf` te sturen. ### Zo lees je een geaggregeerd rapport RFC 9990 beschrijft XML-rapporten die “dagelijks (of vaker)” komen, één per beleidsdomein. Hier is één record, aangepast van het voorbeeld in de RFC: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` In `policy_evaluated` zijn `dkim` en `spf` de resultaten van de **alignment**, en `disposition` is wat de ontvangende server deed. `auth_results` bevat de ruwe resultaten en hun domeinen. Hier slagen beide voor `vendor.example`, dus zakken ze allebei voor alignment: een leverancier die namens jou verstuurt zonder namens jou te ondertekenen. Zet de aangepaste DKIM of domeinauthenticatie van die leverancier aan. ### Dag 1 tot en met 7: vind de onbekende afzenders Groepeer op `source_ip`, `envelope_from` en het DKIM-veld `domain` plus `selector`, sorteer op `count` en deel de resultaten zo in: | Patroon in het rapport | Waarschijnlijke oorzaak | Actie | |---|---|---| | DKIM of SPF slaagt met alignment | Correct geconfigureerd | Geen | | DKIM en SPF slagen voor domeinen van leveranciers | SaaS-tool die zijn eigen identiteit gebruikt | Aangepaste DKIM aanzetten | | DKIM slaagt met alignment, SPF faalt, IP van een mailboxprovider of mailinglijst | Doorsturen of een mailinglijst | Meestal geen. DKIM met alignment overleeft doorsturen | | Geen DKIM, SPF faalt, IP’s die niet te herleiden zijn | Spoofing | Geen. Dit is precies wat `p=reject` tegenhoudt | Om te achterhalen bij wie een IP-adres hoort, voer je `dig -x 192.0.2.123 +short` uit en bekijk je de selector, die vaak de naam van de leverancier bevat. Vraag daarna aan de financiële afdeling, support en sales wat er allemaal namens het bedrijf verstuurt: facturering, helpdesk, agenda-uitnodigingen, kantoorscanners. Doorgestuurde mail en mail van mailinglijsten zullen falen op manieren die je niet kunt repareren, en de [FAQ voor afzenders](https://support.google.com/mail/answer/14229414) van Google eist daarvoor geen alignment, dus wacht daar niet op. ### Dag 8 tot en met 14: repareer elke legitieme bron Werk van de hoogste `count` naar beneden: 1. **Zakelijke mail** (Google Workspace, Microsoft 365). Zet DKIM aan in de beheerconsole, met 2048 bits waar dat kan, en controleer of de include van de provider in je SPF-record staat. 2. **ESP’s en marketingtools.** Stel domeinauthenticatie in, zodat ze ondertekenen met jouw `d=`, plus een eigen return-path als dat wordt aangeboden. 3. **Helpdesk, facturering, CRM.** Hetzelfde als bij ESP’s. Kan een tool niet met jouw domein ondertekenen, gebruik dan een subdomein waarvoor hij dat wel kan, of het eigen domein van de tool. 4. **Tools die je niet meer gebruikt.** Verwijder hun includes en selectors. Tel daarna je SPF-lookups opnieuw. ### Dag 15: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Quarantaine betekent meestal de spammap. Let op legitieme bronnen met de disposition `quarantine`. Wil je eerst oefenen, dan vraagt `p=quarantine; t=y` ontvangers die RFC 9989 volgen om `none` toe te passen, al is de RFC pas een paar maanden oud en respecteert nog niet elke ontvanger `t`. ### Dag 22: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` Ontvangers die `p=reject` respecteren, weigeren falende mail al tijdens de SMTP-sessie, maar RFC 9989 zegt dat ze die in quarantaine moeten plaatsen als het beleid hun enige aanwijzing is, dus een deel belandt in de spammap. Dezelfde RFC zegt dat een domein op `p=reject` “NIET uitsluitend op SPF MAG vertrouwen” en met DKIM moet ondertekenen, omdat doorsturen SPF breekt, maar DKIM niet. Controleer daarom eerst of elke bron DKIM met alignment heeft. Laat `rua` voorgoed staan. De nieuwe tool van volgend kwartaal duikt eerder op in je rapporten dan in je supportwachtrij. ### Wanneer je meer tijd neemt Volgens RFC 9989, sectie 7.4, horen domeinen waarvan de gebruikers berichten op mailinglijsten plaatsen geen `p=reject` te publiceren (“SHOULD NOT”), en domeinen die dat toch doen, moeten eerst “minstens een maand” op `p=none` staan en “een even lange periode” op `p=quarantine`. Dat geldt voor de meeste hoofddomeinen van bedrijven, dus geef daar elk van de eerste twee fases een maand. Een subdomein dat alleen je ESP gebruikt, heeft geen verkeer van mailinglijsten en kan het tempo van 30 dagen aanhouden. ### Beleid voor subdomeinen: sp= en np= `p` geldt voor het domein en de subdomeinen ervan. `sp` overschrijft dat voor bestaande subdomeinen, `np` voor niet-bestaande. Een subdomein met een eigen record gebruikt dat record, en RFC 9989 negeert `sp` dan. Een apart verzendsubdomein zoals `mail.example.com`, dat door één ESP wordt gebruikt met geverifieerde SPF en DKIM, kan vanaf dag één `p=reject` publiceren. `p=none; sp=reject` op het hoofddomein beschermt de subdomeinen terwijl je met het hoofddomein zelf bezig bent, maar blokkeert BIMI. Geparkeerde domeinen horen volgens de SPF-handleiding van Microsoft `v=spf1 -all` te publiceren, plus `v=DMARC1; p=reject;` op `_dmarc`. ## Dag 30 en daarna: BIMI BIMI toont je logo naast geauthenticeerde mail in inboxen die het ondersteunen: | Vereiste | Detail | Bron | |---|---|---| | DMARC-beleid | `p=quarantine` of `p=reject` op het organisatiedomein en het From-domein | BIMI-draft | | Beleid voor subdomeinen | Als `sp` is gepubliceerd, niet `none` | BIMI-draft | | Percentage | Quarantine mag geen `pct` onder 100 hebben | BIMI-draft | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, een ``, geen scripts of externe verwijzingen, geen `x=` of `y=` op het rootelement | BIMI Group | | Certificaat | Gmail vereist een VMC (geregistreerd handelsmerk, vinkje) of een CMC (geen handelsmerk, geen vinkje) | Google | De [BIMI-draft](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) staat op revisie 14 (mei 2026) en is nog steeds een Internet-Draft die is geschreven op basis van RFC 7489, vandaar `pct`. Laat `pct` weg en zet geen `t=y`. De regel voor het organisatiedomein is een valkuil voor afzenders op subdomeinen: met `mail.example.com` op `p=reject` en `example.com` op `p=none` mogen ontvangers het logo niet tonen, dus ook het hoofddomein moet het plan doorlopen. De [SVG-richtlijnen van de BIMI Group](https://bimigroup.org/creating-bimi-svg-logo-files/) raden een vierkant, gecentreerd logo op een effen achtergrond aan, kleiner dan 32 KB. Google [voegde in september 2024 ondersteuning voor CMC’s toe](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Het record volgens de [implementatiegids van de BIMI Group](https://bimigroup.org/implementation-guide/): ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` Een handelsmerk registreren duurt maanden, dus begin nu al met alles wat met een VMC te maken heeft. ## Wat Gmail, Yahoo en Microsoft eisen Geen van de drie eist handhaving, alleen een DMARC-record en alignment. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Drempel | Rond de 5.000 per dag naar persoonlijke Gmail-accounts, per primair domein, permanent zodra bereikt | Bulkverzenders, geen aantal | Meer dan 5.000 per dag naar outlook.com, hotmail.com en live.com, per From-domein | | SPF en DKIM | Beide | Beide | Beide moeten slagen | | DMARC | Record vereist, `p=none` geaccepteerd | Minstens `p=none`, `rua` sterk aanbevolen | Minstens `p=none` | | Alignment | SPF of DKIM | SPF of DKIM, relaxed is prima | SPF of DKIM | | Bij niet voldoen | Tijdelijke en permanente weigeringen sinds november 2025 | Niet vermeld | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Bronnen: [de richtlijnen van Google voor afzenders](https://support.google.com/mail/answer/81126) en de [FAQ](https://support.google.com/mail/answer/14229414), [de best practices van Yahoo voor afzenders](https://senders.yahooinc.com/best-practices/), en de [aankondiging van april 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) en de [supportpagina over 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) van Microsoft. Microsoft begon op 5 mei 2025 met handhaven, nadat een update van 29 april de actie had veranderd van verplaatsen naar de map Ongewenste e-mail in weigeren. Volgens de FAQ van Google “wordt alignment met zowel SPF als DKIM uiteindelijk een vereiste voor afzenders”, dus zorg in week 2 voor alignment op allebei. Over afmeldingen en spamratio’s lees je meer in [wat er nog steeds geldt als een agent je e-mail verstuurt](/nl/blog/agent-email-deliverability) en in onze [gids over bezorgbaarheid](/nl/blog/email-deliverability). ## DMARC op een verzenddomein in Brew Bij het [instellen van een domein](https://docs.brew.new/get-started/verify-your-sending-domain) in Brew heb je dit nodig: - **DKIM**: een TXT-record op een `._domainkey`-selector onder je verzenddomein. Vereist. - **SPF**: een MX- en een TXT-record op `send.<your sending domain>`, het return-path van Brew. Vereist. - **DMARC**: een TXT-record op `_dmarc.<your sending domain>`. Optioneel en aanbevolen. - Een **CNAME** voor kliktracking, alleen bij een eigen trackingsubdomein. Het domein kan versturen zodra SPF en DKIM zijn geverifieerd, en Brew stelt een passende DMARC-waarde voor: ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` Een apart subdomein krijgt `p=reject`, omdat er niets vanaf wordt verstuurd voordat de SPF en DKIM van Brew zijn geverifieerd. Een hoofddomein krijgt `p=none`, omdat je andere tools waarschijnlijk ook namens dat domein versturen; volg dan het plan hierboven. De alignment blijft relaxed, omdat het return-path `send.<domain>` alleen in de relaxed-modus in lijn is. Brew leest het live record op `_dmarc.<sending domain>` bij het toevoegen, bij het verifiëren en bij elke nieuwe controle. Je ziet het resultaat onder **Domeinen**, en ook via `get_domain_health` over MCP en `GET /v1/domains/{domainId}/health`: - **`dmarc_missing`**: een waarschuwing met het exacte record dat je moet toevoegen. - **`dmarc_invalid`**: bij twee DMARC-records op dezelfde naam, of bij een ongeldige versie, een ongeldig beleid of dubbele tags. De melding noemt het record dat je moet verwijderen. - **Geverifieerd**: zodra er precies één geldig record is gevonden. De automatische DNS-instelling schrijft alleen een DMARC-record als er nog geen bestaat, dus er ontstaat nooit een dubbel record. De controle gebeurt op het verzenddomein, niet op het bovenliggende domein, dus geef elk verzendsubdomein een eigen record, ook dat voor [transactionele mail](/nl/blog/transactional-emails) als je de twee scheidt zoals de documentatie aanraadt. In je `rua`-verwerker lees je de rapporten en besluit je wanneer je naar reject gaat. ## Veelgestelde vragen ### Hoelang moet ik op p=none blijven voordat ik naar quarantine ga? Tot een volledige week aan rapporten laat zien dat elke legitieme bron slaagt voor SPF of DKIM met alignment; voor een verzendsubdomein is dat meestal één tot twee weken. Voor een domein dat medewerkers voor hun dagelijkse mail gebruiken, vraagt RFC 9989 om minstens een maand. Twee jaar op `p=none` zonder dat iemand de rapporten leest, telt voor niets. ### Is de pct-tag van DMARC verouderd? Ja. RFC 9989 noemt `pct` “historisch” en vervangt de enige betrouwbare waarden ervan door `t`: `t=y` werkt als `pct=0`, `t=n` als `pct=100`. Oudere ontvangers lezen `pct` misschien nog, maar pasten tussenliggende waarden nooit consequent toe, dus ga in hele stappen. ### Blokkeert p=reject mijn doorgestuurde e-mail? Gewoon doorsturen breekt meestal SPF, maar niet DKIM, dus DKIM met alignment slaagt nog steeds. Mailinglijsten die het onderwerp of de footer aanpassen, breken DKIM, en sommige herschrijven de From-header om dat te compenseren. Overal DKIM met alignment is je beste bescherming. ### Eisen Gmail en Yahoo p=reject? Nee. Beide eisen dat bulkverzenders DMARC publiceren en accepteren `p=none`, net als Microsoft boven de 5.000 berichten per dag naar Outlook.com. Handhaving houdt spoofing tegen en is vereist voor BIMI, maar geen van de drie eist het. ### Heb ik een VMC nodig voor BIMI? Voor Gmail heb je een VMC nodig, waarvoor je een geregistreerd handelsmerk moet hebben en die een vinkje toont, of een CMC, die het logo zonder vinkje toont. Volgens de [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) tonen een paar providers, waaronder Yahoo en Fastmail, ook logo’s zonder certificaat (self-asserted).