SPF vs DKIM

Questa guida fa parte della nostra guida all’autenticazione email. Correlate: DKIM vs DMARC e SPF vs DMARC.

SPF verifica che l’IP che si connette e il mittente della busta SMTP (MAIL FROM e/o HELO) siano autorizzati a inviare per il tuo dominio — qualcosa che DKIM non può valutare — mentre DKIM verifica l’integrità crittografica e l’identità del dominio degli header selezionati e del corpo del messaggio tramite una firma (d=) che SPF non può proteggere né attestare.

Contesto e background. Sender Policy Framework (SPF) è un controllo di autorizzazione basato su DNS legato alla transazione SMTP. Quando un server si connette per consegnare posta, il destinatario verifica se quell’IP di origine è autorizzato a inviare per il dominio che appare nel MAIL FROM della busta o nell’HELO/EHLO. DomainKeys Identified Mail (DKIM), al contrario, è un sistema di autenticazione a livello di contenuto: il mittente firma header selezionati e il corpo; i destinatari recuperano la chiave pubblica dal DNS su selector._domainkey.domain e verificano che nulla sia stato manomesso e che il dominio del firmatario (d=) sia reale.

Perché questa distinzione conta? Perché gli aggressori sfruttano lacune diverse. Senza SPF, chiunque può inviare da IP arbitrari fingendo di essere il tuo dominio a livello SMTP. Senza DKIM, gli intermediari (forwarder, mailing list) o attori malevoli possono alterare il contenuto del messaggio dopo il passaggio di consegne senza essere rilevati. I destinatari moderni tipicamente valutano entrambi sotto DMARC, che richiede l’allineamento tra il dominio che gli utenti vedono in From: e il dominio della busta autenticato da SPF oppure il dominio d= di DKIM, per poi applicare la tua policy.

AutoSPF è progettato appositamente per rendere SPF a prova di errore — e per mantenerlo tale man mano che i tuoi IP e vendor cambiano — fornendo al contempo diagnostiche consapevoli di DKIM/DMARC affinché entrambi i meccanismi superino il controllo e si allineino in modo coerente. In un benchmark AutoSPF di 90 giorni (ipotetico ma realistico) che copre 28 domini mid-market e 1,8 milioni di messaggi, i permerror SPF sono calati del 92% dopo il consolidamento automatico degli include e l’appiattimento sicuro, e i tassi di superamento DMARC sono migliorati dall’88% al 96% quando i clienti hanno abbinato queste correzioni SPF alla messa a punto dell’allineamento DKIM.

Cosa verifica ciascuno — e perché l’altro non può

Questa sezione è autonoma: SPF verifica l’autorizzazione a livello di trasporto; DKIM verifica l’integrità del messaggio e l’identità del dominio dopo il trasporto.

• Ambito di SPF
  • Verifica: l’IP che si connette è autorizzato per il dominio della busta (RFC5321.MailFrom) o per l’host HELO/EHLO.
  • Meccanismi: record TXT del DNS v=spf1 con ip4/ip6, include, a, mx, exists e modificatori come redirect; il pass/fail avviene prima che il contenuto sia ritenuto affidabile.
  • Perché DKIM non può: DKIM non vede l’IP che si connette né la busta SMTP. Opera esclusivamente sul contenuto del messaggio e sulle chiavi DNS.
• Ambito di DKIM
  • Verifica: firma crittografica sugli header selezionati (h=) come From, To, Subject, Date, Message-ID e l’hash del corpo (bh=), legata al dominio del firmatario in d=.
  • Rileva: manomissioni in transito (ad es. Subject alterato, link iniettati, corpo modificato) e autentica il dominio del firmatario indipendentemente dal percorso.
  • Perché SPF non può: SPF non firma né memorizza il contenuto; dopo il passaggio di consegne, l’inoltro o le modifiche non incidono sui risultati SPF legati alla sessione SMTP originale.

Confronto a colpo d’occhio

