Il requisito DMARC p=reject per BIMI spiegato
Il requisito DMARC p=reject per BIMI spiegato
La maggior parte delle implementazioni BIMI fallite riconducono a un'unica causa: una policy DMARC errata. Le organizzazioni si concentrano sulla generazione del file logo SVG e trascurano il requisito di autenticazione che determina se il logo viene visualizzato o meno.
BIMI è un protocollo di sicurezza, non una funzionalità di branding. I provider di posta elettronica mostrano il tuo logo solo dopo aver verificato crittograficamente che il messaggio proviene dal tuo dominio [1].
Questo articolo descrive il prerequisito DMARC per BIMI, confronta le tre policy di applicazione e specifica come preparare il tuo dominio.
Cos'è DMARC?
Domain-based Message Authentication, Reporting, and Conformance (DMARC) è uno standard di autenticazione email che impedisce a mittenti non autorizzati di utilizzare il tuo dominio nell'intestazione From.
DMARC si basa su due protocolli sottostanti:
- SPF (Sender Policy Framework): Verifica che l'indirizzo IP del mittente sia autorizzato dal proprietario del dominio.
- DKIM (DomainKeys Identified Mail): Applica una firma crittografica a ogni messaggio affinché il destinatario possa confermare che il messaggio non è stato modificato durante il transito.
Il record DMARC indica ai server riceventi, come Gmail e Yahoo, come gestire i messaggi che falliscono sia SPF che DKIM.
Le tre policy DMARC
Pubblichi il tuo record DMARC come record TXT nella tua zona DNS. Il tag p= definisce la policy di applicazione.
1. p=none (Modalità monitoraggio)
Il server ricevente consegna i messaggi non conformi nella posta in arrivo e invia report aggregati all'indirizzo che specifichi. Utilizza questa policy per identificare le fonti di invio legittime prima di passare all'applicazione.
Stato BIMI: ❌ Rifiutato. I provider di posta elettronica non visualizzano i loghi BIMI per i domini con p=none.
2. p=quarantine (Modalità applicazione)
Il server ricevente instrada i messaggi non conformi nella cartella spam o posta indesiderata.
Stato BIMI: ✅ Accettato. Questa è la policy minima che qualifica per BIMI. La policy deve applicarsi al 100% dei messaggi. Includi pct=100 oppure ometti il tag pct (il valore predefinito è 100).
3. p=reject (Modalità applicazione rigorosa)
Il server ricevente elimina i messaggi non conformi. Non vengono consegnati. Stato BIMI: ✅ Accettato. Questa è la policy raccomandata per BIMI.
Perché BIMI richiede l'applicazione
Il requisito esiste per prevenire lo spoofing visivo. Quando un provider di posta elettronica visualizza il tuo logo accanto a un messaggio, sta attestando al destinatario che il messaggio è autentico [2].
Se BIMI accettasse p=none, un attaccante potrebbe falsificare il tuo dominio e far sì che il provider di posta elettronica visualizzi il tuo logo accanto a un messaggio di phishing. Richiedere p=quarantine o p=reject garantisce che il proprietario del dominio abbia bloccato la posta non autenticata prima che il logo venga concesso.
Considerazioni sui sottodomini
Le aziende utilizzano frequentemente sottodomini per flussi di posta distinti, come marketing.company.com o receipts.company.com. BIMI richiede che il dominio organizzativo sia in modalità applicazione.
Se il tuo dominio organizzativo pubblica p=reject ma sovrascrive i sottodomini con sp=none, BIMI fallisce per la posta inviata da quei sottodomini. L'applicazione deve essere attiva sia per il dominio organizzativo che per i suoi sottodomini.
Come verificare la tua infrastruttura
Conferma il tuo stato DMARC prima di generare un file SVG o richiedere un Verified Mark Certificate (VMC).
Usa makeBIMI per verificare il tuo dominio. Lo strumento interroga i tuoi record DNS, valuta la configurazione SPF e DMARC e riporta se il tuo dominio soddisfa il requisito di applicazione per BIMI.
Dopo che il tuo dominio supera la verifica, genera il tuo file SVG conforme e rivolgiti a un intermediario CA come veriBIMI per ottenere il tuo certificato.
Riferimenti
[1] M. Blank, et al. "Brand Indicators for Message Identification (BIMI)." IETF Datatracker, RFC 9091, https://datatracker.ietf.org/doc/html/rfc9091 [2] DMARC.org. "Overview." DMARC, https://dmarc.org/overview/