Łukasz Gogolin

Posted on May 9

One API Call to Audit Any Domain's Email Security

#security #webdev #api #devops

You know the drill. A customer complains their transactional emails land in spam. Or a B2B trial signup uses a throwaway address. Or someone asks "do we have DMARC set up correctly?" and you open ten browser tabs to find out.

I built MailSec to replace that entire workflow with one API call.

The problem

Email infrastructure is deceptively complex:

SPF has a hard 10-lookup limit that silently breaks when you add one too many include:
DMARC with p=none does literally nothing — but most teams ship it and assume they're protected
DKIM selectors vary by provider (google, selector1, k1, s1) and you need to guess which one to check
Spamhaus listings can tank your deliverability for days before anyone notices
DNSSEC is either there or it isn't, and most tools make you check separately

The information is all in DNS, but it's scattered across different record types, different query tools, and different mental models. You end up juggling dig, MXToolbox, Spamhaus lookup, and a DMARC analyzer — just to answer "is this domain's email OK?"

One request, full picture

curl https://prod.api.market/api/v1/fivetag-systems/mailsec/v1/audit/cloudflare.com \
  -H "x-api-market-key: YOUR_KEY"

Response:

{
  "domain": "cloudflare.com",
  "spf": {
    "present": true,
    "valid": true,
    "record": "v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all",
    "lookupCount": 7
  },
  "dmarc": {
    "present": true,
    "valid": true,
    "record": "v=DMARC1; p=reject; pct=100; rua=mailto:...@dmarc-reports.cloudflare.net,mailto:rua@cloudflare.com",
    "policy": "reject",
    "subdomainPolicy": "reject",
    "pct": 100,
    "rua": [
      "mailto:...@dmarc-reports.cloudflare.net",
      "mailto:rua@cloudflare.com"
    ]
  },
  "dkim": { "present": true, "selector": "k1", "valid": true },
  "dnssec": { "enabled": true, "valid": true },
  "mx": {
    "present": true,
    "redundant": true,
    "records": [
      { "host": "mxa-canary.global.inbound.cf-emailsecurity.net.", "priority": 5 },
      { "host": "mxb-canary.global.inbound.cf-emailsecurity.net.", "priority": 5 },
      { "host": "mxa.global.inbound.cf-emailsecurity.net.", "priority": 10 },
      { "host": "mxb.global.inbound.cf-emailsecurity.net.", "priority": 10 }
    ]
  },
  "score": 100,
  "grade": "A",
  "blacklists": { "dblListed": false, "zenListed": false },
  "verdict": "READY",
  "mtaSts": {
    "present": false,
    "issues": ["mta-sts: no DNS record found"]
  },
  "tlsRpt": {
    "present": false,
    "issues": ["tlsrpt: no record found"]
  }
}

Cloudflare scores 100/A. SPF with 7 lookups (under the limit of 10), DMARC at reject with full reporting, DKIM present, DNSSEC valid, redundant MX, clean blacklists. Verdict: READY.

Now try a domain that doesn't have its act together and you'll see the score drop, issues appear, and the verdict shift to CAUTION or BLOCKED.

What's behind the score

The audit scores five components out of 100:

Check	Max points	What it measures
SPF	20	Valid record, `all` mechanism present, lookup count under 10
DMARC	30	Present, enforced (`quarantine`/`reject`), reporting configured
DKIM	20	Key found at a known selector
DNSSEC	20	DS record present, chain of trust valid
MX	10	MX records exist, redundant hosts

Grades: A (90+), B (70+), C (50+), D (30+), F (<30).

DMARC is weighted heaviest because it's the single biggest factor in whether spoofed mail gets through. A domain with p=none is essentially unprotected — MailSec won't call that "ready."

MTA-STS, TLS-RPT, and BIMI are included in the audit response for visibility but are informational only — they don't affect the score. Adoption is still too low to penalize domains without them.

Beyond the full audit

You don't always need everything. Each check has its own endpoint:

# Just SPF
GET /v1/spf/{domain}

# Just DMARC policy
GET /v1/dmarc/{domain}

# DKIM — auto-probes common selectors, or pass ?selector=google
GET /v1/dkim/{domain}

# MTA-STS — DNS record + HTTPS policy file (RFC 8461)
GET /v1/mta-sts/{domain}

# TLS-RPT — reporting URIs for TLS failures (RFC 8460)
GET /v1/tlsrpt/{domain}

# Is this a throwaway email domain?
GET /v1/email/disposable/{domain}

# Full email validation: syntax + DNS + disposable check
GET /v1/email/validate?email=user@example.com

# Deliverability verdict without DNSSEC (focused on inbox placement)
GET /v1/deliverability/{domain}

Real use cases

1. Validate B2B signups

Before provisioning a trial, check if the domain is real, has working email, and isn't disposable:

curl .../v1/email/validate?email=cto@acme-corp.com

{
  "email": "cto@acme-corp.com",
  "syntaxValid": true,
  "domainExists": true,
  "mxPresent": true,
  "disposable": false,
  "deliverable": true
}

Block mailinator.com, guerrillamail.com, and 100k+ other throwaway domains automatically. The disposable check does suffix-walking, so anything.mailinator.com is caught too.

2. Pre-flight transactional sends

About to send a welcome email, invoice, or password reset? Check the recipient's domain first:

curl .../v1/deliverability/their-domain.com

If verdict is BLOCKED, that domain is in Spamhaus — your email probably won't arrive. If CAUTION, their SPF/DMARC is misconfigured and replies/bounces may behave unexpectedly. Only send with confidence when verdict is READY.

3. Customer onboarding — "Check my domain" button

Building a SaaS that sends email on behalf of customers? Give them a one-click domain health check in your onboarding flow. Hit /v1/audit/{domain} and render the results:

"Your DMARC policy is set to none — this means spoofed emails from your domain won't be blocked. Change it to quarantine or reject to protect your brand."

4. Monitor your own domains

Run a daily cron against /v1/audit/bulk with your company's domains. Alert when:

Score drops below a threshold
DMARC policy changes from reject to none
A new Spamhaus listing appears
SPF lookup count crosses 8 (getting close to the limit of 10)

5. Audit third-party vendors

Before integrating with a partner who'll send email on your behalf, check their domain. A vendor with p=none DMARC and no DKIM is a phishing risk to your customers.

Performance

Live DNS lookups on every request (no stale scrapes)
In-process cache respects each record's TTL — repeat queries are <50ms
Full audit fans out all checks in parallel — cold lookups typically 200-800ms
Bulk endpoint audits up to 10 domains in a single request

Get started

MailSec is available on api.market. Sign up, grab your API key, and start auditing domains in minutes.

Try it now — pick any domain you're curious about and see what comes back. You might be surprised by your own.

DEV Community