toolkit

Scenario · Something looks broken

Our email isn't arriving

“We're not getting the form notifications.” Or: “Our email to patients is going to spam.”

"Our email isn't arriving" is actually two unrelated problems wearing the same sentence: form notifications not reaching the practice, which is usually a website issue, and outgoing mail landing in spam, which is a mail-authentication issue the website has no control over. This tells the two apart and rules out the cheap, common cause — a form that's silently rejecting submissions — before anyone spends an afternoon in DNS records chasing a problem that was never there.

What to ask for

Hosting & DNSHosting & DNS infra fingerprint — reads a domain's DNS, TLS, headers and RDAP and reports the backend stack: web host, nameservers, CDN/edge, email provider, SSL issuer, CMS, registrar and last-changed date.Form submittabilityDrives a rendered page to prove its primary form can be submitted.

See it work

A real run of Form submittability:

Form submittability · form-submittability — https://toolkit-tests.pages.dev/forms/overlay-submit.html  (devices: desktop,iphone-17)

FAIL — https://toolkit-tests.pages.dev/forms/overlay-submit.html
  ✗ the submit button is covered by a fixed element (div.banner) — clicks land on the overlay, the form cannot be sent
  • field textarea [message] is covered by a fixed div.banner — a visitor may not be able to click it
  • field button is covered by a fixed div.banner — a visitor may not be able to click it

  report: ./out/form-submittability-form-submittability.html
  text:   ./out/form-submittability-form-submittability.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

The category this sits in is inflated: most of what lands in it is bounce notifications rather than tickets. The genuine ones split cleanly into two problems that need opposite responses, and the sentence people use does not distinguish them.

  1. Establish which problem this is. Inbound — form notifications not reaching the practice — is a website problem and often not an email problem at all. Outbound — the practice’s mail to patients landing in spam — is a mail-authentication problem the website cannot cause or fix. Everything downstream depends on this answer.
  2. For inbound, check the form first. Run the submittability check. A form that silently rejects submissions produces exactly the symptom “we stopped getting emails”, and it is a website defect with a website fix. This is the most common cause and the cheapest to rule out.
  3. Read the domain’s mail configuration. The hosting and DNS fingerprint reports the mail provider and the domain’s DNS records. What you are looking for is a mismatch: mail apparently handled by one provider while the site sends through another, which is the usual reason notifications from a website vanish while ordinary staff email works fine.
  4. [manual] Send a test through the actual path and follow it. Submit the form with a test address, then look in the destination mailbox, its junk folder, and the mail provider’s own logs. The provider’s log is the only place that says what happened to a specific message, and nothing in this toolkit can read it.
  5. [manual] Fix it where it lives. A missing or wrong SPF, DKIM or DMARC record is fixed in DNS; a website sending mail directly from the web server instead of an authenticated relay is fixed by configuring the relay. Both are outside every check here and both need the provider’s console.
  6. Confirm with a second test after the change, and keep the message headers from a delivered message as the proof.

The honest position

This is a scenario that exists to route rather than to solve, and it says so. Its value is step 1 and step 2: separating a form defect from a mail-authentication defect, and ruling out the website before anyone spends an afternoon in DNS. Past that point, the mail provider owns the problem and this procedure’s job is to have established which problem it is.

What this does not cover

Almost all of it, and that is the honest answer. There is no mail-flow tool here: nothing reads a mailbox, traces a message, checks a blocklist, or inspects SPF and DKIM alignment in detail. What this procedure does is read the domain's public mail configuration, separate the two very different problems people describe with the same sentence, and route the rest to the mail provider — which is where it gets solved.

← All scenarios