Source: Dev.to

Introduction

A few days ago I received an unexpected email from Cloudflare: maildock.store had stopped using their nameservers and was at risk of being deleted. I hadn’t changed any DNS settings, so the notice was a surprise. After some digging I discovered that the domain had been flagged for abuse, most likely because it powers a disposable‑email service.

---

What is Nullmail?

Nullmail (hosted at maildock.store and nullmail.cc) is a privacy‑first disposable‑email service. Its core principles are:

User Experience

• Users create a temporary address.
• Incoming mail is forwarded to the address and displayed in a lightweight UI.
• After a configurable period the address (and its messages) are removed automatically.

---

Architecture Overview

The whole system is built from a handful of lightweight components, most of which run on free tiers.

Database Schema (simplified)

-- addresses table
CREATE TABLE addresses (
    id          uuid PRIMARY KEY,
    address     text NOT NULL,
    expires_at  timestamptz NOT NULL
);

-- emails table
CREATE TABLE emails (
    id          uuid PRIMARY KEY,
    address_id  uuid REFERENCES addresses(id) ON DELETE CASCADE,
    sender      text NOT NULL,
    recipient   text NOT NULL,
    subject     text,
    body        text,
    received_at timestamptz NOT NULL
);

A cron job runs every five minutes to delete rows whose expires_at has passed.

---

The Incident

Why a Receive‑Only Service Gets Flagged

Even though Nullmail never sends outbound mail, disposable‑email domains are often associated with spam‑related activity. Automated abuse systems at registries sometimes treat any domain that hosts a disposable‑mail service as high‑risk, leading to a ServerHold status.

---

Investigation Steps

1. WHOIS lookup – confirmed ServerHold status.
2. DNS verification – ensured Cloudflare records (NS, MX, SPF, DMARC, TLSRPT, _security) were correct.
3. Blacklist checks – queried SURBL, Spamhaus, etc.; the domain appeared temporarily listed.
4. Contacted Radix – opened a ticket to understand the specific abuse reason.
5. Gathered evidence – compiled logs from Supabase (no outbound traffic) and ForwardEmail (receive‑only).

---

Resolution (What Worked)

After the registry cleared the hold, Cloudflare automatically restored the nameserver status, and inbound mail flow resumed without interruption.

---

Lessons Learned

1. Registry‑level abuse flags can affect even the most minimal services.
2. Explicitly declare “receive‑only” in DNS (SPF -all, DMARC p=reject).
3. Maintain a visible abuse contact in WHOIS and a policy.txt to aid manual reviews.
4. Separate concerns – keeping the frontend, API, and DNS isolated meant the outage was limited to the domain name, not the whole stack.
5. Automated monitoring of WHOIS and blacklist status can give early warning before a hard hold is applied.

---

Final Thoughts

Nullmail’s architecture—lightweight, privacy‑first, and largely serverless—allowed a swift recovery when the domain was flagged. By adding a few defensive DNS records and clear abuse‑handling documentation, the service can continue to operate without compromising its core philosophy.

If you run a disposable‑email or any privacy‑focused service, consider the following checklist:

• Publish SPF v=spf1 -all and DMARC p=reject.
• Provide a dedicated abuse email address in WHOIS.
• Host a policy.txt explaining the service’s purpose and abuse‑handling process.
• Periodically query WHOIS and major blacklists for your domain.
• Keep DNS and registry contacts up‑to‑date.

With those safeguards in place, you’ll be better prepared for the inevitable automated abuse checks that come with operating a “throw‑away” email domain.

---

Repository: (MIT‑licensed)

End of post.

ServerHold Incident – maildock.store

---

Overview

The domain maildock.store was placed on ServerHold by the registry, which stopped all traffic to the service. Although the service is receive‑only (no outbound mail), the registry flagged it for potential abuse.

Key points:

• The service is privacy‑first: no logs are kept, and it only receives email.
• The registry’s automated systems can be overly cautious.
• The exact trigger for the flag remains unknown.

---

Immediate Actions

1. Contact the Registry

• Submitted the unsuspension form.
• Explained the service’s receive‑only nature.
• Detailed the privacy‑first safeguards in place.

Result: Radix responded positively, removed the ServerHold, and reinstated the domain.

2. Provide an Abuse Contact

• Created a dedicated mailbox: abuse@maildock.store.
• Stored the mailbox address in the Supabase database (no public access).
• Checked the mailbox only via the Supabase UI when needed.

3. DNS Cleanup (Cloudflare)

Outcome: The domain became fully operational again—emails were received reliably, and the automatic cleanup of expired content continued to work.

---

Lessons Learned

Abuse‑Related Insights

• Even a receive‑only service can be flagged.
• Registry‑level automated abuse systems tend to be cautious and sometimes overly conservative.
• Lack of logs (privacy‑first design) means there’s no internal way to determine what triggered the flag.

DNS & Registry Configuration

• Inconsistent nameservers or leftover DNS records can trigger alerts.
• Clear, correct DNS entries are essential for domain reachability.

Communication

• Direct, timely communication with the registry is crucial.
• Providing a clear explanation and a point of contact (the abuse mailbox) helped resolve the issue quickly.

Minimalist Architecture Trade‑offs

• Pros: Isolates most operations from failures; simplifies the system.
• Cons: No logging and no outbound monitoring mean reliance on external feedback to detect problems.

Open Questions

• The exact reason for the abuse flag is still unknown.
• Possibilities include:
  • A malicious actor reporting the domain.
  • An exploit attempt on the service.
  • An automated flag based on domain history or traffic patterns.

---

Final Thoughts

Running a privacy‑first, minimal disposable email service brings both benefits and uncertainties:

• Minimalism and privacy help in many areas, but external systems (registries, DNS providers, abuse monitors) can still impact availability.
• Due diligence is essential: understand how registries evaluate domains and anticipate potential false positives.
• While you should value your users, you must also design for abuse and have clear contact channels.

The incident reinforced the importance of:

1. Clear abuse contact channels.
2. Proper DNS hygiene.
3. Documenting a simple, minimal architecture that isolates potential issues.

Overall, the service is back up without lasting damage, and the experience provides valuable insight into how to design resilient, privacy‑focused services.