Kort svar: Cloudflare proxyer kun web-trafik – aldrig mail. Går mailen ned efter et Cloudflare-skift, står mail-relaterede DNS-records næsten altid forkert: MX må aldrig pege på et proxied navn (orange sky), og værter som mail., webmail., smtp. og imap. skal stå med grå sky (DNS only). Ret skyerne, vent på propagering – og mailen fungerer igen, uden at web-beskyttelsen mister noget.
Mønsteret er klassisk: et site flyttes bag Cloudflare, alt ser fint ud – og næste morgen kan ingen sende eller modtage mail, og Outlook kan ikke forbinde. Forklaringen er næsten altid den orange sky på records, der ikke må være proxied. Mailprotokoller (SMTP, IMAP, POP3) kan ikke gå gennem Cloudflares webproxy, så når mailserverens navn opløses til en Cloudflare-adresse, løber forbindelserne dødt.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med anonymiseret domæne – det er ikke data fra hostious.io.
Den orange sky betyder: “send trafikken gennem Cloudflares webproxy”. Proxyen taler HTTP og HTTPS – ikke SMTP på port 25/465/587 eller IMAP på 143/993. En mailserver bag orange sky er derfor usynlig for al mailtrafik. Cloudflare advarer selv i dashboardet, når en MX peger på et proxied navn – men advarslen er let at overse midt i en onboarding, og den dukker ikke op, hvis skyen tændes senere.
Åbn DNS → Records i Cloudflare, og følg kæden: MX-recorden peger på et navn (fx mail.ditdomæne.dk) – og det navns A-record afgør alt. Udefra kan du se resultatet med dig:
| Record | Type | Sky |
|---|---|---|
| ditdomæne.dk (web) | A/AAAA | Orange – proxied |
| www | A/CNAME | Orange – proxied |
| MX → mail.ditdomæne.dk | MX | Har ingen sky – men målnavnet skal være gråt |
| A | Grå – DNS only | |
| webmail, smtp, imap, pop, autodiscover, autoconfig | A/CNAME | Grå – DNS only |
Ret de forkerte skyer ved at klikke på dem – ændringen slår typisk igennem på minutter, men klienter og andre mailservere kan cache det gamle svar i op til TTL’ens længde; baggrunden står i propagerings-guiden. Bemærk trade-off’et: en grå mail-record afslører serverens IP. Ligger mail og web på samme server, er web-serverens IP dermed synlig – det er præcis derfor, mange lægger mail på en separat adresse eller hos en dedikeret mail-hosting.
Selve TXT-records (SPF, DKIM, DMARC) påvirkes ikke af skyerne – de er rene tekstopslag. Men tjek dem alligevel efter en Cloudflare-migrering: ved import af zonen smutter der af og til records. Sender sitet via en SPF-mekanisme som a eller mx, kan proxied records desuden få valideringen til at pege på Cloudflare-adresser – brug eksplicitte include/ip4-mekanismer i stedet; se SPF/DKIM/DMARC-guiden. Webmail på webmail.-underdomænet er teknisk set web og kan proxies – men den følger typisk kontrolpanelets opsætning; den enkle regel “alt mail-relateret gråt” giver færrest overraskelser.
Mailen er tilbage, når mail.-navnet opløses til mailserverens rigtige IP (dig +short), en testmail udefra (fx fra Gmail) lander i indbakken, en testmail sendes ud uden fejl, og Outlook/Apple Mail forbinder på både IMAP og SMTP. Test også autodiscover, hvis I bruger det – ny opsætning af mailklienter fejler ellers stille. Og skriv én linje i jeres driftlog om, hvilke records der skal være grå – så overlever reglen næste omgang DNS-oprydning. Er du i tvivl om jeres konkrete opsætning, kigger Hostious-supporten gerne DNS-zonen igennem.
Fordi afsendende mailservere og klienter cacher DNS-svar. Mailen dør først, når de gamle opslag udløber – derfor kommer nedbruddet typisk forskudt og rammer gradvist flere.
Web-beskyttelsen er intakt – web-records forbliver orange. Prisen er, at mailserverens IP er synlig; ligger web på samme IP, kan angribere gå uden om proxyen. Løsningen er separat mail-IP eller dedikeret mailhosting, ikke en orange sky på MX.
Cloudflare kan hoste mail-DNS og tilbyder Email Routing til videresendelse af indgående mail – men selve mailserver-trafikken (SMTP/IMAP) proxyes aldrig. Din mailserver skal altså altid kunne nås direkte.
