DMARC RUA indica nel record DMARC le destinazioni richieste per i rapporti aggregati. Senza questo campo, la politica può esistere, ma perdi una fonte di informazioni su autenticazione e allineamento. I rapporti sono parziali e non provano da soli identità delle origini o falsificazione. Per le basi, inizia dalla posta aziendale per piccole imprese.
Un CRM mal configurato, un'estensione WordPress dimenticata o un inoltro che influenza SPF possono complicare la diagnosi. RUA fornisce dati per indagare, senza spiegare da solo tutte le decisioni di filtraggio di Gmail.
Questa guida spiega RUA, pubblicazione, contenuto XML e priorità delle correzioni.
Cos'è DMARC RUA?
RUA è il campo di destinazione dei rapporti aggregati di autenticazione. Riassumono SPF, DKIM, allineamento, IP sorgente e disposizione per un periodo, spesso giornaliero, sul traffico dei destinatari partecipanti.
In DMARC, rua=mailto:... richiede l'invio dei rapporti aggregati alla destinazione. Secondo la RFC 7489, rua definisce dove inviare dati di autenticazione, allineamento, domini, volume e politica applicata.
Osservare il traffico aiuta a valutare p=none, p=quarantine o p=reject. RUA fornisce indizi, senza dimostrare che tutti i mittenti legittimi siano pronti per una politica restrittiva.
Cosa mostrano i rapporti RUA
Sono riepiloghi aggregati, non copie dei messaggi. Mostrano origini osservate, autenticazione SPF/DKIM e allineamento DMARC. Distingui risultati grezzi da quelli valutati per la politica, che incorporano l'allineamento.
Non ricevi i corpi dei messaggi, ma dati per indagare errori dei fornitori, allineamento e possibili abusi. Completa con inventario e test.
| Tag | Funzione | Dati | Uso comune |
|---|---|---|---|
rua | Richiede rapporti aggregati | Riepiloghi XML per IP e autenticazione | Monitoraggio e valutazione delle politiche |
ruf | Richiede rapporti di errore | Campioni di messaggi quando disponibili | Diagnosi mirata |
Inizia da RUA e considera ruf per esigenze precise. I rapporti forensi hanno supporto irregolare e pongono maggiori questioni di riservatezza.
Esempio: il dominio invia tramite Google Workspace, un'applicazione di fatturazione e supporto. RUA può mostrare origini osservate di questi servizi, senza garantire che appaiano tutti. Un errore di allineamento richiede indagine; un IP in un altro paese non dimostra falsificazione.
Come pubblicare RUA
Aggiungi un TXT sotto _dmarc.yourdomain.com con destinazione valida rua=mailto:. Inizia dal monitoraggio se l'inventario dei mittenti è ancora incompleto.
Questo esempio usa allineamento rigoroso facoltativo, che può colpire sottodomini legittimi e non è la migliore scelta iniziale per tutti:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"Questa alternativa minima usa l'allineamento rilassato predefinito. Pubblica un solo record, non entrambi:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Usa una casella dedicata o un servizio di analisi. Evita di mescolare allegati XML compressi con le richieste abituali del supporto.
Per TrekMail, consulta i Record DNS richiesti. I controlli disponibili di SPF, DKIM e DMARC aiutano nella verifica, senza garantire la rilevazione di ogni problema o mittente esterno.
Come verificare RUA
Interroga direttamente il DNS, poi controlla la ricezione dei rapporti. Una configurazione errata può impedire ai partecipanti di ottenere una destinazione valida; una casella vuota può avere anche altre cause.
Usa dig o nslookup:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comLa risposta dovrebbe mostrare il TXT DMARC. Secondo la RFC 7489, questo è un altro esempio valido, non un record da aggiungere ai precedenti:
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"I rapporti sono spesso giornalieri, ma frequenza e partecipazione variano. La loro assenza non prova assenza di traffico né, da sola, un errore DNS.
Come leggere un rapporto RUA
Esamina origine, SPF, DKIM, allineamento e disposizione. Un'autenticazione valida deve essere allineata per contribuire a DMARC; non dimostra da sola che il contenuto sia sicuro o legittimo.
Una sequenza utile:
- Esamina IP e DNS inverso e confrontali con i fornitori: PTR non dimostra identità o legittimità.
- Valuta volume e importanza: un'origine con 2 messaggi può essere critica anche se un'altra ne invia 20,000.
- Controlla autenticazione e allineamento SPF/DKIM. Un risultato valido non allineato può non servire a DMARC.
- Esamina la disposizione:
nonenon prova recapito o monitoraggio;quarantinenon indica una cartella fissa;rejectnon garantisce blocco. - Indaga se l'origine è nota, mal configurata, intermediaria o abusiva.
Google richiede SPF o DKIM per i mittenti generici verso Gmail personale; per quelli di grandi volumi, entrambi e DMARC con l'allineamento applicabile al From: visibile. RUA aiuta a individuare problemi osservati, senza garantire la posta in entrata.
Tre situazioni da indagare
I rapporti possono rivelare mittenti legittimi non autenticati, inoltri e possibili falsificazioni, ma anche relay condivisi o altri percorsi. Indaga prima di classificare o bloccare.
1. Mittente legittimo mal configurato
Un servizio può usare il dominio senza SPF o DKIM validi e allineati. Basta un risultato valido e allineato per DMARC. Correggi il mittente e prova prima di cambiare politica.
In TrekMail, segui il percorso reale di invio. Per un servizio esterno, consulta SMTP proprio. Con invio incluso nel piano, consulta Managed TrekMail SMTP e verifica firma e allineamento disponibili.
2. SPF fallisce dopo un inoltro
Può succedere perché si connette il server di inoltro. Non prova che il messaggio sia malevolo. Se DKIM conserva i dati firmati secondo la canonicalizzazione, passa ed è allineato, DMARC passa. Verifica il percorso invece di ignorare automaticamente tutti gli errori SPF.
Consulta l'inoltro della posta e inoltrare la posta del dominio a Gmail. Distinguere l'errore SPF dal risultato DMARC evita modifiche inutili.
3. Origine sconosciuta o possibile falsificazione
Un IP o fornitore sconosciuto richiede indagine: può essere un servizio dimenticato, relay condiviso o inoltro. Non autorizzarlo in SPF né bloccarlo senza identificarlo. Valuta restrizioni dopo aver verificato le origini legittime.
Usare un servizio esterno per RUA?
Può facilitare l'analisi, ma devi comprenderne configurazione DNS e trattamento dei dati. Le destinazioni esterne richiedono l'autorizzazione corrispondente per essere accettate dai generatori partecipanti.
Secondo la RFC 7489, quando la destinazione rua è esterna al dominio organizzativo, il dominio che riceve i rapporti deve pubblicare l'autorizzazione sotto un nome come:
example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"Senza questa conferma, alcuni generatori ignorano la destinazione esterna. Segui le istruzioni esatte dell'analizzatore e verifica l'autorizzazione nel DNS di destinazione.
Quando passare da p=none a quarantine o reject
Usa i dati con inventario e test. Indaga gli errori prima delle restrizioni: rapporti favorevoli non provano la copertura di tutti i flussi legittimi.
Un percorso indicativo:
- Pubblica RUA con
p=none. - Osserva i rapporti per un periodo da 1 a 2 settimane come riferimento iniziale, estendendolo per i flussi rari.
- Correggi autenticazione e allineamento di ogni mittente affinché almeno SPF o DKIM passi allineato.
- Valuta
p=quarantinedopo aver risolto gli errori legittimi e indagato quelli sconosciuti. - Valuta
p=rejectdopo aver provato anche processi critici e inoltri.
Senza osservazione e prove, un cliente potrebbe segnalare un mittente dimenticato prima dei rapporti. Prepara la risposta agli incidenti durante la transizione.
Gestione dispersa o percorso coordinato
Esaminare XML separatamente per ogni dominio richiede coordinamento. DNS coerente e un pannello di domini, caselle, migrazione e invio possono facilitare le correzioni secondo le funzioni disponibili.
| Problema comune | Approccio con TrekMail |
|---|---|
| Configurazioni SPF, DKIM e DMARC diverse tra domini | Pannello di monitoraggio DNS e operazioni delle caselle |
| Mittente responsabile del mancato allineamento sconosciuto | Percorso DNS e documentazione diagnostica |
| Inoltri attribuiti solo a SPF | Configurazione che considera DMARC, DKIM e percorsi indiretti |
| Costi per utente ampliando i domini | Piani pubblicizzati da $3.50 al mese con spazio condiviso e senza costi per utente secondo le condizioni |
TrekMail non sostituisce un analizzatore DMARC. Può coordinare domini, caselle IMAP, catch-all, inoltri, migrazione IMAP e SMTP proprio o incluso secondo il piano. Verifica le funzioni necessarie per correggere i problemi osservati.
I piani sono pubblicizzati da $3.50 al mese. Nano è offerto gratuitamente senza carta. I piani a pagamento possono includere una prova di 14 giorni con carta richiesta: conferma le condizioni vigenti.
Conclusione: RUA offre visibilità parziale
RUA crea un canale utile per indagare autenticazione, inoltri e possibili falsificazioni. Integra questi dati con altre prove per valutare la preparazione del dominio alle restrizioni.
Con un dominio, cinquanta o cinquecento, basa le decisioni sui test. Rivedi periodicamente i rapporti, aggiorna l'inventario e correggi i mittenti prima della politica.
Per coordinare l'infrastruttura, TrekMail offre hosting multidominio, spazio condiviso, creazione di caselle tramite inviti e migrazione IMAP secondo il piano. Consulta le condizioni su trekmail.net e scegli secondo le esigenze operative.
