Blog/email-deliverability
1 min read

Buy vs Build a DMARC and Email-Deliverability Auditor

DIY DNS lookups, a deliverability SaaS, or a per-call check: how to audit a domain's SPF, DKIM, and DMARC without overbuying.

Buy vs Build a DMARC and Email-Deliverability Auditor

If you audit a domain's email posture once in a while, buy per call. If you watch a fleet of sending domains around the clock and need alerting, buy a standing SaaS. Building your own SPF, DKIM, and DMARC auditor from raw DNS lookups is the option that looks cheapest and costs the most, because the DNS query is the easy 10 percent and the interpretation is the other 90. This is a fair look at all three, with a comparison table up front, an honest caveat, and a rule for picking.

Copy this line to your agent to check a domain's SPF, DKIM, and DMARC in one call.

set up https://monid.ai/SKILL.md and use api.strale.io to check a domain's deliverability posture

TL;DR

  • The three options are: roll your own DNS lookups, subscribe to a deliverability monitoring SaaS, or pay per call for a managed check like Strale on Monid.
  • What you actually want to know is small and fixed: does the domain have SPF, DKIM, and DMARC, what is the DMARC policy, is anything misconfigured, and how bad is it. A one-call check returns exactly that plus a 0 to 100 score.
  • DIY looks free because dig is free. The cost is the parser and the interpretation: SPF has a 10-lookup limit, DKIM lives at selector-specific names you have to guess, and a p=none DMARC record is technically present and functionally useless.
  • A standing SaaS is worth its monthly floor only if you need continuous monitoring, aggregate report ingestion, and alerts across many domains. For occasional audits you pay for capacity you do not use.
  • Per-call billing fits the bursty shape of auditing: cents when you run it, nothing when you do not. Current magnitudes are at monid.ai/tools.

What a deliverability audit actually has to tell you

Strip away the tooling and the job is narrow. For a given domain you need five facts. Is there an SPF record, and is it valid. Is there a DKIM record for the selectors that domain signs with. Is there a DMARC record, and what is its policy: none, quarantine, or reject. Are the pieces aligned and free of the common misconfigurations. And, netted out, is this domain likely to land in an inbox or a spam folder.

That is a short list, and every option below claims to answer it. The differences are in how much work you do to get there, how much you pay whether you run it or not, and whether the answer is raw records you still have to read or a verdict you can act on.

The comparison, up front

DIY: dig plus a parserDeliverability SaaSPer-call check on Monid
Time to first answerHours to build, then secondsSignup, onboard domainsMinutes
SPFYou fetch the TXT, then enforce the 10-lookup rule yourselfParsed and flaggedParsed and flagged
DKIMYou must know the selector name to query it at allDiscovered or configuredChecked in the same call
DMARC policyYou read p= and interpret itRead and explainedReturned with the record
MisconfigurationsYour own rules to write and maintainBuilt inBuilt in
Single verdictYou invent your own scoringDashboard health score0 to 100 score in the response
Continuous monitoringBuild a scheduler and storageIts core strengthNot its job (call on demand)
Cost shape"Free" tool, real engineering timeFixed monthly floorPer call, cents, zero when idle
Best fitLearning, one domain, full controlMany domains, always-on alertingOccasional or on-demand audits

The row that decides most cases is the last one. Match the billing shape to how often you actually audit, not to which tool has the most features.

Why DIY costs more than it looks

The seductive version of building is one line: dig TXT stripe.com and read the SPF record. The real version is a parser and a pile of domain knowledge that fails quietly if you get it wrong.

SPF is the friendly-looking trap. The record is a single TXT string, so fetching it is trivial, but SPF has a hard limit of 10 DNS lookups when it is evaluated, counting every include, a, mx, and redirect it chains into. A record that reads fine can silently exceed that limit and fail at receiving servers, and you only catch it if your parser recursively counts lookups the way a real mail server does. Writing that correctly is the actual work.

DKIM is worse, because there is no fixed name to query. A DKIM record lives at <selector>._domainkey.<domain>, and the selector is chosen by whatever sends the mail: google, selector1, k1, s1, or something custom. Without the selector you cannot even look it up, so a naive DIY check that finds no DKIM record often means "I did not know where to look," not "there is no DKIM." That false negative is the single most common way a hand-rolled auditor lies to you.

DMARC has its own subtlety. A domain can publish a perfectly valid DMARC record with p=none, which passes a presence check and does nothing: it monitors but never quarantines or rejects a spoof. An auditor that reports "DMARC present, pass" on a p=none domain is technically right and practically useless. You have to read the policy, not just confirm the record exists, and you have to know that none is a starting line, not a finish.

None of this is exotic. All of it is knowledge you either encode yourself and maintain, or rent from someone who already did. The dig call is free. The correct interpretation of what dig returns is the product.

DIY dig on TXT records leaks: SPF forgetting the 10-lookup limit, DKIM on a wrong selector reading as a false none, DMARC p=none read as a pass; one call takes a domain and returns SPF, DKIM, DMARC, a score, and a verdict

When a standing SaaS is the right buy

