Is your domain's email authentication actually right?

One check reads a domain's SPF, DKIM, DMARC, MX and DNSSEC records, scores what it finds, and gives you the exact record to publish for anything that's broken. Free. No signup.

Enter a domain, not an email address. 5 checks per minute per address; automation belongs on the API. The domain you check and your IP are logged for abuse prevention (details).

How it earns trust: every check is implemented from the RFCs, tested against a corpus of deliberately broken domains, and the tool never asserts what it didn't measure — if a signal can't be verified, it says so instead of guessing. How the results are verified.

What one check covers

SPF

Record present and syntactically valid, the RFC 7208 ten-lookup limit counted for real (includes and redirects followed), multiple-record and PermError conditions caught, and the all qualifier graded: -all passes, ~all and ?all warn.

DKIM

Probes 36 common selectors and validates any key it finds: revoked (empty p=), truncated or undecodable keys, and wildcard catch-alls are called out. A selector we can't guess is reported as not detected, never as a failure.

DMARC

Policy, subdomain policy, pct, alignment modes and reporting address. Flags a subdomain policy weaker than the domain policy and a pct below 100. Remediation is staged: monitor first, then quarantine, then reject.

MX & null MX

MX records resolved to addresses; a null MX (RFC 7505) is recognised as a deliberate no mail here and the domain is scored on how well it's locked against spoofing instead.

DNSSEC

Whether the zone is signed and whether a validating resolver actually validates it. Reported separately so a signed-but-broken chain isn't mistaken for a good one.

Honest scoring

Two rubrics, chosen by what the domain is (a sender or a declared non-sender). The score separates broken from working; it is not a beauty contest, and it says so in the response.

The API: verify a customer's DNS at onboarding

If your product sends mail on behalf of customers, you already know the failure mode: they add your DKIM selector to the wrong host, forget your SPF include, or never publish DMARC, and their mail silently lands in spam. MailPosture answers the two questions an onboarding flow actually needs answered, in one request.

GET https://api.mailposture.dev/v1/domain?domain=customer.com
    &dkim_selector=yourselector          # is OUR key live on their domain? (one query, deterministic)
    &expected_spf_include=_spf.yourapp.com  # did they add OUR include?
    &submission=true                       # 587/465 submission TLS with real certificate validation
X-API-Key: your-key

Every check carries the same shape

"spf": {
  "status": "fail",              // pass | warn | fail | info | unknown | error
  "reason": "spf_multiple",      // stable code you can switch on
  "issue": "Two SPF records found; receivers treat this as PermError.",
  "remediation": "Merge the mechanisms of ALL records into one v=spf1 ...",
  "record": ["v=spf1 -all", "v=spf1 include:_spf.google.com -all"],
  "expected_spf_include": { "value": "_spf.yourapp.com", "present": false }
}

Remediation is safe to show a customer. Staged advice a non-expert can follow without breaking their mail. Never "jump to -all".
A broken target is a finding, not an error. NXDOMAIN, SERVFAIL and timeouts come back as 200 with a structured error object. 4xx means your input; 5xx means our fault.
Nothing asserted that wasn't measured. DKIM you can't enumerate is unknown and excluded from the score, and a top score is capped at 90 until the selector is verified.
Fast. Typically 0.3 to 1 s. Pinned validating resolvers, so results are the same from every region.

Call it from anything

curl -s "https://api.mailposture.dev/v1/domain?domain=customer.com&dkim_selector=s1&expected_spf_include=_spf.yourapp.com" \
  -H "X-API-Key: $MAILPOSTURE_KEY" | jq '.dkim.status, .spf.expected_spf_include.present'

import os, requests

r = requests.get(
    "https://api.mailposture.dev/v1/domain",
    params={"domain": "customer.com",
            "dkim_selector": "s1",
            "expected_spf_include": "_spf.yourapp.com"},
    headers={"X-API-Key": os.environ["MAILPOSTURE_KEY"]},
    timeout=20,
).json()

ready = (r["dkim"]["status"] == "pass"
         and r["spf"]["expected_spf_include"]["present"])
if not ready:
    show_customer(r["dkim"].get("remediation"),
                  r["spf"].get("expected_include_remediation"))

const url = new URL("https://api.mailposture.dev/v1/domain");
url.search = new URLSearchParams({
  domain: "customer.com",
  dkim_selector: "s1",
  expected_spf_include: "_spf.yourapp.com",
});
const r = await fetch(url, {
  headers: { "X-API-Key": process.env.MAILPOSTURE_KEY },
}).then(res => res.json());

