The zone: "" in account: "" was deleted

I received an e-mail like the one in the subject line. I think the error is causing an issue with the delivery of my e-mails to the affected account. I am not sure, but it must have something to do with my DNS settings and maybe my DMARC settings. It is important that I fix that because I need to get those e-mail in order to recover an account where I have that domain registered.

The full text of the e-mail is:


The zone: "xxxx" in account: "[xxxx](mailto:xxxx)" was deleted by Cloudflare on 2023-08-02T13:31:21.155811Z.

If the zone was deleted by mistake, it can be re-added to reinstate existing configuration of the zone. To learn more, read Why was my domain deleted from Cloudflare? []


The Cloudflare Team


The one in my profile.

The name servers listed in the bottom of your DNS records page, are they named FRANK and NOLA?

It looks like you’re pointing your inbound emails towards Zoho, and according to the set up, like outbound ones are supposed to originate from Zoho as well.

You do NOT seem to have a DMARC record right now.

Your website traffic isn’t Proxied (:orange) through Cloudflare, but running as Unproxied (:grey:) / DNS-only.

From my location in the EU, the website loads a bit slow, which seems to be a mix of a lot of requested background data (e.g. 330 requests within 10 seconds, 550 requests within 15 seconds, 660 requests within 30 seconds), as well as the fact that the website traffic is travelling continents (e.g. EU to US), as you appear to be pointing directly towards a server in the US West.

A good percentage of these requests seems however to be YouTube/Spotify requests, that your website makes in the background.

Does the above seem to fit your set up, … if so, everything does actually look to be “fine” from my end?

That sounds about right. I did just secure my Cloudflare account with 2FA, although I doubt anyone hacked into my account. I had to update the contact information e-mail and verify it.

Does it make any difference to proxy it or not.

Also, I am not really clear what the DMARC setup does. I keep getting intermittent reports about that, mostly related to Google, in XML format.

The website is still under construction. It is running on a Digital Ocean Droplet that I pay 28 USD per month for, and I’ve been looking for a different hosting service that has GPU’s for AI development.

The home page is just related to this movie project that I’ve been thinking about, but the stuff behind the scenes with what I am really interested in.

I have a domain registered with a provider in Austria that I might wish to transfer to Cloudflare, idiots-are-savants dot eu, and I think I have a similar one in the US, idiots-are-savants dot us

I am having trouble gaining access to 101Domains, which is where the domain is registered. I am not sure if it is wise to have them all registered with the same provider though.

Always better to be safe than sorry, so :+1: here!

It makes some kind of difference, -

No kind of Cloudflare features (e.g. DDoS protection, WAF, et cetera) will work without the record being Proxied (:orange:).

Cloudflare only serve in the same way as how any other DNS provider would do, when you use Unproxied (:grey:) / DNS-only records.

One of the things about DMARC is about applying a policy to messages claiming to be from your domain name, but not actually authenticating successfully, e.g. against DKIM OR SPF.

I can easily send (e.g. “spoof”) a message that pretends to be from your domain name, which may be able to end up on destroy the reputation of your brand. - What exactly would you want receiving mail servers to do, with such a message?

In order to successfully pass either DKIM or SPF with proper alignment, as DMARC requires, I would need to have had sort of DNS level control over your domain name.

With the rua/ruf tags, you can enable reports to be sent, like you say, e.g. Google sends some aggregate information daily, about how much email messages they have received claiming to be from your domain name, whether they passed or failed the checks, and so on.

The reports can be useful in detecting whether one or more email providers needs further action from your end, in order to pass e.g. DKIM or SPF, and whether or not the alignment works properly.

They can also be used to identify e.g. illegitimate sources that are spoofing messages to claim they are being sent from your domain name.

My recommendation? All should go for a DMARC p=reject/sp=reject policy, as well as a SPF ending in -all.

However, the reject policy and whether or not you’re able to do that, depends on many different factors, such as how you’re sending your messages, what your provider(s) allow you to do, and so forth…

I would recommend ´DKIM` for all of your legitimate messages to be perfect first, before setting p=reject, and identifying that part can be done using the DMARC reports.

Trouble are often the reasons leading to (re-)considerations. :wink:

Having it all at one single place may have the positive effect of “administrative ease” / simplicity.

I personally prefer some sort of redundancy, or “neutrality” (if we can call it that) by having the domains registered at one place, the name servers at a second place, and most often, the actual hosting at a third place.


This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.