[ Guide sui provider DNS ]

Pubblica DNS di autenticazione su IONOS

Pianifica un cambio DNS IONOS in base alla zona di autorità reale, ai proprietari esatti dei record e alle prove di posta indipendenti. Il flusso di lavoro dell'editor documentato è disponibile; la procedura dettagliata dal vivo commissionata è ancora in sospeso.

A cura del team di ricerca EmailAuth · 6 minuti di lettura

[ Punti chiave ]

  • Mantieni separati l'host DNS , il registrar e il servizio di invio.
  • Traduci le etichette host relative in nomi di proprietari previsti espliciti.
  • Conserva una policy SPF e controlla i conflitti CNAME o di delega prima di modificare le dipendenze.
  • Dimostrare separatamente la pubblicazione autorevole e l'allineamento del messaggio ricevuto.
In questa pagina

Inizia con la zona autorevole

La registrazione IONOS, l'hosting DNS IONOS e l'e-mail IONOS sono responsabilità diverse. Questa guida riguarda la pubblicazione dei record di autenticazione tramite il pannello di controllo del dominio IONOS, non la configurazione di una casella di posta IONOS o l'autorizzazione di ogni servizio di invio IONOS. La documentazione ufficiale consente server di nomi esterni; i record inseriti in una zona IONOS inattiva non diventano risposte su Internet. Stabilire la zona delegata e l'amministratore responsabile prima di preparare qualsiasi modifica. Server dei nomi esterni IONOS

Per ogni modifica richiesta, registrare il nome completo del proprietario, il tipo di record, il valore attuale, il valore proposto, il servizio di invio e il proprietario che approva. Ottenere DKIM materiale dalle istruzioni specifiche dell'account del mittente effettivo. Un host DNS pubblica la configurazione pubblica; non può fornire la chiave di firma di un altro servizio o dimostrare che il servizio firma i messaggi. Mantieni le chiavi private al di fuori della richiesta di modifica DNS . Recupero chiave DKIM

Traduci i nomi prima di inserire i valori

IONOS documenta il percorso TXT come menu Azioni del dominio, DNS , Aggiungi record, quindi TXT . Il modulo separa Nome host, Valore e TTL facoltativo. Le voci esistenti hanno un'azione Modifica record. La sua pagina TXT generica descrive @ come carattere jolly, ma tale dicitura non dovrebbe diventare un presupposto per la progettazione dell'autenticazione. Un'abbreviazione di zona d'origine non è una promessa di pubblicare una politica per ogni discendente. Verifica il proprietario risultante anziché fare affidamento solo sul simbolo. Editor TXT di IONOS Notazione del file master DNS

Il dedicato DMARC le istruzioni sono più precise: il nome host _dmarc crea _dmarc sotto il dominio selezionato. In un esempio fittizio, scegliendo example.com e inserendo _dmarc dovrebbe indirizzarsi _dmarc.example.com . Questa è un'aspettativa proposta, non un risultato IONOS acquisito. Non inserire il suffisso del dominio due volte. Per i proprietari nidificati, conservare il nome completo previsto e richiedere un confronto delle risposte pubblicate prima dell'accettazione. Pubblicazione IONOS DMARC

Preserva i limiti dei record e la proprietà delle policy

Una raccolta TXT esistente può contenere token di verifica non correlati. Seleziona la policy di autenticazione rilevante, non tutte registrazione TXT presso quel proprietario. SPF consente una politica SPF selezionata; l'aggiunta di un secondo candidato non è il modo in cui un altro mittente riceve l'autorizzazione. Qualsiasi consolidamento richiede un inventario dei mittenti e una valutazione dei termini di query DNS, comprese le dipendenze raggiunte tramite include. Non ampliare silenziosamente l'autorizzazione mentre si riordina il testo. Selezione e limiti dei record SPF

