DEV Community: xusteve

Giving AI Agents an Email Deliverability Check with MCP

xusteve — Mon, 02 Nov 2026 06:58:15 +0000

Your agent can draft an email in seconds. It still cannot tell whether the sending domain is configured correctly.

That gap matters. An agent can produce a perfect cold email, newsletter, or support reply, then hand it to a domain with no SPF record, a broken DKIM selector, or a DMARC policy that tells receivers to do nothing. The writing is fine; the infrastructure is not.

I built a small remote MCP server to give agents a read-only email-domain health check. This post shows how it works, how to connect it, and where I deliberately kept the scope narrow.

One tool: `scan_domain`

The MCP server is available at:

https://mcp.mailers.email/mcp

It exposes a single tool:

{
  "name": "scan_domain",
  "description": "Run a domain email health scan (cheap checks; no blacklist).",
  "inputSchema": {
    "type": "object",
    "properties": {
      "domain": { "type": "string" }
    },
    "required": ["domain"]
  }
}

A call returns checks for:

MX records
SPF
DKIM
DMARC
reverse DNS / PTR
domain age

The response includes a score, maxScore, grade, confidence, individual check details and a fixes array ordered by what to fix first.

The public MCP tool intentionally does not run DNSBL blacklist checks. Those are 32+ extra DNS queries per domain and belong in the full web scan at mailers.email/scan, not in a quick agent tool.

Connect an MCP client

Add the server to your MCP configuration:

{
  "mcpServers": {
    "mailers": {
      "url": "https://mcp.mailers.email/mcp"
    }
  }
}

No API key, account, or OAuth flow is required. The server is anonymous and rate-limited by IP.

After connecting, ask your agent something like:

Check example.com's email setup. Tell me the three most important fixes and why they matter.

A useful agent response should separate:

What is broken — for example, no MX record or no SPF record.
What it means — can the domain receive mail? Can another server spoof it?
What to do first — prioritize authentication and routing before cosmetic improvements.

Why only one tool?

MCP servers can become a pile of endpoints. I kept this one focused because the main agent use case is simple: check a domain before you send from it or recommend it.

One tool also makes the permission model easy to reason about:

It is read-only.
It does not touch a mailbox.
It does not send email.
It does not require credentials.
It returns DNS-based evidence, not a guarantee of inbox placement.

DNSBL checks, mailbox access, and sending would each deserve a separate tool with a separate threat model.

Limits and caching

The MCP server shares the same scan budget as the REST API:

60 requests per hour per IP
No API key or account
MCP calls run a fresh scan
The REST endpoint caches same-domain results for 24 hours

That difference is intentional. The REST API is optimized for repeated checks and dashboards; the MCP path is optimized for an agent asking once during a task.

If your agent needs the full blacklist report, send it to the web scanner or use the REST API's documented surface. The MCP tool says no blacklist in its description so the agent does not silently assume otherwise.

What the score means

The public API returns maxScore: 80. That is not a bug.

The score is normalized against the checks that actually ran. Because DNSBL checks are excluded from the public API, the maximum available score is 80 rather than 100. A "perfect" cheap scan should not be presented as a perfect full deliverability audit.

This is the kind of detail that matters when an agent is summarizing results for a human. The agent should say what was checked, not just repeat a number.

A small example response

{
  "domain": "example.com",
  "score": 69,
  "maxScore": 80,
  "grade": "C",
  "confidence": 83,
  "checks": ["mx", "spf", "dkim", "dmarc", "age", "rdns"],
  "fixes": ["rdns", "mx"]
}

The real payload includes the record values and reasons behind each status. That is what makes the result useful to an agent: it can explain the finding instead of only returning a grade.

When this is useful

An agent onboards a new client domain and checks it before sending.
A developer asks an IDE agent to sanity-check a domain from a README.
A support assistant flags a customer domain with no SPF or DMARC.
A sales agent checks a prospect's domain before recommending an email setup.

When it is not enough

This is not a replacement for a full deliverability audit. It does not inspect mailbox placement, content, sending reputation, or live blacklist listings. It is a fast, cheap first pass.

