Passa al contenuto principale

10. Effects on Infrastructure (Effetti sull'infrastruttura)

L'implementazione di SPF può avere vari impatti sull'infrastruttura di posta elettronica e DNS. Gli amministratori dovrebbero essere consapevoli di questi potenziali impatti.

10.1 DNS Server Load (Carico del server DNS)​

Le verifiche SPF richiedono query DNS aggiuntive, il che può aumentare il carico sui server DNS. Per ogni messaggio di posta elettronica in arrivo, il destinatario deve:

  • Interrogare il record SPF del dominio mittente
  • Eseguire ricerche DNS aggiuntive per i meccanismi (A, MX, PTR, EXISTS, INCLUDE)
  • Eseguire query ricorsive per i meccanismi include:

Mitigation (Mitigazione)​

  • Caching DNS: Uso appropriato dei valori TTL per minimizzare le query ridondanti
  • Limiti di ricerca: SPF limita il numero di ricerche DNS a 10 per prevenire un carico eccessivo
  • Progettazione efficiente dei record SPF: Minimizzazione del numero di meccanismi e include

10.2 Large Volume Mailing (Invio di grandi volumi)​

Le organizzazioni che inviano grandi volumi di messaggi di posta elettronica dovrebbero assicurarsi che i loro record SPF:

  • Coprano tutti gli indirizzi IP di invio autorizzati: Inclusione di tutti i server di posta legittimi, terze parti e servizi cloud
  • Siano correttamente strutturati: Evitare PermError o troppe ricerche DNS
  • Siano regolarmente aggiornati: Quando l'infrastruttura di invio cambia

Third-Party Senders (Mittenti di terze parti)​

Le organizzazioni che utilizzano servizi di posta elettronica di terze parti (ad esempio, piattaforme di marketing, servizi cloud) devono autorizzare questi servizi nei loro record SPF:

v=spf1 include:_spf.example.com include:_spf.thirdparty.com -all

10.3 Email Forwarding (Inoltro di posta elettronica)​

SPF può causare problemi con gli scenari di inoltro di posta elettronica:

Problema: Quando un destinatario inoltra un messaggio di posta elettronica a un altro destinatario, l'indirizzo IP di invio cambia (ora il server di inoltro), ma l'indirizzo MAIL FROM rimane l'originale. Ciò porta a fallimenti SPF.

Solutions (Soluzioni)​

  • SRS (Sender Rewriting Scheme): Riscrittura dell'indirizzo MAIL FROM durante l'inoltro
  • SPF Neutral o SoftFail: Utilizzo di ~all invece di -all per ridurre l'impatto
  • Integrazione DMARC: Utilizzo di DMARC con DKIM per gestire gli scenari di inoltro

10.4 Mailing Lists (Liste di distribuzione)​

Le liste di distribuzione affrontano sfide simili all'inoltro di posta elettronica:

  • Il server della lista di distribuzione inoltra messaggi da un mittente originale a molti abbonati
  • L'indirizzo MAIL FROM rimane spesso quello del mittente originale, ma l'IP di invio è il server della lista di distribuzione

Best Practices (Migliori pratiche)​

  • Riscrittura MAIL FROM: Il software della lista di distribuzione dovrebbe riscrivere l'indirizzo MAIL FROM nel dominio della lista di distribuzione
  • Firma DKIM: Le liste di distribuzione dovrebbero aggiungere le proprie firme DKIM
  • Intestazione List-ID: Utilizzo di List-ID e altre intestazioni per identificare l'origine della lista di distribuzione

10.5 IPv6 Considerations (Considerazioni IPv6)​

SPF supporta sia IPv4 che IPv6. Gli amministratori dovrebbero:

  • Includere meccanismi ip6: Se l'infrastruttura di invio supporta IPv6
v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 -all
  • Mantenere voci doppie: Assicurarsi che sia gli intervalli IPv4 che IPv6 siano coperti
  • Record DNS AAAA: Assicurarsi che i meccanismi A e MX risolvano correttamente gli indirizzi IPv6

10.6 Subdomain Policies (Policy per i sottodomini)​

Per impostazione predefinita, i sottodomini non ereditano i record SPF dal loro dominio genitore. Ogni sottodominio che invia messaggi di posta elettronica ha bisogno del proprio record SPF, oppure il dominio genitore dovrebbe pubblicare un record wildcard:

*.example.com. IN TXT "v=spf1 -all"

Questo impedisce agli aggressori di utilizzare sottodomini inesistenti per lo spoofing.

Ultimo aggiornamento il