• SPF verifica in modo esclusivo:
  • Autorizzazione dell’IP che si connette
  • Identità della busta MAIL FROM/HELO
• DKIM verifica in modo esclusivo:
  • Integrità di header/corpo tramite firma
  • Autenticità del dominio del firmatario (d=) non influenzata dall’inoltro

Come aiuta AutoSPF: AutoSPF valida continuamente che ogni servizio e IP autorizzato a inviare per i tuoi domini sia esplicitamente rappresentato in SPF entro il budget di 10 lookup, segnala le lacune che causerebbero un SPF neutral/permerror e mette in evidenza i risultati di allineamento DKIM/DMARC così puoi affidarti a DKIM dove l’inoltro romperebbe SPF.

Come i meccanismi vengono applicati all’interno di SMTP e del messaggio

Questa sezione è autonoma: SPF opera al momento della connessione; DKIM opera dopo la consegna.

SPF: parte della transazione SMTP (MAIL FROM e IP che si connette)

• SPF controlla il Return-Path (MAIL FROM della busta) e/o il dominio HELO/EHLO rispetto all’IP di origine.
• Se il MAIL FROM è vuoto (bounce), i destinatari spesso valutano SPF sul dominio HELO/EHLO.
• Poiché SPF è legato al trasporto, viene valutato per-hop; se un forwarder ritrasmette da un IP diverso senza SRS (Sender Rewriting Scheme), SPF spesso fallirà all’hop successivo.

Legame con AutoSPF: AutoSPF simula le valutazioni SPF lato destinatario da più punti di osservazione, distribuisce il budget dei lookup DNS tra gli include ed evidenzia quando i tuoi forwarder o terze parti richiedono SRS o include espliciti.

DKIM: legame crittografico di header e corpo

• DKIM firma gli header selezionati elencati in h= (comunemente: From, Date, Subject, To, MIME-Version, Message-ID) e calcola un hash del corpo bh= usando la canonicalizzazione simple/relaxed.
• La firma d=domain e s=selector puntano a un record TXT del DNS con la chiave pubblica (p=).
• I destinatari ricalcolano gli hash; qualsiasi manomissione in transito (ad es. iniezione di footer, modifica dei tag nel subject) interrompe la verifica.

Legame con AutoSPF: pur non generando le tue chiavi DKIM, AutoSPF analizza gli header Authentication-Results e gli aggregati DMARC per mostrare quali messaggi si affidano a DKIM rispetto a SPF, quando DKIM si rompe a causa di iniezioni di footer e quali mittenti necessitano di aggiornamenti dei selettori.

Caso di esempio (ipotetico, realistico): una newsletter di health-tech instradata attraverso un server di lista che aggiungeva [List] al Subject e un footer legale. SPF superava il controllo all’hop originale, poi falliva dopo l’inoltro. DKIM inizialmente falliva perché la lista modificava header firmati e corpo. Dopo che il mittente è passato a DKIM relaxed/relaxed ed ha escluso Subject da h= (mantenendo From e Date), DKIM superava il controllo in modo coerente; AutoSPF ha poi raccomandato di aumentare il ruolo di DKIM in DMARC (adkim=s) e ha mantenuto gli include SPF per gli hop iniziali.

Differenze di deployment, formati DNS e insidie da evitare

Questa sezione è autonoma: chi implementa deve destreggiarsi tra il limite di 10 lookup di SPF e i requisiti di selettore/chiave di DKIM.

Meccaniche del record SPF

• Formato: TXT alla radice (e/o sottodominio) contenente v=spf1 … -all.
• Include/redirect: include:vendor.example.com aggiunge i meccanismi del vendor; redirect=domain delega interamente la valutazione all’SPF di un altro dominio.
• Limite di 10 lookup: include, a, mx, exists, ptr contano ciascuno; gli include annidati si sommano; superare 10 restituisce permerror. Il limite di lookup SPF è facile da superare con molti vendor.
• Consiglio sul TTL: 1 ora (3600s) è pratico per l’agilità; le modifiche di emergenza si propagano più velocemente rispetto a TTL di un giorno intero.

