mAIb Deliverability Repair

Methodology

Last updated 2026-09-14.

This page exists because the most valuable thing a diagnostic tool can do is be clear about its own limits. Everything below describes what this scanner actually does, in enough detail that you could check it.

What is read

Every scan queries public DNS through a public recursive resolver. Nothing else is contacted, with one exception noted below. Specifically:

  • TXT at the domain apex, for SPF and for other records published there.
  • TXT at _dmarc of the domain and, where needed, of its ancestors.
  • TXT and CNAME at selector._domainkey for each selector tried.
  • MX for the domain, and A/AAAA for each mail exchanger.
  • TXT at _mta-sts, _smtp._tls and default._bimi.
  • CAA for the domain.
  • Every TXT, A and MX lookup required to expand your SPF record.

The one exception: if an MTA-STS record is published, the policy file is fetched over HTTPS from mta-sts.yourdomain, because that is where RFC 8461 puts it. That fetch resolves the name, checks every address it resolves to against a block list of private and reserved ranges, connects only to a validated address, follows no redirects, and reads a bounded amount of data.

Every query a scan makes is listed on the result page under DNS evidence, with the answer and the time it took. Nothing is hidden.

SPF

The record is parsed against the RFC 7208 grammar rather than pattern-matched. Each term is validated as a mechanism or modifier; a term that does not parse is reported as a syntax error, because a receiver hitting it returns permerror and SPF stops working for the domain entirely.

Includes and redirects are then expanded recursively, exactly as a receiving server would, with a single budget of 10 DNS-querying terms shared across the whole evaluation. Cycles are detected, recursion is bounded independently of the budget, and every answer is cached for the life of the scan. Void lookups — NXDOMAIN or an empty answer — are counted separately against the limit of two that RFC 7208 advises.

The ptr mechanism is counted but not resolved, because evaluating it requires the connecting client's IP address, which a domain-only scan does not have.

DMARC

Parsed against RFC 9989, the Standards Track specification published in May 2026 that obsoletes RFC 7489. Three consequences of that change are handled explicitly:

  • The DNS Tree Walk. RFC 9989 replaced the Public Suffix List with a walk from the queried name toward the root, at most eight queries, stopping at the first record carrying an explicit psd tag. Every step is shown on the result page.
  • Removed tags. pct, rf and ri were removed. Records carrying them are parsed and the tags are explained rather than silently ignored or silently rewritten — a record with pct=50 is not broken, but it no longer means what its author intended.
  • Testing mode. t=y is recognised as suspending policy application.

A record found at an ancestor rather than at the queried name is reported as inherited, and the policy that applies is resolved through sp, or through np where the queried name does not exist in DNS at all.

p=none is described as monitoring, not as a failure. It is a valid published policy and it satisfies the current Gmail, Yahoo and Outlook.com requirements.

DKIM, and why it is often “not determined”

A DKIM key is published at selector._domainkey.yourdomain. The selector is chosen by whoever signs the mail and appears only inside the signature on a message. DNS offers no way to enumerate names under a domain, so a scan given only a domain cannot discover the selector.

What this scanner does instead: detect your mail platforms from MX and SPF, then try the selectors each of those platforms is documented to use, plus a short list of common defaults. Every selector tried is listed on the result page along with where the guess came from.

When no key is found, the result is not determined. It is not fail, and it is never described as DKIM being missing, because that is a claim the evidence does not support. Some platforms make it impossible in principle: Amazon SES Easy DKIM publishes three CNAMEs whose names are random 32-character tokens, and HubSpot's selectors carry a per-portal numeric suffix.

When a key is found, it is parsed: key type, modulus length, revocation via an empty p= value, testing mode, and whether the selector is delegated by CNAME.

Provider detection

Two separate questions, deliberately never conflated:

  • Inbound provider comes from MX records. It says where mail addressed to you is delivered.
  • Known outbound senders comes from SPF includes. An include is an explicit statement by the domain owner that a platform may send on their behalf.

An MX record is never used to conclude anything about outbound sending, and the IP address of a mail exchanger is never described as a sending IP. Those are different machines doing different jobs, and treating them as the same is a common and consequential error.

The score

Five categories, each with a fixed budget totalling 100: Authentication 40, Policy strength 20, DNS correctness 15, Provider readiness 15, Transport and security 10. Each finding takes its own published points off its category; categories cannot go below zero. The arithmetic is shown on every result under “Why did I lose these points?”, with the rule id responsible for each deduction.

There is no model, no weighting learned from data, and no AI involved at any point in a scan. The same domain with the same records produces the same score, and any score can be traced to the specific rules that produced it.

The score measures configuration against published standards. It is not a probability of inbox placement. A domain can score 100 and still have mail filtered, because placement depends on reputation, complaint rates and recipient behaviour that no external tool can read.

What this scanner cannot determine

  • It cannot establish that DKIM is absent. See above: not finding a guessed selector is an absence of evidence, not evidence of absence.
  • Your sending IP addresses. Nothing in DNS states them.
  • Your spam-complaint rate. Measured by each provider, visible only to you in their tools.
  • Whether your messages carry one-click unsubscribe headers. A property of each message.
  • Whether a real delivery used TLS. A property of a connection.
  • Whether your mail is actually signed. A published key proves a key exists, not that it is used.
  • Blocklist status or IP reputation. Not checked, and not claimed.
  • Whether any message will reach an inbox. Nothing can tell you that.

Most of these become answerable from one message's headers, which is why the header analyser exists. It runs in your browser and the headers are never uploaded.

Message headers

Where a message is supplied, preference is given to the Authentication-Results header stamped by a receiving system this tool recognises. A sender can write that header saying anything it likes, so one that cannot be attributed to a known receiver is shown as reported rather than verified, with a warning saying so.

The IP in the earliest Received header is labelled a likely sending IP, never a confirmed one, because headers before the first trusted hop can be forged.

Versions

Scan engine 0.1.0, ruleset 2026.09.14. Every rule carries the authority it derives from and the date that authority was last read (2026-09-14). Provider requirements change; when they do, the ruleset version changes with them, and every stored scan records the version it was run under so an old report can still be understood.