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 follows the same six-field structure, so the report stays honest about what the evidence shows and what it doesn't. Below: the method, then fictional examples of the findings, the risk register, and the 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 Audit & Action Plan · 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 its findings into a single register: one row per finding, one view of the whole. A fictional sample, three rows. Each row stands on its own; together they form one view of risk.
| ID | Finding | Public evidence | Severity | Confidence | Recommended action |
|---|---|---|---|---|---|
| F-04 | DMARC posture set to p=none | DMARC record published with p=none; no enforcement signal sent to receivers | Medium–High | High | Move to p=quarantine in stages after 14 days of rua aggregate reporting confirms alignment |
| F-07 | SPF alignment fails for marketing subdomain | Mail headers show return-path on a third-party subdomain not aligned with header-from | Medium | Medium | Switch ESP to custom return-path under the sending subdomain; re-test alignment before any DMARC tightening |
| F-11 | Orphaned MX record on legacy subdomain | MX record present on a subdomain no longer used for sending; resolves to retired infrastructure | Low | High | Remove the record after confirming no inbound mail relies on it; document the rollback note before edit |
SEVERITY × CONFIDENCE — EVERY ROW CARRIES BOTH. A LOW-SEVERITY, HIGH-CONFIDENCE FINDING 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. The audit lists changes 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.
Audit and implementation are separate decisions
The Sender Audit & Action Plan ends with written recommendations. Infrastructure Setup & Repair adds a separately approved implementation scope, time-bound access where required, a recorded change sequence, rollback notes, post-change verification, and a written handover.
From finding to approved change
The implementation method protects the baseline.
Technical changes are handled as a controlled sequence, not a collection of isolated fixes. The client remains the owner and approver throughout.
Establish the baseline
Capture relevant DNS values, authentication paths, provider settings, and available message evidence before a material edit is proposed.
Approve scope and rollback
Confirm what changes, who approves it, what access is required, what sits outside scope, and how the prior state can be restored.
Verify and hand over
Check the new state against the agreed target, document the result, remove temporary access, and leave the owner a maintainable record.
Reference standards
The standards behind the methodology.
The Presida's audit methodology is grounded in the same authentication and sender-readiness standards that mailbox providers publish and enforce. These are the primary references.
- Google — Email sender guidelines SPF, DKIM, DMARC requirements for bulk and all senders
- Yahoo — Sender best practices Authentication, complaint rates, and sender requirements
- Microsoft — Requirements for high-volume senders Outlook.com enforcement for 5,000+ daily senders (May 2025)
- RFC 7489 — DMARC specification The technical standard for Domain-based Message Authentication
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 on a screen doesn't tell a CTO what to change, in what order, or what the change won't fix. That judgement is the deliverable.