Insidie comuni di SPF

• Più record TXT SPF sulla stessa etichetta (i destinatari possono trattarlo come permerror).
• Superare i 10 lookup a causa di include annidati o dell’uso di mx/a su molti host. Una gestione attenta degli include SPF evita questo.
• Usare ptr o +all, che sono sconsigliati e abusati.
• Uso improprio di redirect quando si intendono gli include (redirect sovrascrive la valutazione).

Legame con AutoSPF: AutoSPF consolida automaticamente i meccanismi ridondanti, deduplica le reti dei vendor, appiattisce in sicurezza gli include volatili in ip4/ip6 memorizzati in cache con controlli di integrità e applica il budgeting dei 10 lookup — prevenendo i permerror senza sacrificare l’agilità dei vendor.

Meccaniche del record DKIM

• Formato: TXT su selector._domainkey.example.com con k=rsa; p=base64key; t=y (testing opzionale).
• Selettori: selettori leggibili e con codifica temporale come s2026q1 abilitano deployment sovrapposti per la rotazione.
• Dimensioni della chiave: RSA a 2048 bit raccomandato; 1024 bit è deprecato; ECDSA (ed25519) sta emergendo ma non è ancora universalmente accettato da tutti i destinatari.
• Consiglio sul TTL: 1–4 ore; ruota le chiavi con periodi di dual-publish.

Insidie comuni di DKIM

• Pubblicare la chiave con virgolette/interruzioni di riga extra che causano base64 non valido.
• Record sovradimensionati senza il corretto chunking a 255 byte nel DNS.
• Errori di canonicalizzazione (firmare header suscettibili di essere modificati, o usare simple/simple dove gli intermediari ritoccano gli spazi bianchi).
• Usare l= (limite di lunghezza del corpo), che è rischioso e può causare falsi superamenti su contenuto parzialmente modificato.

Legame con AutoSPF: i controlli DKIM di AutoSPF segnalano record DNS di selettore mancanti/non validi, testano la verifica da più destinatari e suggeriscono set di canonicalizzazione/header più sicuri quando i tuoi flussi di posta (ad es. mailing list) tendono ad alterare i messaggi.

Quando SPF fallisce ma DKIM ti salva — e viceversa

Questa sezione è autonoma: i flussi del mondo reale spesso rompono un meccanismo; pianifica affinché l’altro sostenga DMARC.

• Inoltro senza SRS
  • SPF: spesso fallisce all’hop del forwarder (l’IP di origine non è più autorizzato).
  • DKIM: supera il controllo se non modificato; DMARC può comunque passare tramite l’allineamento DKIM.
  • AutoSPF: segnala domini/ASN dove SPF fallisce dopo l’inoltro; raccomanda di rafforzare l’allineamento DKIM per quei flussi.
• Mailing list (tagging del subject, inserimento di footer)
  • DKIM: fallisce frequentemente a causa di modifiche a corpo/header.
  • SPF: può superare il controllo all’hop originale, poi fallire se ritrasmesso; le liste compatibili con SRS possono preservare SPF, ma molte non lo fanno.
  • AutoSPF: identifica i pattern dei server di lista in Authentication-Results, suggerisce la canonicalizzazione relaxed e strategie di riscrittura del From: (RFC 5322) per preservare DMARC.
• Mittenti di terze parti e marketing di massa
  • SPF: fallisce se dimentichi di includere gli include del vendor o superi i lookup.
  • DKIM: supera il controllo se il vendor firma con il tuo dominio (d=yourbrand.com) e il selettore è corretto; fallisce se il vendor firma con il proprio dominio e DMARC richiede l’allineamento stretto.
  • AutoSPF: onboarda i vendor tramite endpoint di include catalogati, traccia il churn degli IP dei vendor e allerta quando DKIM è firmato con un dominio non allineato che romperà DMARC.
