Email e domini
Verifica SPF
Copertura: Funziona con domini di qualsiasi paese. Leggiamo il record come fanno i server di ricezione (RFC 7208): i suoi meccanismi, come termina, ogni include e redirect fino a 30 ricerche, e il numero di ricerche DNS rispetto al limite di 10.
Apri lo strumentoIn questa pagina
A cosa serve
Controlla il record SPF di un dominio: quali server possono inviare email a suo nome, cosa succede al resto («-all», «~all») e le ricerche DNS (max 10).
Requisiti
Chiunque può leggere queste guide, senza account. Alcuni strumenti richiedono Pro, come indicato in ogni guida.
SPF è il record DNS in cui un dominio elenca i server autorizzati a inviare la sua posta. Senza, o con uno difettoso o troppo permissivo, è più facile inviare email false a nome di quel dominio. Inserisci un dominio, un indirizzo email o un link e leggiamo il suo SPF per spiegartelo.
Come usarlo
Scrivi il dominio che vuoi controllare, oppure incolla un indirizzo email o un link: usiamo solo il suo dominio.
Premi «Verifica SPF». Leggiamo il record SPF e seguiamo ogni include, come farebbe un server di ricezione.
Guarda come termina il record e il numero di ricerche: quello che vuoi vedere è «-all» o «~all» e 10 ricerche o meno.
Esempio inventato
Esempio inventato, non una ricerca reale. Non chiamare e non aprire i suoi link.
v=spf1 include:_spf.example.com ~allInterpretare il risultato
Questo dominio non ha SPF: Non dice quali server possono inviare la sua posta, quindi è più facile spacciarsi per lui. Se è il tuo dominio, pubblica un record SPF.
Il record SPF ha degli errori: I server di ricezione non possono applicarlo, quindi per loro il dominio non ha SPF. I segnali qui sotto dicono cosa non va.
Chiunque può inviare email a nome di questo dominio: Il record termina con «+all», che autorizza qualsiasi server al mondo. Configurato così, SPF non protegge nulla.
L’SPF non protegge del tutto il dominio: Il record non dice cosa fare con i server che non sono nella sua lista, quindi le email false a nome del dominio non vengono segnalate.
L’SPF è configurato correttamente: Il dominio elenca i server che possono inviare la sua posta e chiede di segnalare o rifiutare il resto. SPF da solo non ferma l’impersonificazione: è DMARC a dire ai server di ricezione cosa fare.
+all: qualsiasi server può inviare (pericoloso)
?all: il record non dice nulla su di loro
~all: segnalati come sospetti
-all: rifiutati
Nessun «all»: il record non dice nulla su di loro
Limiti
Leggiamo i record DNS pubblici del dominio. Se inserisci un indirizzo email o un link, dal tuo browser esce solo il suo dominio. Non salviamo il dominio che cerchi.
Risoluzione dei problemi
Non sembra un dominio pubblico. Prova con qualcosa come example.com.
Il DNS non ha risposto in tempo. Riprova tra qualche secondo.
Hai fatto molti controlli di fila. Aspetta un minuto e riprova.
Usare con l’API
Richiede una API key e dei crediti. Ogni chiamata completata costa 1 credito, anche quando non ci sono dati. Un account Pro attivo include 20 crediti per mese solare UTC, condivisi da tutte le rotte API e consumati per primi; i crediti mensili non usati non passano al mese successivo. I crediti acquistati nella pagina del tuo account funzionano senza Pro e non scadono mai.
Gli errori non vengono mai addebitati: 401 invalid_api_key (chiave mancante o non valida), 403 pro_required (nessun credito Pro e nessun credito acquistato), 422 input non valido, 429 quota_exceeded (crediti esauriti), rate_limit_exceeded o ai_busy (l’IA di sms-check è al limite della capacità), 503 tool_warming (i dati sono ancora in preparazione) o tool o provider non disponibile. Dopo un 429 o un 503, riprova quando sono trascorsi i secondi indicati nell’intestazione Retry-After.
Legge il record SPF di un dominio come i server di ricezione (RFC 7208): i suoi termini, come termina, le ricerche DNS dell’intero albero di include rispetto al limite di 10, ogni include e se pubblica SPF, e i problemi del record come segnali. Non viene salvato nulla.
Invia il corpo JSON alla rotta specifica del tool, oppure a POST /v2/tools aggiungendo il campo tool. Entrambe le rotte restituiscono lo stesso risultato.
POST https://api.nocall.io/v2/spf-check
POST https://api.nocall.io/v2/tools {"tool":"spf-check","domain":"example.com"}Parametri
| Nome | Tipo | Obbligatorio | Descrizione |
|---|---|---|---|
| domain | string (1–320) | Sì | Un dominio, oppure un indirizzo email o un link di cui si usa il dominio, fino a 320 caratteri. Solo nomi pubblici: indirizzi IP, nomi con una sola etichetta e nomi a uso speciale (.local, .internal, .test…) danno un 422. |
REQUEST_ID="$(uuidgen)" && [ -n "$REQUEST_ID" ] &&
curl --request POST 'https://api.nocall.io/v2/spf-check' \
--header "Authorization: Bearer $NOCALL_API_KEY" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $REQUEST_ID" \
--data '{"domain":"example.com"}'import json
import os
import urllib.request
import uuid
api_key = os.environ.get('NOCALL_API_KEY')
if not api_key:
raise SystemExit('Set NOCALL_API_KEY')
request = urllib.request.Request(
'https://api.nocall.io/v2/spf-check',
method='POST',
data=json.dumps({'domain': 'example.com'}).encode(),
headers={
'Authorization': 'Bearer ' + api_key,
'Content-Type': 'application/json',
'Idempotency-Key': str(uuid.uuid4()),
},
)
with urllib.request.urlopen(request, timeout=30) as response:
result = json.load(response)
print(result['data']['result'], result['meta']['unitsCharged'])import { randomUUID } from 'node:crypto';
const requestId = randomUUID();
const apiKey = process.env.NOCALL_API_KEY;
if (!apiKey) throw new Error('Set NOCALL_API_KEY');
const response = await fetch('https://api.nocall.io/v2/spf-check', {
method: 'POST',
headers: {
Authorization: 'Bearer ' + apiKey,
'Content-Type': 'application/json',
'Idempotency-Key': requestId,
},
body: JSON.stringify({ domain: 'example.com' }),
});
const result = await response.json();
if (!response.ok) throw new Error(result.error?.code ?? 'request_failed');
console.log(result.data.result, result.meta.unitsCharged);Esempio di risposta (200)
Questo è l’esempio documentato nel riferimento API. Le ricerche usano un numero fittizio, mentre aggregati e risposte dell’IA mostrano la struttura del risultato, non dati reali.
{
"data": {
"tool": "spf-check",
"result": {
"domain": "example.com",
"domainAscii": "example.com",
"found": true,
"record": "v=spf1 include:_spf.google.com ~all",
"recordCount": 1,
"terms": [
{
"qualifier": "pass",
"mechanism": "include",
"value": "_spf.google.com"
},
{
"qualifier": "softfail",
"mechanism": "all",
"value": null
}
],
"allResult": "softfail",
"lookups": 1,
"includes": [
{
"domain": "_spf.google.com",
"found": true
}
],
"signals": [
"softfail_all"
],
"valid": true,
"attention": false
}
},
"meta": {
"requestId": "req_example",
"unitsCharged": 1,
"usage": {
"periodStart": "2026-10-01",
"unitLimit": 20,
"unitsUsed": 3,
"unitsRemaining": 17
}
}
}Campi del risultato (data.result)
| Campo | Tipo | Descrizione |
|---|---|---|
| domain | string | Il dominio in Unicode. |
| domainAscii | string | Lo stesso dominio in ASCII (punycode), come lo vede il DNS. |
| found | boolean | Se il dominio pubblica un record SPF. |
| record | string | null | Il record SPF così come è pubblicato; null se non ce n’è nessuno o ce n’è più di uno. |
| recordCount | integer | Quanti record SPF pubblica il dominio; più di uno è un errore. |
| terms | array<object> | I meccanismi e i modificatori del record in ordine, ciascuno con il suo qualificatore (pass, fail, softfail o neutral; null per redirect ed exp) e il suo valore. |
| allResult | "pass" | "fail" | "softfail" | "neutral" | null | Come termina il record (il suo all, o quello della destinazione del suo redirect): pass, fail, softfail o neutral; null se non ce l’ha. |
| lookups | integer | Meccanismi e modificatori che interrogano il DNS, nell’intero albero di include. I server di ricezione si fermano oltre 10 (permerror). |
| includes | array<object> | Ogni destinazione di include e redirect nell’ordine di lettura, e se pubblica SPF. |
| signals | array<string (enum, 12)> | no_spf, multiple_records, syntax_error, too_many_lookups, include_not_found, include_loop, plus_all, neutral_all, softfail_all, no_all, ptr_mechanism o macros. |
| valid | boolean | Se un server di ricezione può valutare il record: un solo record, nessun errore di sintassi, al massimo 10 ricerche, ogni include trovato e nessun ciclo. |
| attention | boolean | Se il risultato merita un controllo: nessun SPF, un record non valido, o uno che termina con +all, ?all o senza all. |
Domande frequenti
Che cos’è SPF?
Sender Policy Framework: un record DNS in cui un dominio elenca i server autorizzati a inviare la sua posta. Il server che riceve un messaggio controlla se il server che glielo ha consegnato è in quella lista.
Cos’è meglio, «-all» o «~all»?
«-all» chiede ai server di ricezione di rifiutare la posta dei server che non sono in elenco; «~all» chiede di segnalarla come sospetta. Entrambi proteggono, e molti domini usano «~all» e lasciano decidere a DMARC cosa fare. «+all» e «?all» non proteggono.
Perché conta il limite di 10 ricerche?
Ogni include, a, mx, ptr, exists e redirect costringe il server di ricezione a interrogare il DNS. Se il record intero ne richiede più di 10, viene trattato come un errore e SPF smette di funzionare. Elimina i servizi che non usi più o chiedi al tuo provider un include più semplice.
SPF da solo ferma le email false?
No. SPF controlla il mittente nascosto della busta, non l’indirizzo che vedi in «Da». È DMARC a collegare i due e a chiedere ai server di ricezione di mettere in quarantena o rifiutare la posta che non supera i controlli. Controlla anche il DMARC del dominio.
