\n
\n 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.<\/p>\n
I built MailSec to replace that entire workflow with one API call.<\/p>\n
The problem<\/p>\n
Email infrastructure is deceptively complex:<\/p>\n
SPF has a hard 10-lookup limit that silently breaks when you add one too many include:<\/p>\n
DMARC with p=none does literally nothing \u2014 but most teams ship it and assume they’re protected<\/p>\n
DKIM selectors vary by provider (google, selector1, k1, s1) and you need to guess which one to check<\/p>\n
Spamhaus listings can tank your deliverability for days before anyone notices<\/p>\n
DNSSEC is either there or it isn’t, and most tools make you check separately<\/p>\n
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 \u2014 just to answer “is this domain’s email OK?”<\/p>\n
One request, full picture<\/p>\n
curl https:\/\/prod.api.market\/api\/v1\/fivetag-systems\/mailsec\/v1\/audit\/cloudflare.com \\
\n -H “x-api-market-key: YOUR_KEY”<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Response:<\/p>\n
{
\n “domain”: “cloudflare.com”,
\n “spf”: {
\n “present”: true,
\n “valid”: true,
\n “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”,
\n “lookupCount”: 7
\n },
\n “dmarc”: {
\n “present”: true,
\n “valid”: true,
\n “record”: “v=DMARC1; p=reject; pct=100; rua=mailto:…@dmarc-reports.cloudflare.net,mailto:rua@cloudflare.com”,
\n “policy”: “reject”,
\n “subdomainPolicy”: “reject”,
\n “pct”: 100,
\n “rua”: (
\n “mailto:…@dmarc-reports.cloudflare.net”,
\n “mailto:rua@cloudflare.com”
\n )
\n },
\n “dkim”: { “present”: true, “selector”: “k1”, “valid”: true },
\n “dnssec”: { “enabled”: true, “valid”: true },
\n “mx”: {
\n “present”: true,
\n “redundant”: true,
\n “records”: (
\n { “host”: “mxa-canary.global.inbound.cf-emailsecurity.net.”, “priority”: 5 },
\n { “host”: “mxb-canary.global.inbound.cf-emailsecurity.net.”, “priority”: 5 },
\n { “host”: “mxa.global.inbound.cf-emailsecurity.net.”, “priority”: 10 },
\n { “host”: “mxb.global.inbound.cf-emailsecurity.net.”, “priority”: 10 }
\n )
\n },
\n “score”: 100,
\n “grade”: “A”,
\n “blacklists”: { “dblListed”: false, “zenListed”: false },
\n “verdict”: “READY”,
\n “mtaSts”: {
\n “present”: false,
\n “issues”: (“mta-sts: no DNS record found”)
\n },
\n “tlsRpt”: {
\n “present”: false,
\n “issues”: (“tlsrpt: no record found”)
\n }
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
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.<\/p>\n
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.<\/p>\n
What’s behind the score<\/p>\n
The audit scores five components out of 100:<\/p>\n
Check
\nMax points
\nWhat it measures<\/p>\n
SPF
\n20
\nValid record, all mechanism present, lookup count under 10<\/p>\n
DMARC
\n30
\nPresent, enforced (quarantine\/reject), reporting configured<\/p>\n
DKIM
\n20
\nKey found at a known selector<\/p>\n
DNSSEC
\n20
\nDS record present, chain of trust valid<\/p>\n
MX
\n10
\nMX records exist, redundant hosts<\/p>\n
Grades: A (90+), B (70+), C (50+), D (30+), F (<\/p>\n
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 \u2014 MailSec won’t call that “ready.”<\/p>\n
MTA-STS, TLS-RPT, and BIMI are included in the audit response for visibility but are informational only \u2014 they don’t affect the score. Adoption is still too low to penalize domains without them.<\/p>\n
Beyond the full audit<\/p>\n
You don’t always need everything. Each check has its own endpoint:<\/p>\n
# Just SPF
\nGET \/v1\/spf\/{domain}<\/p>\n
# Just DMARC policy
\nGET \/v1\/dmarc\/{domain}<\/p>\n
# DKIM \u2014 auto-probes common selectors, or pass ?selector=google
\nGET \/v1\/dkim\/{domain}<\/p>\n
# MTA-STS \u2014 DNS record + HTTPS policy file (RFC 8461)
\nGET \/v1\/mta-sts\/{domain}<\/p>\n
# TLS-RPT \u2014 reporting URIs for TLS failures (RFC 8460)
\nGET \/v1\/tlsrpt\/{domain}<\/p>\n
# Is this a throwaway email domain?
\nGET \/v1\/email\/disposable\/{domain}<\/p>\n
# Full email validation: syntax + DNS + disposable check
\nGET \/v1\/email\/validate?email=user@example.com<\/p>\n
# Deliverability verdict without DNSSEC (focused on inbox placement)
\nGET \/v1\/deliverability\/{domain}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Real use cases<\/p>\n
1. Validate B2B signups<\/p>\n
Before provisioning a trial, check if the domain is real, has working email, and isn’t disposable:<\/p>\n
curl …\/v1\/email\/validate?email=cto@acme-corp.com<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
{
\n “email”: “cto@acme-corp.com”,
\n “syntaxValid”: true,
\n “domainExists”: true,
\n “mxPresent”: true,
\n “disposable”: false,
\n “deliverable”: true
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Block mailinator.com, guerrillamail.com, and 100k+ other throwaway domains automatically. The disposable check does suffix-walking, so anything.mailinator.com is caught too.<\/p>\n
2. Pre-flight transactional sends<\/p>\n
About to send a welcome email, invoice, or password reset? Check the recipient’s domain first:<\/p>\n
curl …\/v1\/deliverability\/their-domain.com<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
If verdict is BLOCKED, that domain is in Spamhaus \u2014 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.<\/p>\n
3. Customer onboarding \u2014 “Check my domain” button<\/p>\n
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:<\/p>\n
“Your DMARC policy is set to none \u2014 this means spoofed emails from your domain won’t be blocked. Change it to quarantine or reject to protect your brand.”<\/p>\n
4. Monitor your own domains<\/p>\n
Run a daily cron against \/v1\/audit\/bulk with your company’s domains. Alert when:<\/p>\n
Score drops below a threshold
\nDMARC policy changes from reject to none<\/p>\n
A new Spamhaus listing appears
\nSPF lookup count crosses 8 (getting close to the limit of 10)<\/p>\n
5. Audit third-party vendors<\/p>\n
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.<\/p>\n
Performance<\/p>\n
Live DNS lookups on every request (no stale scrapes)
\nIn-process cache respects each record’s TTL \u2014 repeat queries are
\nFull audit fans out all checks in parallel \u2014 cold lookups typically 200-800ms
\nBulk endpoint audits up to 10 domains in a single request<\/p>\n
Get started<\/p>\n
MailSec is available on api.market. Sign up, grab your API key, and start auditing domains in minutes.<\/p>\n
Try it now \u2014 pick any domain you’re curious about and see what comes back. You might be surprised by your own.<\/p>\n