The Cathedra Examen workflow

This is the lesson the rest of the course points at. You have spent five modules learning what each Cathedra check evaluates, what finding text it produces, and how to read the result. This lesson walks you through using the tool end to end on a real domain.

By the time you finish, you should be able to scan a domain, look at the result panel, and recognize every finding. Nothing should surprise you. That is the bar.

Opening the Workbench

Cathedra is part of the Isidore Codex platform at codex.isidoregroup.net. Log in with your Isidore credentials. From the main navigation, open Workbench. Inside Workbench, open the Examen tab.

The Examen tab has a single text input — “Domain to scan” — and a Run Mail Diagnostics button. That is the entire UI surface for kicking off a scan. The simplicity is intentional. The complexity is in reading the result.

Running the scan

Enter the client domain. For this walkthrough, we are scanning Isidore’s own:

isidoregroup.com

Click Run Mail Diagnostics. The scan takes roughly 8–20 seconds depending on DNS responsiveness and the MTA-STS HTTPS fetch. You will see a progress indicator while it runs.

Internally, MailDiagnosticsService::run() is orchestrating ten checks in this order: MX, SPF, DKIM, DMARC, Autodiscover, MTA-STS, TLS-RPT, SMTP connectivity, DNS Hygiene, Provider Detection. Each check produces zero or more findings. The service aggregates them, computes an overall status (healthy, warning, or error), and a score (percentage of passing checks).

Reading the result panel

The result lays out in three regions:

1. Header — domain, overall status, score, detected provider.
2. Findings list — grouped by category (DMARC, SPF, DKIM, etc.), each finding showing status badge, name, finding text, recommendation, raw value.
3. Raw DNS panel — the actual DNS records Cathedra read, by record type.

The header tells you at a glance whether the domain is in good shape. For isidoregroup.com it should show:

• Overall status: warning (one MTA-STS info finding will not move the needle, but if any check returned warning, this reflects that)
• Score: somewhere in the 85–95% range depending on which optional controls are deployed
• Detected provider: Microsoft 365

The score is calculated as passing_checks / (passing + warning + error) × 100. Info-only findings do not affect the score, which is why a healthy posture with MTA-STS not deployed still scores well.

The predict-before-you-open exercise

The discipline this lesson is teaching: before you scroll through the findings, predict what you expect to see.

For isidoregroup.com:

Category	Predicted finding
MX	pass — isidoregroup-com.mail.protection.outlook.com.
SPF	pass — -all, M365 include
DKIM	pass — selector1 and selector2 CNAMEs resolve
DMARC Policy	pass — p=reject
DMARC Reporting	pass — rua= configured
Autodiscover	pass — CNAME present
MTA-STS DNS	info or pass — depends on whether deployed
TLS-RPT	info or pass — same
SMTP Connectivity	pass (or info — see Lesson 6.4)
STARTTLS	pass
NS Records	pass — two NS at the same provider
SOA	pass
CAA	info (if missing) or pass
DNSSEC	info (if missing) or pass
MX TTL	pass — within 300s–86,400s
Provider Detection	Microsoft 365

Now scroll the findings. Each one should match. If a finding diverges from your prediction, that is the finding that requires the most attention — either your model of the domain is wrong, or something in the configuration changed since the last time you reviewed it.

This habit — predict, then verify — is what makes a senior tech faster than a junior tech on this work. The junior reads each finding cold, has to think about whether it is correct, and second-guesses. The senior already knows what the domain should look like and is only checking for deltas.

What to do with each status badge

A short read for each badge color in the Cathedra UI:

• Pass (green) — control operating correctly. No action.
• Info (blue) — opportunity, not a failure. May or may not belong in remediation depending on client priorities. Often: MTA-STS, TLS-RPT, CAA, DNSSEC.
• Warning (orange) — real issue with reduced impact. Belongs in remediation. Severity (low/medium/high) tells you priority.
• Error (red) — real issue with significant impact. Top of the remediation list. Severity tells you how fast.

The Cathedra UI uses the Isidore palette — orange and green from the brand tokens for warning and pass. That is intentional. The badges read the same way the brand does.

When you have prerequisites that are wrong

A real Examen run on a misconfigured client will often show a cascade. Missing MX → SMTP connectivity is skipped. Missing SPF → DMARC alignment is meaningless. Missing DMARC → MTA-STS deployment is putting a roof on a house with no walls.

The order in which you remediate matters. The priority for an MSP-managed client:

1. MX correct — without this, no mail. Fix first.
2. SPF correct — passes alignment for envelope mail. Without it, DMARC cannot work.
3. DKIM correct — passes alignment for signed mail. Same.
4. DMARC at p=reject — the actual protection.
5. MTA-STS + TLS-RPT — transport hardening, once the rest is in place.
6. CAA, DNSSEC — DNS hardening, lowest priority but in the remediation list.

Cathedra does not order findings by remediation priority. It orders them by category. You translate from the report into the priority list yourself when you write the deliverable. The next lesson covers that.

A walkthrough of isidoregroup.com

Run the scan now. For the canonical Isidore domain you should see:

• A pass on every required control (MX, SPF, DKIM, DMARC at reject, autodiscover, NS, SOA).
• An info on MTA-STS or TLS-RPT depending on current deployment state.
• A possible info on SMTP connectivity (Cathedra cannot reach port 25 from its host — Lesson 6.4).
• Provider detected as Microsoft 365.

Score will be in the high 80s to low 90s. Overall status: warning or healthy.

This is the reference output. When you run Cathedra against a new client and the result looks materially different in shape, you are looking at a domain with real remediation ahead.

What you should remember

• Workbench → Examen → enter domain → Run Mail Diagnostics. That is the workflow.
• Cathedra runs ten checks via MailDiagnosticsService::run(). Output is grouped by category, with status, severity, finding text, and recommendation per item.
• Predict-then-verify is the working habit. Decide what you expect to see before you scroll the findings.
• The score weighs pass against warning and error; info findings do not affect the score.
• Cathedra does not order remediation by priority. You translate findings into a remediation plan when you write the deliverable. The next lesson covers the format.

---

Cathedra alignment: MailDiagnosticsService.php — orchestration of all 10 checks; this is the capstone synthesis lesson where every finding from Modules 1–6 lands in one report