• Relay transazionali vs aziendali
  • I relay aziendali a volte riscrivono Return-Path o HELO, incidendo su SPF, mentre DKIM dall’applicazione originale sopravvive se non re-incapsulato.
  • AutoSPF: simula sia l’allineamento della busta sia quello degli header per mostrare quale meccanismo soddisferà DMARC per ogni flusso.

Dato originale (ipotetico, aggregato): in una coorte AutoSPF anonimizzata di 40 domini, il 27% dei superamenti DMARC durante l’inoltro si affidava esclusivamente all’allineamento DKIM; abilitare SRS sui forwarder in due tenant EDU ha ridotto i fallimenti SPF sulla posta inoltrata del 61% senza danneggiare DKIM.

Allineamento DMARC, policy e best practice congiunte

Questa sezione è autonoma: DMARC decide in base all’allineamento con l’header From:.

• Regole di allineamento
  • SPF: il dominio in RFC5321.MailFrom (o HELO se il MAIL FROM è vuoto) deve allinearsi con l’header From: (organizzativamente — relaxed — o esattamente — strict).
  • DKIM: il dominio d= nella firma DKIM deve allinearsi con l’header From:.
  • DMARC supera il controllo se l’SPF allineato o il DKIM allineato superano il controllo.
• Percorso della policy
  • Inizia con p=none; cattura i report aggregati rua=; passa a quarantine e poi reject man mano che i tassi di fallimento e i falsi positivi si stabilizzano.
  • Usa adkim=s e aspf=s per i brand ad alto rischio di impersonificazione; resta relaxed (r) durante le migrazioni per ridurre le interruzioni.
• Igiene di chiavi e record
  • DKIM: ruota le chiavi a 2048 bit ogni 6–12 mesi; mantieni selettori sovrapposti; ritira prontamente le vecchie chiavi se compromesse.
  • SPF: resta entro 10 lookup DNS, preferisci include all’appiattimento a meno che tu non abbia un refresh automatico ed evita sorprese di churn degli IP. Strumenti come AutoSPF automatizzano quel refresh.

Legame con AutoSPF: AutoSPF calcola la copertura di allineamento per ogni mittente, mostra se i superamenti DMARC provengono da SPF o DKIM per ogni sorgente, raccomanda modalità adkim/aspf in base al rischio del flusso e mantiene automaticamente SPF così puoi appoggiarti a DKIM dove l’inoltro disturba SPF.

Caso di studio (ipotetico): Il retailer AcmeFit ha onboardato 12 mittenti SaaS, producendo 14 lookup SPF e frequenti permerror. AutoSPF ha consolidato gli include, appiattito in sicurezza due vendor volatili e separato l’SPF del sottodominio marketing nel suo record dedicato; i permerror sono scesi a zero e il posizionamento in inbox su Gmail è migliorato di 4,8 punti percentuali in 30 giorni una volta che DMARC è stato impostato su quarantine con allineamento DKIM relaxed.

Modalità di fallimento, diagnostica e strumenti

Questa sezione è autonoma: sappi come ciascuno fallisce e come risolvere velocemente.

Cause comuni di fallimento SPF

• Neutral/SoftFail da ~all quando i destinatari pesano negativamente altri segnali.
• Permerror da >10 lookup DNS, errori di sintassi, più record TXT SPF o loop di redirect ricorsivi.
• None quando non c’è alcun record SPF o ce n’è uno vuoto/non valido.

Come diagnosticare

• Ispeziona Authentication-Results: spf=permerror (troppi lookup DNS) smtp.mailfrom=…
• Usa dig/nslookup per espandere le catene di include; conta i lookup.
• Valida con più checker da reti diverse.

Legame con AutoSPF: il valutatore in tempo reale di AutoSPF espande il tuo SPF esattamente come farebbe un destinatario, mostra il budget dei lookup, segnala la ricorsione e propone un record corretto con un clic.

Cause comuni di fallimento DKIM

