False-positive security block (Akamai / Comcast Business SecurityEdge)

I'm a Comcast Business customer and the owner/operator of weatherboard.net, a legitimate weather-dashboard service. SecurityEdge on my Business line is blocking my own domain, weatherboard.net, as malware/phishing. It's a false positive, and I'd like the classification corrected at the source not just self-allowed on my own account. This false classification has poisoned the following downstream from Akamai security vendors who have added the domain to their block lists completely blocking potential customers and testers from even accessing the account or sending me email. (for example other comcast customers can't validate my _dmarc records): 

alphaMountain.ai  
T-Mobile
MalwareBytes
CDRF
Certgo
Gridinsoft
Fortinet (FortiGuard)
 
I expect to find out several others add us to their list because we are on the Akami list in their next update - this damage took less than 10 hours. 

I traced what triggered it. I run a personal weather station (an Ecowitt console) that posts its readings to my service once a minute, via HTTP POST to ingest.weatherboard.net/ecowitt/<token>.

That regular once-a-minute POST to a token path is the kind of pattern an automated classifier can mistake for C2/beaconing — but it's ordinary weather telemetry (temperature, wind, rain), validated by token and stored. Nothing is ever sent back to the device, and the endpoint serves no executable content. After approximated 12 hours, SecurityEdge flagged this as potentially malicious. 

I've already hardened the endpoint so it's clearly benign on inspection: it now presents a publicly-trusted Let's Encrypt certificate and a plain landing page explaining what it is (previously
it only exposed the POST path). Ecowitt consoles can't do HTTPS upload on their current firmware, so the endpoint must accept plain-HTTP POSTs for the hardware to work — a vendor limitation, not a shortcut. There is no way for the tens of thousands of PWS users using this brand to submit weather condition updates to a custom endpoint over https, only over http.

Honestly, part of why I'm posting here is that there's no real way to *report* this. I spent nearly an hour on the phone, and the only path offered was to open a support ticket and then wait
for someone to circle back and ask for the details, there's no self-service false-positive form or direct line to the SecurityEdge team. For a product that can block a legitimate business's own
domain, a simple "report a false positive" submission would save everyone a lot of time. Looking through your forum, I have seen customers saying resolving this type of issue take 4-6 WEEKS, that is life or death of a business in 2026.

With no usable way to report this and a business to run, I ultimately had to disable SecurityEdge entirely on my account just to function — which removes that protection from my whole network and should never be the only option left to a customer. The underlying SecurityEdge/Akamai classification is still flagged, which affects every SecurityEdge customer, so it still needs to be corrected at the source. Could a moderator help escalate this to the SecurityEdge team for a proper reclassification? I'm happy to verify domain ownership and share my account details by private message.