If you need the complete view, use the web scanner:

Full scan: mailers.email/scan
API and MCP docs: mailers.email/api/scan
GitHub README and examples: github.com/xusteve/mailers-scan-api

If you connect it to an agent, I would like to hear what the agent does with the results — especially where it overstates the score or misses a fix-first priority.

Building an anonymous email-domain scan API on Cloudflare Workers

xusteve — Mon, 02 Nov 2026 06:47:01 +0000

Mailers.email exposes domain health checks as both a REST API and an MCP server. This post covers the API contract, the Cloudflare Worker request path, caching, rate limiting and the design decisions behind no-key access.

The short version: POST /v1/scan accepts a domain, runs a small set of DNS checks through Cloudflare DoH, returns a structured score plus fix-first findings, and requires no account or API key. The public API is intentionally cheaper than the full web scan: blacklist checks are excluded.

Why email-domain checking works well as an API

Email configuration is mostly public DNS. MX, SPF, DKIM, DMARC, reverse DNS and domain age can all be inspected without mailbox access.

That makes the core check a good fit for a small, read-only API:

one domain in
a handful of DNS lookups out
a deterministic result that another service or agent can explain

It is also safe to automate. There is no message content, no mailbox login and no sending capability.

Contract of `POST /v1/scan`

curl -X POST https://api.mailers.email/v1/scan \
  -H "Content-Type: application/json" \
  -d '{"domain":"example.com"}'

A successful response contains the domain, score, grade, confidence, individual checks and a fixes array:

{
  "ok": true,
  "data": {
    "domain": "example.com",
    "score": 69,
    "maxScore": 80,
    "grade": "C",
    "confidence": 83,
    "checks": ["mx", "spf", "dkim", "dmarc", "age", "rdns"],
    "fixes": ["rdns", "mx"]
  },
  "meta": {
    "cached": false,
    "quota": {
      "limit": 60,
      "remaining": 59,
      "scope": "hour"
    }
  }
}

The real response includes the record values and reasons for each check; the example is abbreviated.

About `maxScore`

The public API returns maxScore: 80.

This is deliberate. The score is normalized against the checks that actually ran. DNSBL checks are excluded from the public API, so a perfect public scan should not be presented as a perfect full deliverability audit.

That distinction matters when another system summarizes the result. A score should come with the scope it was measured against.

Request flow: Cloudflare Worker + DoH

The API is served by a Cloudflare Worker.

At a high level:

POST /v1/scan
  -> validate domain
  -> check IP rate limit
  -> check KV cache by domain
  -> query Cloudflare DoH for DNS records
  -> build checks and score
  -> cache result for 24 hours
  -> return JSON

The Worker uses Cloudflare's DNS-over-HTTPS resolver for live DNS. No separate DNS service sits in the middle.

The scan currently covers:

MX records
SPF record and lookup count
DKIM at common selectors
DMARC policy
reverse DNS / PTR
domain age via RDAP where available

The checks are deliberately bounded. This is not a full inbox-placement or reputation test.

24-hour cache for the same domain

DNS records do not change every minute. Caching the result by domain keeps repeated checks cheap and avoids hammering upstream resolvers.

The cache is stored in Cloudflare KV with a 24-hour TTL. Cached requests still count toward the rate limit, but they skip the DNS work. The response includes meta.cached so callers know whether they received a cached result.

The cache is per domain, not per user. There is no account or API key to associate with a query.

Rate limiting: atomic counters with Durable Objects

Anonymous APIs need a limit that works under concurrency.

An ordinary read-modify-write sequence in KV is not atomic: two simultaneous requests can read the same counter and both write the same increment. For a 60/hour limit, that is a quiet way to let bursts through.

The scan API uses a Durable Object as a per-IP serialization point for counter updates. The object handles the counter operation, so increments are atomic. The API uses the same mechanism for the shared scan budget.

The public scan limit is:

60 requests/hour/IP
shared by the REST scan, MCP scan_domain and the interactive scan
no API key or account
HTTP 429 when exceeded

