Catch the send you cannot un-send

dns_auth when you want one pre-send verdict, email-health when you want the evidence. Measured on github.com they produced the identical score object, 90.0 grade A with the same nine-section breakdown, but email-health returned 14 top-level keys and dns_auth returned 9. What dns_auth drops is the standalone bimi, mta_sts, tls_rpt, dnssec, dane and blacklist objects; their contribution is still visible in score.breakdown and their booleans in summary. If you need the SPF mechanism tree, the DKIM key bits or the DNSBL zone list, go to email-health.

Because include_blacklist defaults to false and the skipped section is still scored. With the default, github.com returned blacklist 10 out of 10 with the note "clean across 15 DNSBLs", summary.blacklisted false, and a total of 90.0 grade A. With include_blacklist true the same domain returned blacklist 6 out of 10 with the note "1 listing(s)", summary.blacklisted true, and 86.0 grade B. The fast default therefore awards a full clean blacklist score without having run the lookup. Pass include_blacklist true before you report a reputation result to anyone.

Different object entirely. validate's email action takes one address and answers whether that mailbox is worth sending to: a measured [email protected] returned syntax_valid true, has_mx true with the exchange github-com.mail.protection.outlook.com, is_disposable false, is_role_account false, is_free_provider false, deliverable true and score 95. email-preflight never looks at a recipient. It takes the message body, or the sending domain, and answers whether the thing you are about to send is well formed. A typical pipeline uses validate on the list, dns_auth once on the sender, and audit_html once per template.

Yes, an empty alt attribute counts as missing in both audit_html and check_images. In a measured run the image carrying alt="" appeared in accessibility.missing_alt_srcs and came back from check_images as alt "" with has_alt false. That is stricter than the HTML specification, where an empty alt is the correct marking for a decorative image. If you use that convention, subtract those images from missing_alt yourself before acting on the MISSING_ALT recommendation.

Because List-Unsubscribe is an SMTP header and audit_html only ever sees the HTML body, so there is nowhere for it to be true. In our runs it was false while has_unsubscribe_link and has_unsubscribe_text were both true from an in-body link. Treat that field as a checklist reminder for your sending code rather than a finding about the template, and read the two has_unsubscribe_* fields for what the HTML actually contains.

That we could not prove the link is dead, so we refuse to call it broken. Of four links in a measured template, one returned verdict ok, one returned verdict broken with a real HTTP 404, and two returned unverifiable: one with reason "host does not resolve" and error_code NOT_FOUND, the other reporting a resolution timeout against a slow target, with the response spelling out that a timeout is not proof the link is broken, and error_code INTERNAL. The response note spells out the rule: broken means a real status of 400 or above from the target, while anti-bot responses, timeouts and transport failures all land in unverifiable. Do not fail a campaign on unverifiable.

Yes. Reachability checks use a ranged request, so a healthy target commonly answers 206 Partial Content rather than 200. A measured github.com link returned status 206 with verdict ok and redirect_count 0, and a measured image returned reachable true with http_status 206. Key on verdict for links and on reachable for images rather than testing status == 200 yourself. Images that were never attempted come back with reachable null, which is not the same as false.

No, and the response says so in threshold_note: "score >= 5.0 ~ likely spam (SpamAssassin convention); this is a deterministic content SIGNAL, not an inbox-placement prediction." It is rule-based and repeatable. A deliberately awful test message scored 7.3 with verdict likely_spam over 7 rules including FREE_MONEY 1.5, CAPS_HEAVY 1.5 at a measured 36 percent all-caps words, URGENCY 1.0, MANY_EXCLAIM 1.0 and IMG_RATIO 1.0 for 4 images against 25 words; a plain rewrite scored 0.0 with verdict clean_signal and zero rules. Note that audit_html does not include this block, so spam_score is a separate call.

Email Preflight API is a ReefAPI endpoint group for email preflight It returns live JSON through POST requests under /email-preflight/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. Email Preflight calls use the same shared credit balance as every other ReefAPI engine.

No login to Email Preflight is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live audit_html call, and production requests fetch live data through ReefAPI rather than a static sample.

Email Preflight actions currently cost 1-3 credits per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call email-preflight actions with the same key, credit pool and JSON envelope used by normal REST requests.