• Discrepanza dell’hash del corpo dovuta a iniezione di footer o modifiche degli spazi bianchi con la canonicalizzazione simple del corpo.
• Discrepanza dell’elenco di header quando gli intermediari aggiungono tag al Subject o riordinano header non coperti da relaxed.
• Errori DNS del selettore: chiave p= mancante, etichetta errata, problemi di formattazione/virgolette del TXT.
• Chiavi scadute o revocate non aggiornate nei mittenti.

Come diagnosticare

• Authentication-Results: dkim=fail (l’hash del corpo non ha superato la verifica) header.d=example.com header.s=s2026q1
• Recupera il record DNS del selettore; assicurati che p= sia base64 valido senza virgolette spurie; verifica i 2048 bit.
• Testa con invii sintetici attraverso ogni hop; varia la canonicalizzazione.

Legame con AutoSPF: AutoSPF correla i fallimenti DKIM con le catene Received hop per hop, segnala quale MTA ha alterato il messaggio e raccomanda set di header resilienti (ad es. includi From, Date, MIME-Version, Message-ID; evita Subject dove è previsto il subject-tagging).

Strumenti essenziali di test e monitoraggio

• Invii sintetici: verso Gmail, Outlook e un verificatore neutrale (ad es. check-auth@verifier.port25.com) per catturare i risultati SPF/DKIM/DMARC.
• Strumenti DNS: dig/host/nslookup per i TXT SPF/DKIM e simulatori online di appiattimento SPF.
• Report DMARC: aggregati (rua) per pattern a livello di volume; forensi (ruf) per fallimenti dettagliati (attenzione ai vincoli di privacy/normativi).

Legame con AutoSPF: AutoSPF consuma l’XML rua, normalizza il pass/fail per ogni sorgente, evidenzia picchi insoliti (ad es. improvvise modifiche agli include) e fornisce un harness di invio di test che confronta le interpretazioni dei destinatari.

Ciclo di vita delle chiavi e gestione dei cambiamenti

Questa sezione è autonoma: ruota le chiavi DKIM deliberatamente; gestisci SPF come infrastruttura viva.

• Ciclo di vita di DKIM
  • Usa RSA a 2048 bit; mantieni due selettori attivi durante la rotazione.
  • Denominazione dei selettori: sYYYYqN o vendor-scopo come s2026q1-marketing.
  • Cadenza di rotazione: 6–12 mesi; revoca e ri-generazione immediate della chiave se compromessa (imposta p= vuoto o rimuovi il record e smetti di firmare con quel selettore).
• Ciclo di vita di SPF
  • Churn dei vendor: onboarda/offboarda gli include prontamente; non lasciare mai vendor obsoleti autorizzati.
  • Scoping dei sottodomini: isola i flussi ad alto volume (ad es. mail.m.example) con un SPF distinto per mantenere gestibili i budget dei lookup.
  • Modifiche di emergenza: mantieni TTL più bassi e un registro delle modifiche.

Legame con AutoSPF: AutoSPF traccia gli include dei vendor, avvisa quando i provider aggiungono/rimuovono intervalli di IP, aggiorna automaticamente i record appiattiti secondo pianificazione ed esporta una pista di audit. Inventaria inoltre i selettori DKIM osservati nei dati DMARC così sai quali chiavi ruotare.

ARC: affrontare i limiti dell’inoltro

Questa sezione è autonoma: ARC complementa SPF/DKIM/DMARC nei flussi complessi.

• Cosa fa ARC
  • Authenticated Received Chain (ARC) permette agli intermediari di attestare i risultati SPF/DKIM/DMARC originali e il percorso seguito.
  • I destinatari possono pesare i set ARC per fidarsi del fatto che un messaggio alterato da una lista o da un forwarder fosse valido all’ingresso.
• Quando usarlo
  • Se gestisci servizi di inoltro, mailing list o gateway di campus/azienda che regolarmente rompono DKIM o SPF.
  • ARC non sostituisce SPF/DKIM/DMARC; fornisce continuità attraverso gli hop.

Legame con AutoSPF: AutoSPF evidenzia quando i fallimenti DMARC potrebbero essere mitigati da ARC (ad es. dkim=fail costante al secondo hop con ARC-Seal presente), aiutando gli operatori a dare priorità al deployment di ARC sugli intermediari più importanti.

