Questo strumento gira sul server
Come funziona
Il protocollo di posta non verifica chi invia: qualsiasi server può mettere il tuo dominio come mittente. Tre record DNS chiudono questa porta. SPF elenca i server che possono inviare a nome del dominio. DKIM firma ogni messaggio con una chiave privata la cui parte pubblica è pubblicata nel DNS. DMARC unisce i due: richiede che almeno uno superi la verifica e coincida con il dominio visibile del mittente, dice al destinatario cosa fare con ciò che fallisce e chiede report su tutto ciò che è stato inviato a tuo nome.
Da febbraio 2024 Gmail e Yahoo richiedono SPF, DKIM e DMARC a chi invia più di 5.000 messaggi al giorno ai loro utenti, e la mancanza di uno qualsiasi si traduce in email rifiutate o nella cartella spam. Per questo conviene controllarli insieme: un SPF impeccabile serve a poco senza DMARC, e un DMARC in reject con un DKIM pubblicato male blocca la tua stessa posta.
La verifica si esegue dal nostro server con query DNS pubbliche, come farebbe qualsiasi server di posta. L'SPF viene valutato per intero, seguendo ogni include e redirect per contare le query DNS, perché superare il limite di 10 annulla l'intero record. Vengono interrogati anche i record MX e quelli facoltativi MTA-STS, TLS-RPT e BIMI.
Esempi
github.comSPF · 10 / 10Otto include di provider (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) e quelli che a loro volta includono portano la valutazione esattamente al limite di 10 query DNS. Un provider in più e l'intero SPF darebbe errore permanente.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sLa configurazione corretta per un dominio che non invia né riceve posta: MX nullo, SPF che non autorizza nessuno e DMARC in reject. Protegge i domini parcheggiati, un bersaglio comune dello spoofing.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Un rilascio graduale: solo un messaggio su quattro tra quelli che falliscono va nello spam, e i report arrivano alla casella indicata in rua per individuare mittenti legittimi non ancora autenticati.Casi d'uso
- Capire perché le email del dominio finiscono nello spam o vengono rifiutate da Gmail, Outlook o Yahoo.
- Verificare che l'SPF non superi le 10 query DNS prima di aggiungere un nuovo provider di invio, come un CRM o una piattaforma di newsletter.
- Verificare che la chiave DKIM di un provider sia stata pubblicata correttamente dopo la configurazione.
- Pianificare il passaggio di DMARC da none a quarantine e a reject senza bloccare la posta legittima.
- Controllare i domini di un cliente o di un'azienda acquisita, compresi quelli parcheggiati che non dovrebbero inviare posta.
- Controllare la configurazione di un mittente sospetto durante l'analisi di un phishing.
Domande frequenti
Perché dice che non ha trovato DKIM se il mio dominio firma le email?
Perché DKIM non consente di elencare le chiavi di un dominio: ognuna si trova in <selettore>._domainkey.<dominio> e bisogna conoscere il selettore per interrogarla. Lo strumento prova i selettori più usati, ma molti provider usano nomi propri o con data. Apri un'email inviata dal dominio, cerca l'intestazione DKIM-Signature e copia il valore di s=; con quel selettore la verifica è esatta.
Cosa succede se l'SPF supera le 10 query DNS?
La RFC 7208 obbliga il destinatario a restituire un errore permanente (permerror), e per DMARC ciò equivale a un fallimento di SPF. Consumano query i meccanismi include, a, mx, ptr ed exists e il modificatore redirect, compresi quelli presenti in ogni include; ip4 e ip6 non ne consumano. Per ridurre il numero si tolgono i provider non più usati, si sostituiscono gli include con intervalli ip4 o si invia da sottodomini con un proprio SPF.
~all o -all?
Con DMARC attivo la differenza è minima: il destinatario applica la policy DMARC e non il qualificatore SPF. ~all è la norma perché alcuni destinatari rifiutano subito con -all prima di valutare DKIM, e così si può perdere posta inoltrata che DKIM avrebbe salvato. Senza DMARC, -all è l'unico modo per chiedere che ciò che non è autorizzato venga rifiutato.
Come passo DMARC da none a reject senza perdere posta?
Parti da p=none con un indirizzo in rua e leggi i report aggregati per qualche settimana: mostrano ogni server che invia con il tuo dominio e se supera SPF o DKIM. Autentica i mittenti legittimi mancanti, passa a quarantine con un pct basso, aumenta pct gradualmente e arriva a reject. Il salto diretto a reject di solito blocca sistemi di fatturazione, CRM o sistemi interni di cui nessuno si ricordava.
Basta una chiave DKIM a 1024 bit?
Funziona, perché la RFC 8301 obbliga i destinatari ad accettare chiavi da 1024 a 4096 bit, ma la stessa norma raccomanda a chi firma di usarne almeno 2048. Le chiavi sotto i 1024 bit non sono considerate valide. Passare a 2048 è semplice: si pubblica la nuova chiave con un altro selettore, si cambia la firma e poi si revoca la vecchia lasciando p vuoto.
A cosa servono MTA-STS, TLS-RPT e BIMI?
MTA-STS (RFC 8461) chiede ai server mittenti di pretendere TLS quando consegnano ai tuoi MX, evitando attacchi che declassano la connessione a testo in chiaro. TLS-RPT (RFC 8460) ti invia report quando quelle consegne falliscono. BIMI mostra il logo del marchio accanto al mittente nei client che lo supportano, e funziona solo con DMARC in quarantine o reject. Nessuno è obbligatorio, ma tutti e tre aiutano.