const ready = r.dkim.status === "pass"
           && r.spf.expected_spf_include.present;

Keys are issued through the RapidAPI listing (pricing below). The free checker on this page is the same engine with the onboarding parameters switched off. Questions or a wrong result: help@mailposture.dev.

Pricing

Usage tiers. Core posture is free to evaluate; the onboarding parameters and the submission-TLS check are what a sender-onboarding product is actually paying for.

Tier	Per month	Requests / month	Rate	What you get
Free	$0	100	5 / min	Core posture: SPF, DKIM, DMARC, MX, DNSSEC, score, remediation. For evaluation and small tools.
Starter	$12	3,000	10 / min	Everything in Free plus `dkim_selector`, `expected_spf_include` and `submission=true`. The onboarding tier.
Pro	$49	40,000	30 / min	Everything, higher quota. Weekly re-checks across a customer base.
Ultra	$149	250,000	60 / min	High-volume onboarding platforms. Metered overage above quota.

Billing and keys are handled by RapidAPI; the listing link goes here when it is live. Cancel any time; nothing is stored on our side that you would lose.

FAQ

What does the score mean?

It depends on what the domain is. A sender gets a sender-readiness score: can it send authenticated, aligned mail that receivers trust? Weights are DMARC 30, SPF 25, DKIM 20, MX 20, DNSSEC 5, as a percentage of the weight we could actually verify. A domain with a null MX is a declared non-sender and gets a hardening score instead: is it locked against spoofing? The two are not comparable, and the response says which one you're looking at.

SPF, DMARC and MX are 75 of the 100 points, so any domain with the basics in place scores 75 or more. The score reliably separates broken from working. It is not a fine ranking of good versus excellent; act on the findings, not on small differences.

Is the advice safe to follow without an expert?

That is the design goal and a hard gate on every remediation string. Advice is staged (DMARC starts at p=none with reporting, then tightens), never tells you to delete a record that might carry a real sender, and never says "just set -all". Every remediation is reviewed against one question: "could a non-expert follow this blind and break their mail?" If you find one that fails that test, it's a bug.

Why does it say DKIM is "not detected" when I know I have DKIM?

DKIM keys live under a selector name that only you and your provider know; DNS gives no way to list them. The free checker tries 36 common selectors. If yours isn't among them the result is unknown, which is excluded from the score rather than counted against you, and the response shows what the score would be with DKIM verified. The API's dkim_selector parameter makes the check deterministic with a single query.

Does it test STARTTLS or blacklists?

The free checker does no live SMTP connections. Blacklist status of the primary MX addresses is checked over DNS (Spamhaus and similar) and reported when the lookup is conclusive. The API's submission=true checks the domain's 587/465 submission service with real certificate validation, which is the TLS signal that matters for a sender. Live port-25 STARTTLS on inbound MX is deliberately not a headline feature: it measures the receiving provider, not the sender's configuration.

What do you log and store?

For each free check: the domain you entered (after validation), your IP address, the outcome and the response time. This is kept in the server log for up to 30 days, purely for abuse prevention. Results are cached for 15 minutes so repeated checks of the same domain don't re-query its nameservers. No cookies, no analytics, no third-party scripts, and the page only talks to its own origin.

Why the rate limits, and what stops someone abusing this?

One check sends roughly fifty DNS queries toward the target's nameservers, so an open checker is a lookup amplifier by construction. This one is bounded on four independent axes: per address (5 a minute, 40 an hour, with a cooling-off period for repeat offenders), per target domain across all users (so rotating subdomains doesn't help), globally (an absolute ceiling on what the checker can generate), and by concurrency. Anything wanting more than that belongs on the API, which has its own quotas and an accountable key.

How do I know the results are right?

Three things. The checks are implemented from the RFCs (7208 for SPF, 7489 for DMARC, 6376 for DKIM, 7505 for null MX), not from a list of common mistakes. They are tested against a corpus of deliberately broken domains — duplicate SPF, PermError lookup counts, truncated DKIM keys, weak subdomain policies — so each diagnosis and each remediation string is exercised against real DNS, not mocked. And the contract is never assert what wasn't measured: a DKIM selector we can't find is reported as unknown and excluded from the score, a mail server that refuses our connection is reported as refused rather than as "no TLS", and a top score is withheld until the last signal is verified.

What that doesn't buy you is infallibility. A wrong result is a bug we want to hear about: write to help@mailposture.dev.