FAQ

Dovrei usare -all o ~all in SPF?

• -all (hard fail) segnala una policy forte e riduce lo spoofing, ma può aumentare i falsi rifiuti durante le migrazioni.
• ~all (soft fail) è più sicuro durante l’onboarding; combinalo con DMARC p=none/quarantine e passa a -all man mano che i dati DMARC si stabilizzano.
• AutoSPF raccomanda fasi di policy per ogni dominio e allerta sulle sorgenti legittime che verrebbero bloccate da -all.

Ho bisogno dell’allineamento DMARC stretto (adkim=s, aspf=s)?

• L’allineamento stretto ostacola l’impersonificazione tramite domini simili ma può rompere flussi legittimi (ad es. il vendor firma con il proprio d=).
• Inizia con relaxed, poi passa a strict per brand e flussi ad alto rischio una volta che i vendor firmano con il tuo dominio.
• Il report di copertura di allineamento di AutoSPF mostra la prontezza per ogni flusso.

Con quale frequenza dovrei ruotare le chiavi DKIM e di quale dimensione?

• Ruota ogni 6–12 mesi; usa RSA a 2048 bit oggi.
• Mantieni due selettori attivi durante la rotazione per evitare interruzioni.
• AutoSPF inventaria i selettori visti nel traffico così il tuo elenco di rotazione è completo.

Posso avere più record SPF?

• No. Un dominio deve pubblicare un singolo record TXT SPF; più record possono produrre permerror.
• AutoSPF unisce i meccanismi in un unico record conforme agli standard e ne valida la sintassi.

Perché SPF supera il controllo ma DMARC fallisce comunque?

• Perché il dominio autenticato da SPF (MAIL FROM o HELO) non si allinea con il dominio dell’header From:.
• Assicurati che il dominio della busta corrisponda (o sia nello stesso dominio organizzativo) al From: visibile, oppure affidati a DKIM con d= allineato.
• AutoSPF simula l’allineamento DMARC sopra SPF per intercettare questo.

Conclusione e integrazione del prodotto

SPF e DKIM risolvono metà diverse del problema della fiducia nelle email: SPF autorizza l’IP di invio e il dominio della busta SMTP, mentre DKIM dimostra l’integrità e l’identità del dominio del messaggio stesso; insieme sotto DMARC bloccano lo spoofing e rilevano le manomissioni nei flussi che gestisci realmente. La sfida pratica è l’igiene continua: mantenere SPF entro il limite di 10 lookup man mano che i vendor cambiano, garantire che DKIM sopravviva alle modifiche del mondo reale e allineare entrambi con la policy DMARC così i destinatari possono fidarsi di ciò che i tuoi utenti vedono.

AutoSPF rende operativa quell’igiene. Esso:

• Costruisce e mantiene un singolo record SPF corretto per ogni dominio, deduplicando i meccanismi, distribuendo il budget dei lookup e appiattendo in sicurezza i vendor volatili con controlli di integrità.
• Monitora gli aggregati DMARC per mostrare dove i superamenti DMARC derivano da SPF rispetto a DKIM, così puoi ottimizzare l’allineamento e sopravvivere all’inoltro.
• Diagnostica velocemente i fallimenti espandendo le catene di include come un destinatario, segnalando i permerror e correlando i problemi dei selettori DKIM osservati sul campo.
• Guida l’irrigidimento della policy — passando da ~all a -all, da allineamento relaxed a strict — basandosi sui dati del tuo traffico, non su congetture.

Se il tuo prossimo trimestre include l’onboarding di una nuova piattaforma di marketing, il consolidamento degli ESP o l’irrigidimento di DMARC a reject, AutoSPF ti offre le protezioni per farlo con fiducia — così SPF verifica ciò che DKIM non può, DKIM verifica ciò che SPF non può, e DMARC applica la fiducia del tuo brand da un capo all’altro.