Observed signal
The specific public signal we found — quoted or described precisely, so you can verify it yourself.
Methodology & sample report
How we read the evidence — and how we write it down.
A sender readiness audit is only as useful as its discipline. Every finding we publish follows the same structure, so the report stays honest about what the evidence shows and equally honest about what it doesn't. Below is the method, followed by fictional, redacted examples of the findings, risk register and remediation order you'd receive.
About these examples
All domains, records and findings on this page are fictional or redacted and exist only to demonstrate format and judgement. They are not real client data, and they are not advice for your domain.
Sender Readiness Audit · redacted
The anatomy of a finding
Six fields, every time.
Consistency is what makes a report trustworthy. Whether a finding is trivial or serious, it carries the same six fields — so nothing important is asserted without its evidence, and nothing is overstated.
Why it matters
What this signal means for sender readiness, in plain language a non-specialist can follow.
What it does not prove
The explicit limit — what this evidence cannot tell us, including anything about inbox placement.
Risk level
A severity rating, judged against the whole picture rather than a single record in isolation.
Uncertainty note
What we'd need to confirm the finding, and how confident we are without it.
Safest next check
The most careful next move — never "change everything," always a sequenced, reversible step.
Sample finding · 01
A DMARC policy that looks present but isn't protecting much.
PUBLISHED RECORD — REDACTED DOMAIN
; _dmarc.northwind-sales.example (TXT)
v=DMARC1; p=none; rua=mailto:dmarc@northwind-sales.example;
fo=1; adkim=r; aspf=r
F-04
DMARC is published in monitor-only mode
High- Observed
- A syntactically valid DMARC record exists with p=none and aggregate reporting configured. Alignment modes are relaxed.
- Why it matters
- Monitor-only means receivers are given visibility but no handling instruction for messages that fail authentication. The domain looks protected at a glance, yet the policy itself asks for no enforcement.
- Does not prove
- It does not reveal how any given provider currently treats the domain, and it proves nothing about whether mail reaches the inbox.
- Risk level
- High in the context of a domain preparing to scale volume — exposure is higher than the "valid record present" surface suggests.
- Uncertainty
- Aggregate (RUA) reports were not analysed in a snapshot. Reviewing a few weeks of reports would materially sharpen any policy recommendation.
- Safest next check
- Confirm SPF and DKIM alignment are healthy first; collect and read RUA reports; only then consider a graceful move toward p=quarantine with monitoring at each stage.
Sample finding · 02
When the visible records raise an alignment question.
VISIBLE RECORDS — REDACTED
; Envelope / header domains as observed in a shared sample
Return-Path: bounce@mail.relay-vendor.example
From: hello@northwind-sales.example
DKIM d= northwind-sales.example (selector present)
SPF auth on: mail.relay-vendor.example
F-07
Visible signals suggest an SPF alignment question
Review- Observed
- DKIM signs with the organisational domain, but the visible Return-Path points at a vendor relay domain, so SPF may authenticate on a domain that differs from the visible From:.
- Why it matters
- DMARC passes when SPF or DKIM aligns. With DKIM aligned, mail can still pass — but relying on a single aligned mechanism is more fragile than it looks, especially across multiple sending tools.
- Does not prove
- This is a question raised by visible records, not a confirmed failure. It does not demonstrate that any message failed, and it says nothing about inbox placement.
- Risk level
- Review — worth a deeper look rather than an alarm. It justifies an audit; it does not justify panic.
- Uncertainty
- Confirming this needs real headers from each sending path. A single shared sample is indicative, not conclusive.
- Safest next check
- Gather sample headers from each tool that sends as this domain and confirm which mechanism aligns on each path before changing any record.
Sample finding · 03
The risk register, at a glance.
Every audit consolidates findings into a single register so a reader can grasp the whole picture in one view — finding, evidence, severity, uncertainty, and the recommended next step. Fictional sample below.
| ID | Finding | Evidence | Severity | Uncertainty | Recommended next step |
|---|---|---|---|---|---|
| F-04 | DMARC in monitor-only mode | p=none published | High | RUA reports not yet reviewed | Verify alignment, then tighten gradually |
| F-07 | Possible SPF alignment gap | Return-Path on vendor domain | Review | Needs headers per sending path | Collect sample headers from each tool |
| F-09 | DKIM key length below current norm | 1024-bit selector observed | Review | Rotation impact on tooling unknown | Plan a rotation to a 2048-bit key |
| F-12 | No public blacklist hits observed | Common lists checked, clear | Low | Public lists ≠ private reputation | Re-check periodically; no action now |
| F-15 | SPF nearing lookup limit | Multiple nested includes | Note | Exact count varies by resolution | Flatten / consolidate includes |
SEVERITY: HIGH · REVIEW · LOW · NOTE — A "NOTE" OR "LOW" IS STILL RECORDED, BECAUSE A CLEAN SIGNAL IS EVIDENCE TOO.
Sample finding · 04
A remediation order — not a pile of edits.
The difference between clarity and chaos is sequence. Rather than handing you a list of changes to make at once, an audit lays them out in a safe order, each with a rollback note. Fictional sample below.
Sequenced & reversible
Confirm what aligns today
Before editing anything, gather sample headers per sending path and confirm which authentication mechanism aligns where. Rollback: none required — this step changes nothing.
Consolidate the SPF record
Reduce nested includes to stay clear of the lookup limit, keeping the existing qualifier. Rollback: restore the previous TXT value, retained verbatim before the change.
Rotate DKIM to a stronger key
Publish a new 2048-bit selector, verify signing on each tool, then retire the old selector once confirmed. Rollback: revert signing to the prior selector, which stays published until cutover is verified.
Read DMARC reports, then tighten
Only after the above are verified, review aggregate reports and move policy from p=none toward p=quarantine in measured steps. Rollback: return policy to the previous value; the change is a single TXT edit.
Who makes the changes
In an Audit + Guided Remediation engagement, The Presida does not log in to your DNS or mailbox. Your team or administrator implements each step while we guide, sequence, and verify the visible result.
Why a written audit beats a score
A tool tells you that something looks off. We tell you what, why, how sure, and what to do first.
Dashboards and scanners are useful inputs — but a number doesn't tell a stakeholder what to change, in what order, or what it can't promise. That judgement is the deliverable.