Un record di risorse TXT può contenere più stringhe di caratteri. Per SPF queste stringhe vengono concatenate senza spazi inseriti. Più stringhe all'interno di un record non vengono pubblicate separatamente Registri SPF. Le istruzioni IONOS riviste non stabiliscono ogni comportamento di suddivisione, fuga o quotazione di valori lunghi. Tratta i dettagli dell'editor come un controllo di accettazione: confronta i dati autorevoli e i limiti del record con il valore completo approvato. Non realizzare un esperimento a chiave lunga di successo. SPF più stringhe Formato dati TXT

Distinguere un alias dall'autorità delegata

Per un DKIM fornito dal mittente CNAME, IONOS documenta un percorso DNS del sottodominio, un campo Nome host e un Punto di destinazione espresso come nome host completo senza uno schema URL web. UN selettore alias non è un'istruzione per reindirizzare un sito Web o modificare l'instradamento della posta del dominio. Conferma il selezionatore e la destinazione esatti con il proprietario del servizio di invio. Flusso di lavoro IONOS CNAME

IONOS avvisa quando un nuovo record è in conflitto con un servizio attivo. Fermati a questo avviso e identifica la dipendenza prima di approvare una sostituzione. I dati TXT e CNAME ordinari non possono condividere lo stesso proprietario dell'alias. Separatamente, il provider supporta i record NS del sottodominio tramite l'editor DNS ; questo delega la responsabilità di un sottoalbero e ha un effetto più ampio rispetto alla pubblicazione di un alias chiave. Non considerare la delega come una soluzione alternativa a una collisione inspiegabile. Conflitti IONOS Delega del sottodominio IONOS

Verificare la pubblicazione e spedire in autonomia

La sequenza di accettazione proposta inizia con query autorevoli prima e dopo per ciascun proprietario e tipo esatto, server di registrazione, ora, codice di risposta, risposta e delega pertinente. Quindi confrontare un'osservazione ricorsiva e indagare su eventuali discrepanze. Le cache positive e l'inesistenza della cache sono cause separate di risposte obsolete. La memorizzazione nella cache negativa utilizza il valore più piccolo tra SOA TTL e SOA MINIMUM per la sua durata iniziale, non solo MINIMUM. Lo stato salvato di un editor e una stima della documentazione di un'ora non sono una garanzia di convergenza DNS universale. Cache DNS Durata della memorizzazione nella cache negativa

Successivamente, un operatore autorizzato deve esercitare il flusso di lavoro di invio previsto e preservare il messaggio ricevuto. Confronta il dominio Da visibile, l'identità della busta SMTP , i domini di firma DKIM e i selettori con i risultati dell'autenticazione del destinatario attendibile. RFC 9989 consente il successo DMARC attraverso un percorso SPF o DKIM di passaggio allineato; semplicemente trovare entrambi i record DNS non dimostra nessuno dei due percorsi. Una politica richiede il trattamento e non garantisce la consegna o la segnalazione. RFC 9990 specifica separatamente il reporting aggregato. Allineamento DMARC Reporting aggregato Fiducia nei risultati dell'autenticazione

Mantenere il recupero più ristretto dell'incidente

Prima di una modifica approvata, conservare i precedenti record interessati e il motivo per cui ciascuno è importante. Il backup e il ripristino della zona IONOS richiedono DNS Pro; il ripristino sovrascrive i dati della zona esistente. Un backup disponibile non è quindi l'autorizzazione per ripristinare modifiche non correlate. Chiedere al proprietario di scegliere un ripristino mirato o un ripristino rivisto dell'intera zona, quindi ripetere la pubblicazione e i controlli dei messaggi. Questo pacchetto non esegue nessuna delle due azioni. Ambito di backup di IONOS

Prove richieste prima della pubblicazione

I requisiti esatti del catalogo sono: una guida dettagliata per la pubblicazione IONOS attuale con query autorevoli prima/dopo e un messaggio verificato in modo indipendente.

