# DMARC da p=none a p=reject in 30 giorni URL canonico: https://brew.new/it/blog/dmarc-p-none-to-reject-in-30-days Autore: Thomas Park Pubblicato: 2026-10-04 Aggiornato: 2026-10-04 DMARC è un record TXT su `_dmarc.` che indica ai server riceventi cosa fare con le email che usano il tuo dominio nell’header From ma non superano SPF e DKIM allineati, e dove inviare i report. `p=none` chiede solo i report, `p=quarantine` chiede ai server riceventi di trattare come sospette le email che non superano il controllo e `p=reject` chiede di rifiutarle. Gmail, Yahoo e Microsoft accettano `p=none` dai mittenti di grandi volumi, così molti domini lo pubblicano e si fermano lì: vedono lo spoofing nei report, ma non lo bloccano. L’analisi di Red Sift su 73,3 milioni di domini, citata ad [aprile 2026](https://redsift.com/blog/email-authentication-bespinlabs-redsift), ha rilevato che il 14,9% aveva una qualsiasi policy DMARC e che il 2,5% applicava `p=reject`. EasyDMARC, un altro fornitore di servizi DMARC, ha [riportato nel 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) che il 62,7% delle aziende Fortune 500 con DMARC usava `p=reject`, contro il 15,2% delle aziende Inc. 5000. Ecco un piano di 30 giorni per arrivare a `p=reject`, record per record, per un dominio che invia dalla posta aziendale, da uno o due ESP, da un help desk e da uno strumento di fatturazione. Trenta giorni vanno bene per un sottodominio di invio. Un dominio che il tuo personale usa per la posta di tutti i giorni richiede più tempo. ## Punti chiave - Pubblica `v=DMARC1; p=none; rua=mailto:...` il giorno 1. Senza `rua`, i server riceventi non devono inviare report aggregati. - Ogni mittente legittimo deve superare SPF o DKIM allineati al tuo dominio From. Per la maggior parte degli strumenti, questo significa firmare con DKIM usando il tuo dominio. - Tieni SPF entro i 10 termini che generano query DNS, include annidati compresi, altrimenti tutte le tue email ottengono `permerror`. - Passa a `p=quarantine` il giorno 15 e a `p=reject` il giorno 22, ogni volta dopo una settimana di report puliti. Per un dominio che il personale usa per la posta di tutti i giorni, la RFC 9989 chiede un mese per ciascuna delle prime due fasi. - La RFC 9989 (maggio 2026) classifica `pct` come storico. Salta la progressione `pct=10`, `pct=50`. - BIMI richiede `p=quarantine` o `p=reject` sul dominio organizzativo, nessun `sp=none`, un logo SVG Tiny PS e, per Gmail, un VMC o un CMC. ## Cosa è cambiato in DMARC nel 2026 A maggio 2026 l’IETF ha sostituito la RFC 7489, un documento informativo (Informational) del 2015, con DMARCbis: la [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), un Proposed Standard che rende obsoleta anche la RFC 9091, più la [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) per i report aggregati. Qui contano tre cambiamenti: - **`pct` diventa storico.** L’appendice A.6 afferma che “di solito non veniva applicato in modo accurato, a meno che il valore specificato non fosse 0 o 100”. - **`t=y` sostituisce `pct=0`.** I server riceventi applicano il livello immediatamente inferiore alla tua policy, quindi `p=reject; t=y` funziona come quarantine. È un interruttore per i test. - **`np` è nuovo.** Copre i sottodomini che non esistono nel DNS, e i server riceventi meno recenti devono ignorarlo. Inoltre, per individuare il dominio organizzativo, la public suffix list lascia il posto a una risalita dell’albero DNS (DNS tree walk). ## I tre record da cui dipende DMARC DMARC è superato quando SPF o DKIM sono superati **e** il dominio che supera il controllo è allineato con il dominio From. Basta un solo controllo superato e allineato. ### SPF e il limite di 10 lookup SPF autorizza i server per il dominio della busta (`MAIL FROM` o return path), l’unica identità che DMARC usa, non HELO. La [RFC 7208, sezione 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) limita a 10 i termini che generano query DNS: `include`, `a`, `mx`, `ptr`, `exists` e `redirect`, contati attraverso ogni include annidato. `ip4`, `ip6` e `all` non contano. Oltre il limite, il risultato è `permerror`. La sezione consente inoltre al massimo due “void lookup” (lookup a vuoto), di solito un include verso un hostname che non esiste più. ```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" ``` Questo record consuma già 4 lookup prima ancora di contare quelli annidati da ogni fornitore, quindi risolvi ciascun include con `dig +short TXT ` lungo tutta la catena. Per restare entro i 10, elimina gli strumenti che non usi più oppure dai a ogni ESP il proprio sottodominio di return path, come `bounce.example.com`, con il suo budget di 10 lookup. La [guida alla configurazione di SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) di Microsoft consiglia di terminare con `-all` sui domini che usano anche DKIM e DMARC. Molti ESP usano per impostazione predefinita il proprio dominio di return path, che non è allineato con il tuo. Configura un return path personalizzato o affidati a DKIM. ### DKIM: chiavi a 2048 bit, selettori e rotazione DKIM firma ogni messaggio con un dominio `d=` e un selettore `s=`; il server ricevente recupera la chiave da `._domainkey.`. Uno strumento che firma con `d=vendor-mail.example` supera DKIM ma non supera DMARC. La [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) stabilisce che chi firma deve usare chiavi RSA di almeno 1024 bit e dovrebbe usarne da 2048. Le [linee guida di Google per i mittenti](https://support.google.com/mail/answer/81126) dicono lo stesso per le email dirette agli account Gmail personali. Una chiave a 2048 bit supera il limite di 255 caratteri di una stringa TXT, quindi va inserita come più stringhe tra virgolette in un unico record, e la maggior parte dei provider DNS le divide per te. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Assegna a ogni sistema di invio il proprio selettore e non riutilizzare mai un nome. Una data, come `s202610`, mantiene leggibile la cronologia. Le [pratiche di rotazione delle chiavi](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) di M3AAWG indicano di ruotarle almeno ogni sei mesi: 1. Pubblica il nuovo selettore e lascia che si propaghi. 2. Passa la firma alla nuova chiave. 3. Mantieni la vecchia chiave pubblica nel DNS per un periodo da 7 a 30 giorni, così le email in transito superano la verifica. 4. Dismetti il vecchio selettore con un `p=` vuoto. Non eliminarlo. ### Allineamento: relaxed o strict La RFC 9989 definisce due modalità: | Modalità | Tag | Dominio che supera SPF/DKIM | Dominio From | Allineato? | |---|---|---|---|---| | Relaxed (predefinita) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Sì, stesso dominio organizzativo | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | No, i nomi devono coincidere | | Entrambe | | `vendor.example.net` | `example.com` | No | La RFC 9989 osserva che “quasi tutti i proprietari di domini hanno trovato sufficiente l’allineamento relaxed”. Ometti `aspf` e `adkim`. L’allineamento SPF strict non funziona con la configurazione abituale, quella con il return path su un sottodominio. ## Il piano di 30 giorni ![Una timeline DMARC di 30 giorni in quattro fasi: dal giorno 1 al 7 con p=none e report rua, dal giorno 8 al 14 per correggere i mittenti, il giorno 15 con p=quarantine, il giorno 22 con p=reject, poi BIMI dal giorno 30, con il record TXT esatto per ogni fase.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Il record per ogni fase. Passa alla successiva solo dopo una settimana di report puliti.* | Giorni | Policy | Cosa fai | Condizione per andare avanti | |---|---|---|---| | Da 1 a 7 | `p=none` | Pubblica con `rua`, elenca ogni fonte di invio | 7 giorni di report da Google, Yahoo e Microsoft | | Da 8 a 14 | `p=none` | Correggi DKIM e SPF, dismetti i mittenti inutilizzati | Ogni fonte legittima supera SPF o DKIM allineati | | Da 15 a 21 | `p=quarantine` | Controlla se finiscono in quarantena email legittime | 7 giorni senza fonti legittime che non superano il controllo | | Da 22 a 30 | `p=reject` | Continua a leggere i report, aggiungi `np=reject` | Una settimana senza problemi | | 30+ | `p=reject` | Avvia BIMI | Certificato emesso | Se nella seconda settimana salta fuori una fonte che nessuno riesce a correggere, resta su `p=none`. Rifiutare le tue stesse fatture è peggio che applicare la policy in ritardo. ### Giorni da 1 a 7: pubblica p=none con i report ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` I report sono file XML compressi con gzip, inviati almeno una volta al giorno da ogni server ricevente, quindi fai puntare `rua` a un servizio che elabora i report, non a una persona. Se l’indirizzo si trova su un altro dominio organizzativo, la RFC 9990 prevede che i server riceventi lo ignorino, a meno che `example.com._report._dmarc.` non lo autorizzi. I servizi di elaborazione pubblicano questo record; per i tuoi domini, aggiungilo tu. Pubblica esattamente un record DMARC. Se le procedure guidate di configurazione lasciano due record `v=DMARC1` su `_dmarc.example.com`, i server riceventi li scartano entrambi. Lascia perdere `ruf`. La RFC 9989 osserva che i server riceventi attenti alla privacy oscurano pesantemente i report sugli errori o non li inviano affatto, e le FAQ contenute nell’[annuncio di Microsoft per i mittenti di grandi volumi](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) dicono che Microsoft invia i report `rua` e non ha in programma di inviare i `ruf`. ### Come leggere un report aggregato La RFC 9990 descrive report XML “giornalieri (o più frequenti)”, uno per ogni dominio a cui si applica la policy. Ecco un record, adattato dal suo esempio: ```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`, `dkim` e `spf` sono i risultati dell’**allineamento**, e `disposition` è ciò che ha fatto il server ricevente. `auth_results` contiene i risultati grezzi e i relativi domini. Qui entrambi i controlli sono superati per `vendor.example`, quindi entrambi falliscono l’allineamento: è un fornitore che invia a tuo nome senza firmare a tuo nome. Attiva il suo DKIM personalizzato o l’autenticazione del dominio. ### Giorni da 1 a 7: trova i mittenti sconosciuti Raggruppa per `source_ip`, `envelope_from` e `domain` più `selector` di DKIM, ordina per `count` e classifica i risultati: | Schema nel report | Causa probabile | Azione | |---|---|---| | DKIM o SPF superato e allineato | Configurazione corretta | Nessuna | | DKIM e SPF superati per domini del fornitore | Strumento SaaS che usa la propria identità | Attiva il DKIM personalizzato | | DKIM superato e allineato, SPF non superato, IP di un provider di posta o di una mailing list | Inoltro o mailing list | Di solito nessuna. Il DKIM allineato sopravvive all’inoltro | | Nessun DKIM, SPF non superato, IP non attribuibili | Spoofing | Nessuna. È proprio ciò che `p=reject` blocca | Per attribuire un IP, esegui `dig -x 192.0.2.123 +short` e controlla il selettore, che spesso contiene il nome del fornitore. Poi chiedi all’amministrazione, al supporto e alle vendite cosa invia email a nome dell’azienda: fatturazione, help desk, inviti del calendario, scanner dell’ufficio. Le email inoltrate e quelle delle mailing list non supereranno i controlli in modi che non puoi correggere, e le [FAQ di Google per i mittenti](https://support.google.com/mail/answer/14229414) non richiedono l’allineamento per queste email, quindi non lasciare che ti blocchino. ### Giorni da 8 a 14: correggi ogni fonte legittima Procedi dal `count` più alto verso il basso: 1. **Posta aziendale** (Google Workspace, Microsoft 365). Attiva DKIM nella console di amministrazione, a 2048 bit dove disponibile, e verifica che l’include del provider sia presente in SPF. 2. **ESP e strumenti di marketing.** Configura l’autenticazione del dominio in modo che firmino con il tuo `d=`, più un return path personalizzato se disponibile. 3. **Help desk, fatturazione, CRM.** Come per gli ESP. Se uno di questi strumenti non può firmare con il tuo dominio, usa un sottodominio per cui può firmare, oppure il suo dominio. 4. **Strumenti dismessi.** Rimuovi i loro include e selettori. Alla fine, ricalcola i lookup SPF. ### Giorno 15: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Di solito, quarantena significa cartella spam. Controlla se ci sono fonti legittime con disposition `quarantine`. Per fare una prova, `p=quarantine; t=y` chiede ai server riceventi conformi alla RFC 9989 di applicare `none`, anche se la RFC ha pochi mesi e non tutti i server riceventi rispettano ancora `t`. ### Giorno 22: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` I server riceventi che rispettano `p=reject` rifiutano le email che non superano il controllo durante la sessione SMTP, ma la RFC 9989 indica loro di metterle in quarantena quando la policy è l’unico elemento a disposizione, quindi una parte finisce nello spam. La stessa RFC afferma che un dominio con `p=reject` “NON DEVE affidarsi solo a SPF” e deve firmare con DKIM, perché l’inoltro rompe SPF ma non DKIM. Prima, verifica che ogni fonte abbia un DKIM allineato. Mantieni `rua` per sempre. Il nuovo strumento del prossimo trimestre comparirà nei tuoi report prima che nella coda del supporto. ### Quando allungare il piano La RFC 9989, alla sezione 7.4, afferma che i domini i cui utenti scrivono sulle mailing list “NON DOVREBBERO” pubblicare `p=reject`, e che quelli che lo fanno dovrebbero prima restare “almeno un mese” su `p=none` e “un periodo altrettanto lungo” su `p=quarantine`. È il caso della maggior parte dei domini principali (apex) delle aziende, quindi lì dedica un mese a ciascuna delle prime due fasi. Un sottodominio usato solo dal tuo ESP non ha traffico di mailing list e può mantenere il ritmo di 30 giorni. ### Policy dei sottodomini: sp= e np= `p` copre il dominio e i suoi sottodomini. `sp` lo sostituisce per i sottodomini esistenti, `np` per quelli inesistenti. Un sottodominio con un proprio record usa quello, e lì la RFC 9989 ignora `sp`. Un sottodominio di invio dedicato come `mail.example.com`, usato da un solo ESP con SPF e DKIM verificati, può pubblicare `p=reject` fin dal primo giorno. `p=none; sp=reject` sul dominio principale protegge i sottodomini mentre finisci il lavoro sul dominio stesso, ma blocca BIMI. I domini parcheggiati dovrebbero pubblicare `v=spf1 -all`, come indica la guida SPF di Microsoft, più `v=DMARC1; p=reject;` su `_dmarc`. ## Dal giorno 30 in poi: BIMI BIMI mostra il tuo logo accanto alle email autenticate nelle inbox che lo supportano: | Requisito | Dettaglio | Fonte | |---|---|---| | Policy DMARC | `p=quarantine` o `p=reject` sul dominio organizzativo e sul dominio From | Bozza BIMI | | Policy dei sottodomini | Se `sp` è pubblicato, non `none` | Bozza BIMI | | Percentuale | Con quarantine, `pct` non deve essere inferiore a 100 | Bozza BIMI | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, un ``, nessuno script o riferimento esterno, nessun `x=` o `y=` sull’elemento radice | BIMI Group | | Certificato | Gmail richiede un VMC (marchio registrato, segno di spunta) o un CMC (nessun marchio, nessun segno di spunta) | Google | La [bozza BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) è alla revisione 14 (maggio 2026): è ancora un Internet-Draft scritto sulla base della RFC 7489, da cui il riferimento a `pct`. Ometti `pct` e non impostare `t=y`. La regola del dominio organizzativo coglie in fallo chi invia da un sottodominio: con `mail.example.com` su `p=reject` ed `example.com` su `p=none`, i server riceventi non devono mostrare il logo, quindi anche il dominio principale deve completare il piano. Le [indicazioni del BIMI Group sugli SVG](https://bimigroup.org/creating-bimi-svg-logo-files/) consigliano un logo quadrato e centrato su sfondo pieno, sotto i 32 KB. Google ha [aggiunto il supporto ai CMC a settembre 2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Ecco il record, secondo la [guida all’implementazione del 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" ``` La registrazione di un marchio richiede mesi, quindi se ti serve un VMC inizia subito. ## Cosa richiedono Gmail, Yahoo e Microsoft Nessuno dei tre richiede una policy applicata: solo un record DMARC e l’allineamento. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Soglia | Circa 5.000 al giorno verso account Gmail personali, per dominio principale, permanente una volta raggiunta | Mittenti di grandi volumi, senza un numero preciso | Oltre 5.000 al giorno verso outlook.com, hotmail.com e live.com, per dominio From | | SPF e DKIM | Entrambi | Entrambi | Entrambi devono essere superati | | DMARC | Record obbligatorio, `p=none` accettato | Almeno `p=none`, `rua` fortemente consigliato | Almeno `p=none` | | Allineamento | SPF o DKIM | SPF o DKIM, relaxed va bene | SPF o DKIM | | In caso di errore | Rifiuti temporanei e permanenti da novembre 2025 | Non specificato | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Fonti: [linee guida di Google per i mittenti](https://support.google.com/mail/answer/81126) e relative [FAQ](https://support.google.com/mail/answer/14229414), [best practice di Yahoo per i mittenti](https://senders.yahooinc.com/best-practices/), e l’[annuncio di aprile 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) e la [pagina di supporto sul codice 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) di Microsoft. Microsoft ha iniziato ad applicare i requisiti il 5 maggio 2025, dopo che un aggiornamento del 29 aprile aveva cambiato l’azione: dallo spostamento nella posta indesiderata al rifiuto. Le FAQ di Google affermano che l’allineamento sia con SPF sia con DKIM “diventerà prima o poi un requisito per i mittenti”, quindi allineali entrambi nella seconda settimana. Per i tassi di disiscrizione e di spam, leggi [cosa vale ancora quando è un agente a inviare le tue email](/it/blog/agent-email-deliverability) e la nostra [guida alla deliverability](/it/blog/email-deliverability). ## DMARC su un dominio di invio di Brew La [configurazione del dominio](https://docs.brew.new/get-started/verify-your-sending-domain) di Brew richiede: - **DKIM**, un record TXT su un selettore `._domainkey` sotto il tuo dominio di invio. Obbligatorio. - **SPF**, un record MX e un record TXT su `send.<your sending domain>`, il return path di Brew. Obbligatorio. - **DMARC**, un record TXT su `_dmarc.<your sending domain>`. Facoltativo, ma consigliato. - Un **CNAME** per il tracciamento dei clic, solo con un sottodominio di tracciamento personalizzato. Il dominio può inviare non appena SPF e DKIM risultano verificati, e Brew suggerisce un valore DMARC adatto: ```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" ``` A un sottodominio dedicato Brew suggerisce `p=reject`, perché da lì non parte nulla prima che SPF e DKIM di Brew siano verificati. A un dominio principale suggerisce `p=none`, perché probabilmente anche gli altri tuoi strumenti inviano a suo nome: in quel caso segui il piano descritto sopra. L’allineamento resta relaxed, perché il return path `send.<domain>` è allineato solo in modalità relaxed. Brew legge il record `_dmarc.<sending domain>` pubblicato quando aggiungi il dominio, quando lo verifichi e a ogni nuovo controllo. Il risultato compare in **Domini**, oltre che in `get_domain_health` tramite MCP e in `GET /v1/domains/{domainId}/health`: - **`dmarc_missing`**, un avviso con il record esatto da aggiungere. - **`dmarc_invalid`**, se ci sono due record DMARC sullo stesso nome, oppure una versione o una policy non valida o tag duplicati. Indica il record da eliminare. - **Verificato**, quando viene trovato esattamente un record valido. La configurazione DNS automatica scrive il record DMARC solo quando non ne esiste già uno, quindi non lo duplica mai. Il controllo avviene sul dominio di invio, non sul dominio padre, quindi dai a ogni sottodominio di invio il proprio record, compreso quello per le [email transazionali](/it/blog/transactional-emails) se separi i due tipi di invio come consiglia la documentazione. È nel servizio che elabora i tuoi report `rua` che leggi i report e decidi quando passare a reject. ## Domande frequenti ### Quanto tempo devo restare su p=none prima di passare a quarantine? Finché un’intera settimana di report non mostra che ogni fonte legittima supera SPF o DKIM allineati: di solito da una a due settimane per un sottodominio di invio. Per un dominio che il personale usa per la posta di tutti i giorni, la RFC 9989 chiede almeno un mese. Due anni su `p=none` senza che nessuno legga i report non valgono nulla. ### Il tag pct di DMARC è deprecato? Sì. La RFC 9989 classifica `pct` come “historic” (storico) e sostituisce i suoi unici valori affidabili con `t`: `t=y` si comporta come `pct=0`, `t=n` come `pct=100`. I server riceventi meno recenti potrebbero ancora leggere `pct`, ma non hanno mai applicato in modo coerente i valori intermedi, quindi procedi per passi interi. ### Con p=reject le mie email inoltrate verranno bloccate? Un inoltro semplice di solito rompe SPF ma non DKIM, quindi il DKIM allineato viene comunque superato. Le mailing list che modificano l’oggetto o il footer rompono DKIM, e alcune riscrivono l’header From per compensare. Un DKIM allineato ovunque è la tua protezione migliore. ### Gmail e Yahoo richiedono p=reject? No. Entrambi chiedono ai mittenti di grandi volumi di pubblicare DMARC e accettano `p=none`, come fa Microsoft oltre i 5.000 messaggi al giorno verso Outlook.com. Una policy applicata blocca lo spoofing ed è obbligatoria per BIMI, ma nessuno dei tre la richiede. ### Mi serve un VMC per BIMI? Per Gmail ti serve un VMC, che richiede un marchio registrato e mostra un segno di spunta, oppure un CMC, che mostra il logo senza spunta. Il [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) segnala che alcuni provider, tra cui Yahoo e Fastmail, mostrano anche loghi autodichiarati, senza alcun certificato.