A dedicated deliverability platform earns its monthly floor when the shape of your problem is continuous, not occasional. If you run many sending domains, want DMARC aggregate (RUA) reports parsed and charted over time, need alerts when a record changes or a new source starts spoofing you, and want a team dashboard, that is exactly what these products are built for, and rebuilding it per call would be silly.

The honest caveat is the billing shape. A SaaS charges its floor every month whether you audit one domain or none. If your real usage is "check a prospect's domain before a cold campaign" or "spot-check our own posture once a quarter," you are paying for standing infrastructure to answer a question you ask occasionally. The features are real; the question is whether your cadence justifies the subscription.

The per-call option, in one call

Between the two extremes sits the shape most audits actually have: bursty and on-demand. You want the answer now, for this domain, and you do not want a subscription or a parser to maintain.

Strale exposes /x402/email-deliverability-check, a single call that takes one domain query parameter and returns SPF, DKIM, DMARC, MX records, blacklist status, and a 0 to 100 deliverability score. It encodes the interpretation the DIY path skips: the lookup counting, the selector discovery, the policy reading. You get the verdict, not a pile of TXT records to parse.

Monid is a pay-per-call data API marketplace: one key and one wallet reach hundreds of external data endpoints without a separate signup per vendor, with the price shown before anything runs. Discovering an endpoint and inspecting its schema are free. Only the run bills the wallet.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More details in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>

More details in the CLI quickstart.

Inspect the schema and price for free, then check one domain:

monid inspect -p api.strale.io -e /x402/email-deliverability-check      # schema + price (free)

monid run -p api.strale.io -e /x402/email-deliverability-check \
  --query '{"domain":"stripe.com"}' -w
# -> SPF, DKIM, DMARC, MX, blacklist status, 0-100 score
#    billed per call, price shown before it ran

The -w flag waits inline and hands the verdict straight back, which is what an agent step or a pre-send check wants. Because it takes query params, you pass --query rather than -i.

How often you audit decides it: once to learn suits DIY dig, many domains always-on suits a deliverability SaaS, occasional or on-demand suits a per-call check on Monid

Cost, reasoned in magnitudes

We do not print rates, because the honest unit depends on your cadence, and live magnitudes are at monid.ai/tools. The reasoning that survives any price change is about shape, not sticker.

The per-call check bills a few cents per domain and drops to zero the moment you stop, so auditing a shortlist of prospect domains before a campaign is a low-single-digit-dollar habit. The SaaS bills a fixed floor every month regardless of usage, which only wins on cost once you audit often enough, across enough domains, that the floor divided by your usage dips below the per-call price. The DIY path has no invoice at all and the highest true cost, because the engineering to count SPF lookups correctly, discover DKIM selectors, and read DMARC policy is real time that recurs every time a standard shifts.

Match the meter to the cadence. On-demand work wants on-demand billing.

One honest caveat

A single deliverability check is a snapshot of DNS at the moment you ran it, and DNS changes. A domain that scores well today can regress tomorrow if someone edits a record, and a per-call check does not watch for that: it answers when you ask. If your requirement is genuinely continuous, that is the case for a monitoring SaaS or your own scheduler on top of the endpoint, not against per-call billing. And no automated score replaces sending real mail: SPF, DKIM, and DMARC being correct is necessary for good deliverability, not sufficient, because content, list hygiene, and IP reputation also decide the inbox. Read the score as "is the domain configured to land," not "will this specific campaign land."

The rule for picking

Ask one question: how often do you audit, and across how many domains. Auditing one domain once to understand it, and wanting full control, points to DIY, as long as you respect that the interpretation is the hard part. Watching many sending domains continuously, with alerting and aggregate-report parsing, justifies a standing SaaS floor. Everything in between, the occasional or on-demand audit of your own or a partner's domain, is exactly the shape per-call billing was built for. Start with a free monid discover -q "email deliverability", inspect the endpoint for its schema and price at no cost, and let your real cadence, not a feature list, decide. Start at monid.ai.

FAQ

Is it cheaper to build my own DMARC checker? Only if you value your engineering time at zero. The dig call is free, but a correct auditor has to count SPF's 10 DNS lookups, discover DKIM selectors instead of guessing them, and read the DMARC policy rather than just confirm a record exists. For occasional audits, a per-call check is cheaper once you count the build. Magnitudes are at monid.ai/tools.

What does the check actually return? For one domain, it returns SPF, DKIM, DMARC, MX records, blacklist status, and a 0 to 100 deliverability score. That covers presence, DMARC policy, and the common misconfigurations in a single response.

When should I pay for a deliverability SaaS instead? When you need continuous monitoring across many domains, DMARC aggregate report ingestion, and alerting. Those are a subscription's core strengths. For spot audits, the monthly floor is capacity you are not using.

Does a good score guarantee my email lands? No. Correct SPF, DKIM, and DMARC are necessary, not sufficient. Content, list hygiene, and IP reputation also decide the inbox. Read the score as "the domain is configured to land," then still verify addresses and warm your sending properly.

email-deliverabilitydmarcbuy-vs-buildagents