DMARC p=none quarantine reject definiscono la policy richiesta ai destinatari quando un messaggio non supera l’allineamento DMARC. `none` monitora, `quarantine` suggerisce trattamento sospetto e `reject` richiede il rifiuto.
Questa guida approfondisce DMARC p=none quarantine reject con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.
Che cosa significa
DMARC passa quando almeno SPF o DKIM è valido e allineato con il dominio visibile nel From. Non basta che SPF o DKIM risultino pass su un dominio differente.
Una policy restrittiva deve essere introdotta dopo aver inventariato tutti i mittenti: hosting, newsletter, CRM, e-commerce, ticket, gestionali e servizi esterni.
Come riconoscere il problema
- I report mostrano sorgenti sconosciute.
- Messaggi legittimi falliscono allineamento.
- Con p=reject alcuni servizi non consegnano.
- SPF passa ma usa un Return-Path non allineato.
- DKIM firma con il dominio del provider.
Cause più frequenti
1. Mittenti non inventariati
Un servizio legittimo non è configurato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
2. SPF non allineato
Il dominio envelope sender differisce dal From. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
3. DKIM non allineato
Il parametro d= non corrisponde al dominio organizzativo previsto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
4. Forwarding
Può rompere SPF mentre DKIM può sopravvivere. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
5. Record DMARC duplicato o errato
La policy non viene interpretata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
6. Passaggio immediato a reject
Non esiste una fase di monitoraggio. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
Diagnosi passo per passo
- Pubblica p=none e rua. Raccogli report aggregati. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Inventaria le sorgenti. Associa IP e domini a servizi reali. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Leggi Authentication-Results. Controlla SPF, DKIM e allineamento. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Verifica il record `_dmarc`. Deve essere unico e sintatticamente valido. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Analizza sottodomini. Decidi se usare `sp=`. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla mailing list e forwarding. Valuta ARC e DKIM. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Classifica traffico sconosciuto. Distingui spoofing e sistemi dimenticati. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
Metodo sicuro di diagnosi
Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.
Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.
Verifica prolungata dopo la correzione
Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.
Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.
Procedura di risoluzione
- Configura SPF e DKIM dei servizi. Preferisci DKIM allineato per piattaforme esterne. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Mantieni un solo record DMARC. Correggi tag e indirizzi report. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Passa gradualmente a quarantine. Usa `pct=` se appropriato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Monitora l’impatto. Controlla report e rimbalzi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Adotta reject dopo la copertura. Quando i mittenti legittimi sono allineati. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Definisci policy sottodomini. Con `sp=` secondo l’uso reale. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Proteggi le caselle rua. Gestisci volume e dati dei report. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Come raccogliere prove utili
Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.
Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.
Controlli finali
- Record DMARC valido.
- Mittenti legittimi allineati.
- Report ricevuti.
- Spoofing ridotto.
- Policy applicata gradualmente.
Prevenzione
- Inventario mittenti.
- Report continui.
- DKIM allineato.
- Revisione periodica.
- Policy documentata.
Errori da evitare
- Non passare a reject senza dati.
- Non creare due record DMARC.
- Non pubblicare indirizzi personali nei report se non gestiti.
- Non confondere pass e allineamento.
- Non ignorare servizi transazionali.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- dominio From
- record DMARC
- header di esempio
- servizi di invio
- report o errore
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Domande frequenti su DMARC p=none quarantine reject
p=none protegge dai messaggi falsi?
Monitora e genera report, ma non richiede quarantena o rifiuto.
DMARC richiede sia SPF sia DKIM?
No, è sufficiente che almeno uno passi e sia allineato.
Che cosa fa pct?
Indica la percentuale di messaggi ai quali applicare la policy richiesta.
Posso passare direttamente a reject?
È rischioso senza inventario e monitoraggio dei mittenti legittimi.
SPF pass garantisce DMARC pass?
No, il dominio SPF deve anche essere allineato con il From.