Tale requisito rimane aperto. Le istruzioni pubbliche sono state riviste il 9 novembre 2026, senza accesso all'account, query DNS in tempo reale, record modificati o messaggio ricevuto. Le attuali etichette dei locatari, la gestione dei testi lunghi, la delega effettiva, l'applicabilità del mittente, la revisione tecnica, i controlli del percorso di produzione, l'accettazione visiva e l'approvazione del proprietario necessitano ancora di prove. L'esempio del nome fittizio e la sequenza di verifica proposta costituiscono una preparazione, non una procedura dettagliata eseguita.

[ Porta via ]

Accettare la modifica solo quando i dati autorevoli previsti e l'effettiva identità di invio concordano con la configurazione approvata.

[Per ruolo]

Cosa significa questo per te

Scegli il tuo ruolo per i prossimi passi pratici.

amministratore DNS

Proteggi il confine della zona

Un salvataggio riuscito nella zona sbagliata è comunque un cambiamento inefficace. L'amministratore possiede il posizionamento autorevole e gli effetti sui record vicini.

Prossimi passi

  1. Scrivi il proprietario completo previsto e digita accanto a ciascuna voce dell'editor proposta.
  2. Registra le dipendenze presenti prima di risolvere un conflitto CNAME o prendere in considerazione la delega.
  3. Conservare l'evidenza completa e autorevole prima e dopo l'esecuzione di un test approvato.

Proprietario del servizio di posta elettronica

Fornire identità, non record generici

Il mittente determina la busta e il comportamento di firma. Un amministratore DNS non dovrebbe dover dedurre un selettore di tenant o presupporre che un record attivi la firma.

Prossimi passi

  1. Fornire la configurazione pubblica corrente specifica dell'account e il flusso di lavoro di invio previsto.
  2. Definire il Da visibile, la busta prevista e le identità di firma per l'accettazione.
  3. Organizza un messaggio controllato autorizzato ed esamina i risultati del destinatario attendibile.

Cambia approvatore

Definire un recupero limitato

Le modifiche all'autenticazione possono interrompere la posta non correlata quando una policy, una delega o un'intera zona viene sostituita senza revisione delle dipendenze.

Prossimi passi

  1. Approvare i nomi, i servizi e l'ambito del rollback interessati prima dell'esecuzione.
  2. Controlla se il ripristino DNS Pro sovrascriverà i record più recenti non correlati.
  3. Mantieni il rilascio bloccato fino al completamento della procedura dettagliata commissionata, della revisione tecnica e delle approvazioni della pubblicazione.

[ Domande frequenti ]

Domande frequenti

La registrazione su IONOS dimostra che questo editor è autorevole?

No. La registrazione può coesistere con server dei nomi esterni. Seguire l'autorità delegata per la zona esatta prima di decidere dove pubblicare; non cambiare server dei nomi semplicemente per rendere visibile una modifica.

Devo incollare _dmarc.example.com nel nome host?

La procedura dedicata IONOS DMARC specifica la relativa etichetta _dmarc per il dominio selezionato. Conservare separatamente il proprietario completo previsto e verificare che il nome pubblicato non abbia suffissi duplicati.

@make SPF si applica automaticamente a ogni sottodominio?

No. Tratta @ come notazione di origine della zona, non come autorizzazione con caratteri jolly. SPF viene valutato per l'effettiva identità in uso; una policy padre non fornisce automaticamente a ogni dominio figlio la propria policy SPF .

Qual è la risposta sicura alle due politiche SPF esistenti?

Interrompi l'aggiunta proposta e chiedi ai proprietari responsabili del mittente di riconciliare l'autorizzazione in un'unica policy valida. Conserva i token TXT non correlati e valuta le dipendenze di inclusione anziché semplicemente unire due record completi.

IONOS può contenere un CNAME DKIM specifico del mittente?

Le sue istruzioni pubbliche supportano la pubblicazione CNAME per i sottodomini. Il provider di invio deve fornire il selettore e la destinazione applicabili. Verificare la presenza di dati in conflitto presso l'esatto proprietario dell'alias e lasciare in pace gli altri selettori.

Come deve essere controllata una chiave TXT lunga?

