Perché esiste Spoofhound
L’e-mail è stata costruita sulla fiducia.
Internet no.
Il protocollo che trasporta le tue fatture, i contratti e i reset delle password è stato progettato nel 1982 senza alcun controllo di sicurezza — perché nessuno sembrava necessario. Tutto ciò che è venuto dopo è stato un rattoppo. Questa pagina spiega i problemi che quella storia ti ha lasciato, ed esattamente come Spoofhound li risolve.
Breve storia di un protocollo non sicuro
Nessuno aveva previsto cosa sarebbe diventata l’e-mail.
Spoofhound aiuta a proteggere le tue e-mail.
SMTP è stato scritto per una piccola rete di istituzioni che si conoscevano tra loro. Nessuno dei suoi progettisti aveva previsto miliardi di messaggi al giorno tra sconosciuti — né lo spam, lo spoofing e il phishing diventati industrie da miliardi. Ogni salvaguardia che l’e-mail ha oggi è stata aggiunta decenni dopo, e ognuna esiste per tappare un buco preciso di quel modello di fiducia originale.
-
1978
Il primo spam
Un commerciale invia a circa 400 utenti di ARPANET un annuncio di prodotto non richiesto. La reazione è furiosa — e non cambia nulla. Non esiste alcun meccanismo per fermare il successivo.
-
1982
SMTP viene standardizzato (RFC 821)
Il protocollo che ancora oggi trasporta l’e-mail del mondo è scritto per una rete di poche centinaia di host fidati, per lo più accademici. Qualsiasi server può rivendicare qualsiasi indirizzo mittente; la riga From è solo testo. Nessuna autenticazione, nessuna cifratura, nessuna verifica — niente di tutto ciò ritenuto necessario tra colleghi che si conoscevano.
-
1990s
L’e-mail supera i propri presupposti
Internet si apre al pubblico e l’e-mail ne diventa la prima killer app. Il modello di fiducia costruito per centinaia di host trasporta ora la posta tra perfetti sconosciuti, e lo spam si industrializza quasi subito — nei primi anni 2000 è la maggioranza di tutta l’e-mail inviata.
-
1996
Il «phishing» prende il suo nome
Gli attaccanti scoprono il corollario di una riga From non autenticata: posta che afferma di provenire dalla tua banca, dal tuo provider, dal tuo capo. Il termine nasce tra i ladri di account AOL; la tecnica non scompare più.
-
2002
STARTTLS (RFC 3207): cifratura, in modo opportunistico
La posta da server a server può ora essere cifrata — ma solo se entrambe le parti la offrono, e la consegna prosegue comunque se la negoziazione fallisce. Un attaccante sul percorso può semplicemente rimuovere l’offerta e leggere la posta. Nessuno viene avvisato quando accade.
-
2003–2007
SPF e DKIM aggiungono l’autenticazione
SPF pubblica quali server possono inviare per un dominio; DKIM aggiunge una firma crittografica. Entrambi sono un progresso reale — ed entrambi verificano identificatori tecnici nascosti anziché l’indirizzo From che una persona legge davvero. Un messaggio può superare l’uno o l’altro mostrando il dominio di qualcun altro.
-
2012–2015
DMARC lo lega alla riga From
DMARC richiede che SPF o DKIM siano allineati al dominio From visibile, consente al proprietario di pubblicare una policy (monitorare, mettere in quarantena o rifiutare) e — cosa cruciale — obbliga i destinatari a segnalare chi invia a nome del dominio. Per la prima volta, un proprietario di dominio può vedere l’abuso e spegnerlo.
-
2018
MTA-STS e TLS-RPT (RFC 8461/8460) colmano il divario di cifratura
MTA-STS consente a un dominio di richiedere TLS verificato per la posta in entrata invece di limitarsi a sperarlo; TLS-RPT è il suo anello di feedback — report giornalieri dai mittenti su ogni connessione fallita o declassata che altrimenti fallirebbe in silenzio.
-
2019–2021
BIMI: una ricompensa visibile per aver finito il lavoro
Brand Indicators for Message Identification mette il logo verificato di un dominio accanto alla sua posta in Gmail, Yahoo, Apple Mail e altri — ma solo per i domini che hanno portato DMARC fino all’applicazione, con un logo SVG validato e, per la maggior parte dei provider, un Verified Mark Certificate che prova che il marchio ne è proprietario. Per la prima volta, fare bene la sicurezza dell’e-mail si vede in un posto che tutti possono vedere.
-
2026
DMARCbis (RFC 9989) diventa lo standard
DMARC si eleva a Standard Internet a pieno titolo, con indicazioni più nette: un percorso misurato e graduale verso l’applicazione, e una policy scelta in base a come un dominio è effettivamente usato.
Perché DMARC
La riga From che vede il tuo lettore è quella che conta.
SPF e DKIM autenticano cose reali — il server mittente, la firma del messaggio — ma nessuno dei due deve corrispondere all’indirizzo From che una persona legge davvero. Un phisher può superare entrambi su un dominio proprio mostrando il tuo. DMARC colma questa lacuna: esige che ciò che ha superato la verifica sia allineato al dominio From visibile, e ti permette di dire a ogni destinatario del pianeta cosa fare quando non lo è — consegnarlo, cestinarlo o rifiutarlo del tutto.
Altrettanto importante, DMARC produce report. Ogni grande destinatario invia al proprietario del dominio un resoconto giornaliero di ciò che sosteneva di essere lui: quali sorgenti, quali volumi, cosa ha superato, cosa è fallito. Quei report sono la visibilità su cui tutto il resto si fonda — non puoi applicare in sicurezza una policy contro mittenti che non hai identificato, motivo per cui la RFC 9989 prescrive un percorso misurato e graduale: prima monitorare, capire ogni sorgente, poi stringere.
Perché TLS-RPT
Una cifratura che non puoi verificare è una cifratura che non hai.
La posta tra server è cifrata solo in modo opportunistico: se l’handshake TLS fallisce, o un attaccante sul percorso rimuove di nascosto l’offerta, il messaggio viene inviato comunque — in chiaro. Il mittente non lo sa. Tu non lo sai. MTA-STS risolve la metà relativa alla policy, permettendo al tuo dominio di richiedere TLS verificato invece di sperarci.
TLS-RPT è la metà di cui nessuno si ricorda: l’anello di feedback. I mittenti ti segnalano, ogni giorno, ogni connessione al tuo dominio che ha fallito o declassato la propria cifratura — il che è al tempo stesso il tuo preavviso di un attacco in corso e il tuo unico modo di sapere che una policy MTA-STS funziona anziché respingere in silenzio posta legittima. Senza i report, applichi alla cieca.
Perché BIMI
Il tuo logo, solo dove la tua posta è dimostrata autentica.
BIMI è la ricompensa per tutto quanto sopra: una volta applicato DMARC, i provider di caselle partecipanti — Gmail, Yahoo, Apple Mail, Fastmail — mostrano il tuo logo verificato accanto ai tuoi messaggi. Sono impression di marca quotidiane nell’unico posto in cui i tuoi clienti guardano in modo affidabile, e un segnale visivo che un phisher non può riprodurre, perché il logo compare solo sulla posta che ha superato l’autenticazione per il tuo dominio in applicazione.
Arrivarci ha spigoli vivi: il logo deve essere un file SVG Tiny P/S valido, la maggior parte dei provider richiede un Verified Mark Certificate che provi che il marchio ne è proprietario, e tutto — record, logo, scadenza del certificato — deve restare corretto o il logo sparisce in silenzio. Spoofhound monitora tutti e tre per ogni dominio, e può ospitare per te il logo validato e il certificato, così BIMI resta una ricompensa e non un’altra cosa da sorvegliare.
I problemi che Spoofhound risolve
Cinque problemi che ha ogni proprietario di dominio.
Che lo sappia o no.
I criminali inviano e-mail a nome del tuo dominio
Il problema: La frode sulle fatture, il dirottamento degli stipendi e il phishing rivolto ai tuoi clienti e al personale usano abitualmente il tuo dominio esatto nella riga From — perché finché DMARC non è applicato, i destinatari la consegnano. La frode del CEO (BEC) è costantemente in cima alle perdite per criminalità informatica segnalate all’FBI, anno dopo anno.
Come lo risolve Spoofhound: Spoofhound stabilisce una linea di base per ogni sorgente di invio legittima nei tuoi report DMARC, così una sorgente del tutto nuova che fallisce l’allineamento — la classica firma dello spoofing — fa scattare un allarme lo stesso giorno, con una riga di runbook che ti dice cosa significa e cosa fare. Cosa DMARC ferma e cosa no →
La tua posta legittima finisce nello spam — o da nessuna parte
Il problema: Google, Yahoo e Microsoft ora richiedono l’autenticazione (incluso DMARC per i mittenti massivi) come condizione di consegna. Una piattaforma di marketing dimenticata o un record SPF mal configurato ti costa in silenzio il posizionamento in posta in arrivo, e nessuno ti dice quale messaggio è fallito o perché.
Come lo risolve Spoofhound: Ogni identità di invio vista nei tuoi report viene inventariata e classificata — legittima, inoltratore, mal configurata o malevola — così puoi correggere quelle mal configurate e portare ogni mittente reale a superare la verifica e ad allinearsi prima di stringere la policy.
Le prove esistono, ma nessuno riesce a leggerle
Il problema: I report DMARC e TLS arrivano come allegati XML e JSON compressi, per destinatario, per giorno, in una casella di posta. La visibilità che ti serve ti viene tecnicamente già inviata — in una forma che nessun essere umano leggerà mai.
Come lo risolve Spoofhound: Spoofhound li acquisisce e li legge tutti, ogni giorno, e si apre su una coda di triage di cose che richiedono davvero una decisione — non un muro di grafici. Un riepilogo del lunedì sintetizza la settimana in frasi.
L’applicazione sembra troppo rischiosa per essere mai portata a termine
Il problema: Passare a quarantena o rifiuto è dove sta la protezione — ma un passo falso cestina le tue stesse fatture o gli stipendi. Così la maggior parte dei domini resta bloccata su p=none per sempre, monitorata ma non protetta.
Come lo risolve Spoofhound: La procedura guidata di applicazione codifica il percorso sicuro: una soglia del 98% di superamento allineato su una finestra mobile più un controllo «tutte le sorgenti spiegate», con una raccomandazione a fasi a ogni passo — la progressione misurata che la stessa RFC 9989 prescrive.
La cifratura della posta fallisce in silenzio
Il problema: STARTTLS è opportunistico: se la negoziazione TLS fallisce — o un attaccante la rimuove — la posta viene consegnata comunque, in chiaro, e nessuno viene avvisato. Senza MTA-STS e TLS-RPT non puoi sapere che sta accadendo.
Come lo risolve Spoofhound: Spoofhound assegna a ogni dominio un voto da A a F sulla sicurezza del trasporto a partire dai suoi report TLS, ospita il tuo file di policy MTA-STS (certificato emesso e rinnovato per te) e avvisa sui modelli di errore con livelli di gravità.
Vedilo sul tuo dominio
Il controllo del dominio gratuito valuta la tua configurazione di SPF, DKIM, DMARC, MTA-STS, TLS-RPT e BIMI in pochi secondi — senza registrazione, senza agent, senza nulla da installare.
Com’è costruito Spoofhound
Cloud-first, dalle fondamenta.
La maggior parte degli strumenti di monitoraggio sono applicazioni tradizionali che si trovano a girare in un data center — macchine virtuali e container da dimensionare, aggiornare e pagare che qualcuno li usi o no. Spoofhound no. È stato costruito per il cloud dalle fondamenta: niente macchine virtuali, niente container, niente rack di server. Gira come codice serverless su una rete edge globale, vicino a ovunque arrivino i tuoi report.
Questa scelta si sente in tre punti che percepisci davvero. Scala con la domanda — una giornata che porta dieci volte il volume di report abituale è gestita come qualsiasi altra, senza capacità da provisionare. È separato per progettazione — ogni giurisdizione è un deployment autonomo con il proprio database e la propria regione, il che consente ai tuoi dati di restare nel paese che scegli invece che in un unico sistema condiviso con una colonna paese. E poiché a riposo costa quasi nulla, è il motivo per cui i nostri prezzi sono come sono: un prezzo per dominio basso con ogni funzione inclusa, invece di livelli di funzioni pensati per recuperare il costo di server che girano a vuoto.