I record Cloudflare in proxy (nuvola arancione) bloccano le email: come risolvere

Cosa significa

Nel DNS di Cloudflare, ogni record A, AAAA e CNAME ha uno Proxy status: Proxied (nuvola arancione) o DNS only (nuvola grigia). Quando un record è in proxy, Cloudflare non pubblica il vero IP del tuo server. Risponde con i propri IP e inoltra il traffico web (HTTP/HTTPS) al tuo server.

La posta non passa da quel proxy. Quindi, se un record usato per la posta è in proxy, gli altri server ottengono l'indirizzo di Cloudflare invece di quello del tuo server di posta. I sintomi:

• Nessuno riesce a inviarti email: l'MX punta a un host che risolve verso Cloudflare e la connessione sulla porta 25 fallisce o va in timeout.
• SPF fallisce: un meccanismo a o mx ora risolve verso gli IP di Cloudflare, non verso il tuo server.
• DKIM o la verifica del dominio falliscono su SendGrid, Mailgun e strumenti simili: i loro record CNAME sono stati aggiunti in proxy.
• Le tue app di posta non riescono a connettersi a mail.yourdomain.com per IMAP o SMTP.

Perché succede

• Trasferimento del DNS su Cloudflare: durante l'importazione, Cloudflare può mettere dei record in proxy, compreso mail.
• Un solo record A per entrambi: il sito e il server di posta condividono lo stesso nome host, e qualcuno lo ha messo in proxy per il sito.
• CNAME del provider email in proxy: CNAME come em1234.yourdomain.com o s1._domainkey.yourdomain.com aggiunti con la nuvola arancione attiva.

I record MX e TXT non possono essere messi in proxy; il problema è sempre l'A, l'AAAA o il CNAME da cui dipendono.

Come verificare

1. Apri lo scanner di domini e guarda i tuoi record MX e l'IP verso cui risolve ciascun host MX. Usa Whois su quell'IP: se appartiene a Cloudflare e non usi un prodotto di posta Cloudflare per quell'host, il record è in proxy.
2. Con dig:

   dig MX yourdomain.com +short
   10 mail.yourdomain.com.
   dig A mail.yourdomain.com +short
   104.16.x.x        (Cloudflare range: wrong for a mail server)

3. Testa un CNAME DKIM: un CNAME in proxy non restituisce la chiave TXT che c'è dietro.

   dig TXT s1._domainkey.yourdomain.com +short

4. Invia un'email di test dal tuo server all'indirizzo unico indicato nella home page di Delivmail (/) e leggi il risultato SPF. Un fallimento per l'IP del tuo stesso server deriva spesso da una destinazione a o mx in proxy.
5. Nella dashboard di Cloudflare, apri il tuo dominio, vai su DNS > Records e guarda la colonna Proxy status.

Come risolvere

1. Imposta i record di posta su DNS only

Modifica ciascuno di questi record e passa il Proxy status a DNS only (nuvola grigia):

• il record A/AAAA di ogni host usato nei tuoi record MX (per esempio mail, mx);
• gli host a cui si connettono le tue app di posta per IMAP, POP e SMTP;
• ogni CNAME fornito da un provider email (selettori DKIM, domini di return-path o di rimbalzo, tracciamento dei link salvo diversa indicazione del provider);
• ogni host citato nell'SPF con a:.

Type   Name       Content          Proxy status
A      @          203.0.113.80     Proxied   (website: OK)
A      mail       203.0.113.25     DNS only  (mail server)
MX     @          mail.yourdomain.com   priority 10
CNAME  s1._domainkey  s1.domainkey.u123.wl.sendgrid.net   DNS only

2. Separa il sito e l'host di posta

Non far puntare il tuo MX allo stesso nome del sito in proxy. Usa un nome dedicato come mail.yourdomain.com in DNS only. Nota che un host di posta in DNS only pubblica il suo IP; se è lo stesso IP del sito, rivela l'indirizzo reale del sito. Ospitare la posta su un IP diverso o presso un provider email evita questo problema.

3. Rendi l'SPF indipendente dai nomi in proxy

Nell'SPF preferisci ip4:/ip6: o l'include: del tuo provider rispetto ad a e mx:

v=spf1 ip4:203.0.113.25 include:_spf.google.com ~all

Se usi Google Workspace o Microsoft 365, il tuo MX punta ai loro server e lì non serve cambiare nulla del proxy; controlla invece i CNAME DKIM e il record SPF. Per problemi simili, vedi record email persi dopo il trasferimento del DNS.

Verifica che sia risolto

Le modifiche al proxy hanno effetto rapidamente, ma i resolver possono tenere in cache le vecchie risposte per la durata del TTL del record (vedi propagazione DNS e TTL). Poi esegui di nuovo dig A mail.yourdomain.com: deve restituire l'IP del tuo server. Invia un nuovo test Delivmail e verifica che SPF e DKIM passino, verifica di nuovo il dominio nel tuo strumento di invio e invia un'email da una casella esterna al tuo dominio per confermare la ricezione.