The separate free DNS tool pages have their own stricter limit of 30/minute and 300/hour. The scan API and the tool pages are related products, but they are not the same quota.

Why the API excludes DNSBL

Blacklist checks are 32+ additional DNS queries per domain. That is a different cost profile from the six cheap checks above.

Keeping DNSBL out of the public API has three benefits:

A scan stays fast and inexpensive.
A single scan_domain MCP call does not fan out into dozens of queries.
The API's scope stays honest: it reports DNS configuration, not live reputation.

The full blacklist scan lives in the web app at mailers.email/scan. The API documentation also states that the public scan does not include blacklist checks.

MCP: `scan_domain`

The same cheap scan is available as a remote MCP server:

{
  "mcpServers": {
    "mailers": {
      "url": "https://mcp.mailers.email/mcp"
    }
  }
}

It exposes exactly one tool:

scan_domain

The tool is read-only. It does not access a mailbox, send email or require credentials. This keeps the permission model narrow enough for an agent to use without a long explanation.

One implementation detail: MCP calls run a fresh scan rather than using the REST API's 24-hour cache. The REST endpoint is optimized for repeated checks; the MCP path is optimized for an agent asking once during a task.

I wrote a separate MCP-focused post with client configuration and agent examples:

Giving AI agents an email deliverability check with MCP

Error handling and API behavior

The API returns JSON for normal application errors rather than an HTML error page.

Expected behavior:

400 for an invalid or missing domain
405 for a non-POST request
410 for retired API routes; only POST /v1/scan remains public
429 when the IP budget is exhausted
502 when an upstream scan cannot complete

The health endpoint is available at https://api.mailers.email/health.

Privacy and limits, stated plainly

This is a hosted service, not a self-hosted open-source scanner.

What is true:

no account and no API key
DNS-based checks only
per-IP rate limits
same-domain results cached for 24 hours
no mailbox access and no email sending

What is not claimed:

no inbox-placement guarantee
no permanent "no data stored" claim
no blacklist check in the public API
no 100-point full audit score

Precise limits are more useful than vague promises.

What I would improve next

The current design is deliberately small. The next useful steps would be:

Publish an OpenAPI file and client examples.
Add a small response-schema version field.
Add more granular error details for DNS timeouts.
Keep the public API cheap while leaving heavier reputation checks in the web scanner.

Try it

API and MCP docs: mailers.email/api/scan
Full web scanner: mailers.email/scan
GitHub README and examples: github.com/xusteve/mailers-scan-api
Status: mailers.email/status

If you build something with the API or the MCP server, I would like to hear what worked and what was missing.

Zero-Cost Uptime Monitoring + Status Page on Cloudflare's Free Tier

xusteve — Sun, 16 Aug 2026 14:51:16 +0000

Zero-Cost Uptime Monitoring + Status Page on Cloudflare's Free Tier

Monitoring your websites shouldn't cost money or require a VPS. Most uptime tools need a server, a database, or a paid plan — even small hobby projects end up with a $5/mo bill just to check if a site is up.

MonitorFlare is a self-hosted uptime monitoring platform with a beautiful public status page that runs entirely on Cloudflare's free tier: Workers + D1 + Pages. No server, no VPS, no monthly costs — and it deploys in about 60 seconds with a one-click button.

It's an enhanced fork of Uptime-Monitor (MIT), with a Vue 3 frontend, PWA support, and i18n in 9 languages.

Why MonitorFlare

	MonitorFlare	Typical hosted monitor
Cost	$0/month (Cloudflare free tier)	$5–50/month
Deploy	One click, no CLI	Signup + config
Status page	Built-in, PWA, RSS/email subscribe	Often extra
Notifications	9 channels	1–3 channels

What it monitors

HTTP/HTTPS — GET/POST/PUT/HEAD, custom headers, body, keyword validation
DNS — A/AAAA/CNAME/MX/TXT/NS via DoH
TCP ports — via the Workers TCP Socket API
SSL certificate & domain expiry — via crt.sh + rdap.org
Error-rate thresholds and consecutive-failure escalation

Notifications: 9 channels