Confronta la chiave pubblica completa approvata con il record TXT autorevole, inclusa la concatenazione di stringhe e i limiti del record. Questa ricerca non ha testato il comportamento di suddivisione, fuga o quotazione di IONOS, quindi questi dettagli rimangono una vera e propria soluzione.

È sufficiente un'ora per dichiarare che lo schieramento ha avuto successo?

Il tempo trascorso non costituisce prova di accettazione. Pubblicazione autorevole separata, memorizzazione nella cache ricorsiva e autenticazione dei messaggi. I dati positivi o l'inesistenza precedentemente memorizzati nella cache possono spiegare osservazioni diverse; ispezionare la risposta effettiva e il contesto TTL.

Un backup DNS Pro può annullare in modo sicuro solo la modifica dell'autenticazione?

Il ripristino di una zona è più ampio: IONOS afferma che sovrascrive i dati di zona esistenti. Controlla i diritti, i contenuti del backup e le modifiche intervenute. Una riparazione record mirata e approvata può evitare di annullare il lavoro non correlato; nessuna delle due opzioni è stata eseguita qui.

[ Fonti ]

Fonti

  1. RFC 8601 : campo di intestazione del messaggio per indicare lo stato di autenticazione del messaggio
  2. IONOS: backup e ripristino delle zone DNS
  3. IONOS: configurazione di un record CNAME per un sottodominio
  4. IONOS: evitare i conflitti DNS
  5. RFC 6376 : firme di posta identificate da DomainKeys
  6. RFC 9989 : autenticazione, reporting e conformità dei messaggi basati sul dominio
  7. RFC 1034 : Nomi di dominio: concetti e strutture
  8. RFC 1035 : Nomi di dominio: implementazione e specifica
  9. IONOS: configurazione di un record DMARC per un dominio
  10. IONOS: utilizzare i propri name server per un dominio
  11. RFC 2308 : memorizzazione nella cache negativa delle query DNS
  12. RFC 9990 : report aggregati DMARC
  13. RFC 7208 : quadro delle politiche del mittente
  14. IONOS: aggiungi, modifica o elimina un record NS per un sottodominio
  15. IONOS: gestione dei record TXT

[ Glossario ]

Glossario

Zona autorevole
La parte dello spazio dei nomi DNS servita dai dati autorevoli responsabili. Identificarlo prima di scegliere l'editor per un proprietario di autenticazione.
Nome del proprietario
Il nome DNS a cui appartiene un record, ad esempio _dmarc.example.com . È distinto da un target CNAME o da un valore TXT .
Stringa di caratteri TXT
Un componente con lunghezza limitata dei dati del record TXT . Più componenti possono appartenere a un record di risorse e richiedere un'interpretazione specifica del protocollo.
Alias ​​del selettore
Un CNAME presso il proprietario di un selettore DKIM che indirizza la risoluzione verso la posizione della chiave gestita dal mittente; non è una delega NS dell'intero dominio.
Cache negativa
Prova DNS memorizzata nella cache che un nome o i dati richiesti erano assenti. La sua durata è rilevante quando un record di autenticazione appena creato non è ancora visto da un risolutore.

Provenienza aziendale

Perché le principali istituzioni finanziarie e i governi hanno ritirato le dashboard di sicurezza della posta elettronica.

Le tradizionali piattaforme di autenticazione e-mail ti vendono una dashboard e chiedono ai tuoi ingegneri di fare il lavoro. Negli ambienti ad alto rischio, la supervisione manuale comporta un’applicazione ritardata, deviazioni della configurazione e domini ombra non monitorati.

EmailAuth è la piattaforma di provenienza della posta elettronica degli agenti. I nostri agenti applicano p=reject, mantieni allineati i mittenti di terze parti e sposta i tuoi domini al massimo RFC 9989 conformità, il nuovo standard DMARC , con verificabilità human-in-the-loop.

Governi Grandi imprese Istituti finanziari di primo livello

SaaS · Locazione dedicata · Air-gapped on-premise · Crittografia BYOK

Base di conoscenza