DingTalk · WeCom (WeChat Work) · Feishu (Lark) · Telegram · Slack · Discord · ntfy · generic Webhook — plus email with 5 providers (Resend, SendGrid, Mailgun, Postmark, AWS SES).

Status page

Tag groups, incident timeline, scheduled maintenance
Email subscription for incident updates + RSS/Atom feed
Custom branding, dark/light themes
PWA — installable, offline-ready

Internationalization

9 languages: English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Deutsch · Français · Italiano · Español. Configurable timezone for all timestamps and alerts.

One-click deploy

Click the Deploy button above
Sign in to Cloudflare
Set ADMIN_API_KEY (your admin password)
Done — the D1 schema auto-creates on first visit

Or use GitHub Actions CI/CD, or manual wrangler deploy — all documented in the README.

Live demo

Status page: https://monitorflare.csr.plus
Public API: GET /api/status returns JSON for integrations
Feed: GET /feed.xml

Open source

MIT licensed, fully self-hosted, no telemetry. Fork it, deploy it, own your monitoring.

⭐ Star MonitorFlare on GitHub

Disclosure: I built MonitorFlare.

Generate a Certificate Signing Request with curl — No OpenSSL Needed

xusteve — Sat, 15 Aug 2026 13:58:57 +0000

Generate a Certificate Signing Request with curl — No OpenSSL Needed

If you've ever ordered an SSL/TLS certificate, you know the drill: fire up a terminal, type openssl req -new ..., and pray you get the flags right. One wrong -subj format, one forgotten SAN, and your certificate authority sends the request back with a cryptic error.

There's a simpler way: generate a Certificate Signing Request (CSR) with a single curl command — no OpenSSL, no config files, no interactive prompts.

What is a CSR, really?

A CSR is just a block of encoded text (PKCS#10) that contains:

Your public key
Your domain name(s) — the Common Name (CN) and Subject Alternative Names (SANs)
Optional organization details (O, OU, C, ST, L) for OV/EV certificates

You send it to a Certificate Authority (CA) like Let's Encrypt, DigiCert, or Sectigo. They verify you control the domain, sign a certificate using your public key, and hand it back. Your private key never leaves your machine.

The old way: OpenSSL

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/C=US/ST=California/O=ACME Inc/CN=example.com"

Works, but:

You have to remember the -subj syntax and every flag
Interactive prompts if you forget -subj
Easy to mess up SANs without a config file
Painful inside CI/CD scripts where you want everything automated

The new way: one curl command

The csr.plus API generates a standards-compliant CSR and private key for you. No signup, no API key, no account:

curl -X POST https://csr.plus/api/generate \
  -H "Content-Type: application/json" \
  -d '{"common_name": "example.com"}'

That's the whole thing. Here's what comes back:

{
  "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIB...",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIE...",
  "algorithm": "RSA-2048",
  "created_at": "2026-08-15T10:00:00Z"
}

Paste the csr into your CA's enrollment form, keep the private_key safe, done.

Real-world examples

With SANs (multi-domain certificates)

curl -X POST https://csr.plus/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "common_name": "example.com",
    "sans": ["www.example.com", "api.example.com"]
  }'

ECDSA keys

curl -X POST https://csr.plus/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "common_name": "example.com",
    "key_type": "ecdsa",
    "key_size": "P-256"
  }'

In a CI/CD pipeline (Shell + jq)

curl -s -X POST https://csr.plus/api/generate \
  -H "Content-Type: application/json" \
  -d '{"common_name": "example.com", "sans": ["www.example.com"]}' \
  | jq -r .csr > example.com.csr

curl -s -X POST https://csr.plus/api/generate \
  -H "Content-Type: application/json" \
  -d '{"common_name": "example.com", "sans": ["www.example.com"]}' \
  | jq -r .private_key > example.com.key

In Python

import requests

resp = requests.post(
    "https://csr.plus/api/generate",
    json={"common_name": "example.com", "sans": ["www.example.com"]},
)
resp.raise_for_status()
data = resp.json()

open("example.com.csr", "w").write(data["csr"])
open("example.com.key", "w").write(data["private_key"])

Verify the result

Never trust blindly — verify the CSR locally before submitting:

openssl req -noout -text -verify -in example.com.csr

You should see verify OK and your subject fields. (OpenSSL is still useful for verifying — you just don't need it to generate anymore.)

Is it private? Here's the security model

The obvious question: "my private key is generated on their server?"

Here's how csr.plus handles it:

Zero storage — key pairs are generated in server memory and destroyed immediately after the response
Zero logging — generation never writes logs
HTTPS only with Cache-Control: no-store
Optional passphrase — encrypt the private key (PKCS#8) before it's returned to you
Rate limited — 10 requests/minute/IP to keep the service free

Honest caveat: like any online CSR tool, this is designed for development, testing, and automation workflows. For production certificates, generate the key offline on your own hardware. The API docs say the same thing.

Why I built this

The repo is open source — csr-plus-generator. The goal is simple: make CSR generation boring. One command, no signup, no flags to memorize, works from any CI/CD pipeline.

Check out the other free tools too:

CSR Generator — generate CSRs right in your browser
SSL Certificate Checker — inspect any domain's cert: issuer, expiry, chain
CSR & Certificate Decoder — decode and inspect any CSR
SSL Expiry Monitor — 24/7 expiry monitoring with email alerts

Happy certifying 🎉

We are live on Product Hunt today! If CSR.plus has been useful for you, an upvote would mean a lot:

Upvote CSR.plus on Product Hunt

The Ultimate WordPress Security Checklist for 2026

xusteve — Sun, 21 Jun 2026 15:45:41 +0000

The Ultimate WordPress Security Checklist for 2026

WordPress powers over 43% of all websites — making it the most popular CMS in the world and, by extension, the most targeted platform for attackers. In 2024 alone, over 24,000 WordPress plugins were flagged for security vulnerabilities. If you're running a WordPress site, you need a systematic approach to security, not a reactive one.

This checklist covers everything you need to lock down your WordPress installation — from basic hardening to advanced monitoring. At the end, we'll show you how to automate most of these checks.

1. Core WordPress Hardening

Keep Everything Updated

WordPress core: Enable auto-updates for minor releases; test major releases on staging first
Themes & plugins: Delete unused ones. Outdated plugins are the #1 attack vector — 56% of known vulnerabilities come from third-party plugins
PHP version: Run PHP 8.1+ (7.4 reached EOL in November 2022 and has known security holes)

Strengthen Authentication

Enforce strong passwords for all users (use a password manager)
Enable Two-Factor Authentication (2FA) — the single most effective step against brute force
Limit login attempts — plugins like Wordfence or CSF (ConfigServer Security & Firewall) can block IPs after 3-5 failed attempts
Change the default "admin" username — if you're still using it, create a new admin and delete the old one

Secure wp-config.php

// Move wp-config.php one directory above the web root if possible
// Add these lines:
define('DISALLOW_FILE_EDIT', true);       // Disable file editor in admin
define('AUTOSAVE_INTERVAL', 300);          // Reduce autosave frequency
define('WP_POST_REVISIONS', 5);            // Limit post revisions

2. File System & Server Security

Protect Sensitive Files

Block access to these files via .htaccess or nginx config:

wp-config.php — contains DB credentials
.git/ and .env — if using Git deployment
readme.html and license.txt in the root — these leak your WordPress version
XML-RPC if not needed (often used for DDoS amplification)

Directory Permissions

wp-config.php: 400 or 440 (read-only)
wp-content/: 755 (directories), 644 (files)
Never use 777 — it's an open invitation

Disable Directory Browsing

Add to .htaccess:

Options -Indexes

Implement a Web Application Firewall (WAF)

A WAF sits in front of your site and blocks malicious requests before they reach WordPress. Options:

Cloudflare (free tier available) — blocks SQL injection, XSS, and known bad bots
Wordfence — WordPress-native WAF with real-time threat defense feed
Sucuri — CDN + WAF with DDoS protection

3. Database Security

Change the Table Prefix

The default wp_ prefix is well-known. Change it during installation, or use a plugin like WP-DBManager to rename it on an existing site.

Regular Backups (3-2-1 Rule)

3 copies of your data
2 different media (server + cloud)
1 offsite (Google Drive, Dropbox, S3)
Recommended: UpdraftPlus, BlogVault, or your host's built-in backup

Limit Database Access

Create a dedicated MySQL user with only the necessary privileges
Never use the root MySQL user for WordPress

4. SSL/TLS & HTTPS

Install an SSL Certificate

Free options: Let's Encrypt (most hosts support one-click install)
Verify HTTPS is enforced site-wide (301 redirect HTTP → HTTPS)
Check for mixed content warnings (Chrome DevTools → Console)

HSTS Header

Add to your server config:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

5. Content Security Policy (CSP)

A CSP header tells browsers which resources are allowed to load. Start with a report-only mode:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

Then monitor the reports and tighten over time.

6. Monitoring & Alerts

Uptime Monitoring

UptimeRobot (free, 50 monitors)
StatusCake — also monitors SSL expiry

Change Detection

WPScan — checks if your WordPress version/plugins have known vulnerabilities
WordPress Site Health (built-in, Tools → Site Health)

Security Logging

Enable WordPress debug logging (WP_DEBUG_LOG in wp-config.php) and review regularly. For production, use a plugin like WP Activity Log.

7. Common Mistakes That Undermine Everything

Mistake	Why It's Dangerous	Fix
Using `admin` as username	Brute force bots target it first	Create new admin, delete `admin`
No 2FA	Credential stuffing is rampant	Use Wordfence 2FA or WP 2FA plugin
Outdated PHP	PHP 7.x has unpatched CVEs	Upgrade to PHP 8.1+
Nulled plugins/themes	Often contain backdoors	Buy from official sources only
No backups	Ransomware can wipe everything	Automated offsite backups, test restores
XML-RPC enabled	Used for DDoS and brute force	Disable if not using Jetpack/mobile apps

8. Automate Your Security Audit

Manually checking all 37+ security items above every month is unrealistic. That's why we built wpSEO — a free tool that automates WordPress security scanning:

✅ 37 security checks — version exposure, security headers, WAF, 2FA, PHP version, and more
✅ 125+ total checks combining security + SEO in one report
✅ No signup required — paste your URL and get results in seconds
✅ 10 languages — available in English, Chinese, Japanese, Korean, German, Russian, Arabic, French, Spanish, Portuguese
✅ PDF reports — export and share with your team or clients
✅ Actionable fixes — every check includes a "how to fix" description

Try it free: https://app.wpseo.help

Final Word

WordPress security isn't a one-time setup — it's ongoing hygiene. The checklist above covers the fundamentals. Run through it quarterly, stay on top of updates, and use an automated scanner to catch what you miss.

Your WordPress site is your business. Lock it down.

Got questions about WordPress security? Drop a comment or reach out — happy to help.

digkeywords.net - SEO Keyword Tool

xusteve — Thu, 15 Oct 2020 11:03:46 +0000

All in One SEO KeyWord Research Tool
https://digkeywords.net

Google keyword tool
Bing keyword tool
Amazon keyword tool
eBay keyword tool
YouTube keyword tool
Yahoo keyword tool
Wikipedia keyword tool

FREE All In One SEO Keyword Research Tool that helps you to get the top keyword ideas or long tail keywords from most popular websites such as Google, Bing, Yahoo, Amazon, Ebay, Youtube, Wikipedia and checks the domain names already registered or still available of those keywords to find the BEST Keyword Domain Names for you.

You also can use our Free Google Keyword Rank Checker to Check Your Keyword Positions in Google Search Results for your sites.
Why Do You Need Dig Keywords Tool?

Dig KeyWords Tool is the BEST alternative keyword research tool to Google keyword planner and other keyword research tools
Dig KeyWords Tool helps to find long-tail keywords that are ignored by you or your competitors!
Dig KeyWords Tool helps you find the right keywords for SEO and content creation.
Dig KeyWords Tool helps you dig the relevant keywords that you target with your CPC ads!

Whoisdomainthis - Domain Statistic Search Tool

xusteve — Sat, 03 Oct 2020 23:59:29 +0000

Free Domain Statistic Search Tool shows you related information about domain name such as WHOIS record/DNS records, number of pages indexed in Search Engines (Google, Yahoo, Bing), Server IP and Geo location, Alexa statistic, Like count and more...

WHOIS Lookup Tool
https://whoisdomainthis.com/whois.html

DNS Record Lookup
https://whoisdomainthis.com/dns.html

IP Address Lookup
https://whoisdomainthis.com/ip.html

What Is My Public IP Address?
https://whoisdomainthis.com/whatismyip.html

Favicon Generator
https://whoisdomainthis.com/favicon/

DNS.glass checks the health and configuration & provides DNS report and mail servers report.

xusteve — Sat, 03 Oct 2020 23:54:18 +0000

DNS.glass checks the health and configuration & provides DNS report and mail servers report.

And provides suggestions to fix and improve your domain DNS, with references to protocols’ official documentation.

https://dns.glass/google.com
https://dns.glass/name.com
https://dns.glass/bluehost.com
https://dns.glass/dns.glass

TempMail - Forget about spam, advertising mailings, hacking and attacking robots.

xusteve — Sat, 03 Oct 2020 23:47:05 +0000

https://TempMail.at

Free Temporary Email Address- tempmail, 10minutemail, throwaway email, fake-mail or trash-mail!

Forget about spam, advertising mailings, hacking and attacking robots. Keep your real mailbox clean and secure. tempmail.at provides free temporary, secure, anonymous, free, disposable email address.

DEV Community: xusteve

Giving AI Agents an Email Deliverability Check with MCP

One tool: scan_domain

Connect an MCP client

Why only one tool?

Limits and caching

What the score means

A small example response

When this is useful

When it is not enough

Building an anonymous email-domain scan API on Cloudflare Workers

Why email-domain checking works well as an API

Contract of POST /v1/scan

About maxScore

Request flow: Cloudflare Worker + DoH

24-hour cache for the same domain

Rate limiting: atomic counters with Durable Objects

Why the API excludes DNSBL

MCP: scan_domain

Error handling and API behavior

Privacy and limits, stated plainly

What I would improve next

Try it

Zero-Cost Uptime Monitoring + Status Page on Cloudflare's Free Tier

Zero-Cost Uptime Monitoring + Status Page on Cloudflare's Free Tier

Why MonitorFlare

What it monitors

Notifications: 9 channels

Status page

Internationalization

One-click deploy

Live demo

Open source

Generate a Certificate Signing Request with curl — No OpenSSL Needed

Generate a Certificate Signing Request with curl — No OpenSSL Needed

What is a CSR, really?

The old way: OpenSSL

The new way: one curl command

Real-world examples

With SANs (multi-domain certificates)

ECDSA keys

In a CI/CD pipeline (Shell + jq)

In Python

Verify the result

Is it private? Here's the security model

Why I built this

The Ultimate WordPress Security Checklist for 2026

The Ultimate WordPress Security Checklist for 2026

1. Core WordPress Hardening

Keep Everything Updated

Strengthen Authentication

Secure wp-config.php

2. File System & Server Security

Protect Sensitive Files

Directory Permissions

Disable Directory Browsing

Implement a Web Application Firewall (WAF)

3. Database Security

Change the Table Prefix

Regular Backups (3-2-1 Rule)

Limit Database Access

4. SSL/TLS & HTTPS

Install an SSL Certificate

HSTS Header

5. Content Security Policy (CSP)

6. Monitoring & Alerts

Uptime Monitoring

Change Detection

Security Logging

7. Common Mistakes That Undermine Everything

8. Automate Your Security Audit

Final Word

digkeywords.net - SEO Keyword Tool

Whoisdomainthis - Domain Statistic Search Tool

DNS.glass checks the health and configuration & provides DNS report and mail servers report.

TempMail - Forget about spam, advertising mailings, hacking and attacking robots.

One tool: `scan_domain`

Contract of `POST /v1/scan`

About `maxScore`

MCP: `scan_domain`