# Email Deliverability Readiness Audit and Evidence Checklist

> Audit sender identity, permission, suppression, delivery operations, monitoring, and incident response with explicit applicability, reproducible evidence, named owners, and an ordered remediation queue.

- **Canonical page:** [https://emailbump.com/tools/email-deliverability-readiness-audit](https://emailbump.com/tools/email-deliverability-readiness-audit)
- **Interactive tool:** [Open the deliverability readiness audit](https://emailbump.com/tools/email-deliverability-readiness-audit)
- **Category:** Deliverability operations and sender readiness
- **Updated:** July 2026
- **Control library:** 28 controls across four evidence families
- **Privacy:** Audit fields, examples, analysis, and exports remain in the browser
- **Boundary:** Readiness evidence is not an inbox-placement score, certification, legal opinion, or delivery guarantee

## What this audit is for

Email deliverability is an operating system, not a single DNS record and not a one-time launch task. A sender needs to know which identities produce mail, why recipients are eligible, how failures and opt-outs move through the system, what receivers report, and who has authority to contain a problem.

This audit turns those questions into controls that can be tested and handed to another operator. Each applicable control receives one of four states:

- **Verified:** the documented test was performed and a reproducible evidence reference is attached
- **Gap:** the control is absent, failing, incomplete, or contradicted by current evidence
- **Unknown:** the team has not established the control's state
- **Not applicable:** the declared stream scope excludes the control and the exclusion can be explained

The interactive tool then produces:

- A readiness state instead of an artificial percentage
- Applicable and non-applicable control counts
- Coverage by evidence family
- An ordered queue of blocker, high-priority, and operational gaps
- Warnings about missing owners and unsupported verified claims
- A concise text brief
- A CSV control ledger
- A structured JSON handoff

The audit is useful before a launch, after a provider or domain migration, during an incident, before a volume increase, after adding a list source, and during recurring operational reviews.

## Why there is no letter grade

A checklist can create false confidence when unlike controls are converted into interchangeable points. Publishing a correct DNS record does not compensate for ignoring an unsubscribe. A polished dashboard does not compensate for a broken suppression path. Twenty low-risk passes do not neutralize one identity or permission blocker.

The tool therefore uses three priority classes:

- **Blocker:** a missing control can invalidate sender identity, recipient eligibility, opt-out handling, or critical containment
- **High:** a missing control creates substantial operational or diagnostic exposure
- **Operational:** the control improves repeatability, evidence quality, and response

The readiness state is **blocked** when an applicable blocker is a known gap. It is **incomplete** when applicable gaps, unknowns, or verified-without-evidence assertions remain. It is **evidence ready** only when every applicable control is verified and every verified control has a proof reference.

Evidence ready still does not mean every message will reach the inbox. Receivers make contextual decisions using identity, reputation, traffic, recipient behavior, content, security signals, and other information. The state means the sender can establish important controls, observe outcomes, and respond coherently.

## Declare the audit scope first

Controls are meaningless without a boundary. Record the program or stream, its owner, review date, stream type, identities, environment, and receiver population.

### Program or stream

Choose a scope that can be tested end to end. Examples include:

- Product authentication and security messages
- Billing and account notifications
- A newsletter for one brand and region
- Lifecycle subscription messages
- A marketing program using one provider and one organizational domain
- All production email for a migration review

Do not write “email” if different systems, providers, owners, identities, or permission rules make that scope impossible to test as one unit.

### Stream type

The tool supports:

- **Subscription:** messages whose receipt depends on an ongoing subscription, such as newsletters and promotional campaigns
- **Transactional:** messages triggered by a transaction, account action, security event, or service relationship
- **Mixed:** a scope containing both subscription and transactional streams

This distinction affects applicability. Visible unsubscribe and one-click unsubscribe controls apply differently to subscription and transactional traffic. Mixed scopes should preserve stream separation rather than treating every message identically.

### Bulk traffic to personal Gmail

The tool includes a switch for bulk sending to personal Gmail accounts. When enabled for subscription or mixed traffic, the RFC 8058 one-click unsubscribe control becomes applicable.

Google's sender guidance and FAQ define requirements for mail sent to personal Gmail accounts. Their scope should not be silently generalized to every Google Workspace mailbox or every receiver. Other receivers, providers, laws, or contracts can create additional obligations. Treat the switch as a specific applicability rule, not universal legal classification.

## Evidence standards

A checkbox is useful only if a future operator can reproduce the conclusion. “Configured,” “looks good,” and “provider handles it” are assertions, not durable evidence.

Good evidence has five properties:

1. **Scoped:** it identifies the stream, environment, provider, domain, selector, pool, or endpoint being tested.
2. **Dated:** it records when the test or observation occurred.
3. **Reproducible:** it contains a query, trace, message identifier, ticket, fixture, or procedure another authorized operator can follow.
4. **Outcome-bearing:** it records the actual result, not only the intended configuration.
5. **Owned:** it identifies the person or team responsible for maintenance and remediation.

Useful examples include:

- A timestamped DNS trace from an authoritative or intentionally selected resolver
- Raw message headers from a delivered production-route fixture
- A DMARC aggregate report sample tied to the reporting destination
- A signed webhook fixture and processing log
- A completed unsubscribe flow test followed by a no-send verification
- A suppression query that shows event source, time, reason, and consuming systems
- A dashboard link plus field and denominator definitions
- A provider portal export with identity and time range
- A change ticket containing before/after evidence and rollback criteria
- Runbook exercise notes with participants, containment decision, and recovery gate

Do not paste credentials, bearer tokens, private keys, full recipient lists, or unnecessary personal data into the browser fields. Prefer a privacy-safe summary or a reference to an access-controlled evidence system.

## Evidence family 1: identity and authentication

### 1. Maintain a production sender inventory

Inventory every application, provider, vendor, domain, subdomain, envelope identity, visible From identity, DKIM selector, sending IP or pool, environment, owner, and retirement state.

Test the inventory by selecting recent production messages from each stream and tracing every hop back to an owned entry. Look for shadow vendors, legacy credentials, default provider domains, forgotten selectors, and development systems that can reach real recipients.

Expected evidence is a current inventory with a review date and owner. A diagram is helpful but should not replace searchable source data.

### 2. Authorize every production route with SPF where applicable

SPF evaluates whether an IP is authorized for the envelope sender or HELO identity being checked. A record existing at the visible From domain does not prove the actual message path passes SPF.

For each route:

- Inspect the return-path or envelope identity from a real message
- Query the exact SPF domain through the complete include and redirect chain
- Preserve the receiver's Authentication-Results
- Check that retired vendors are removed deliberately
- Review void lookups, recursion, and the processing limits defined by SPF

Use the [SPF record checker](https://emailbump.com/tools/spf-record-checker.md) to inspect an existing policy and the [SPF record generator](https://emailbump.com/tools/spf-record-generator.md) to draft a policy. Neither tool can prove that production routing matches the plan; raw headers still matter.

### 3. Verify DKIM on actual messages

DKIM evidence must come from signed production-route fixtures, not only a selector lookup. Confirm:

- The signature validates
- The signing domain is intended
- The selector resolves to the expected key
- Canonicalization and signed-header choices are understood
- Important identity and unsubscribe headers are covered where required by the applicable design
- Key rotation can occur without breaking active traffic

Preserve the raw DKIM-Signature and receiver result. Use the [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md) for the public key and the [email header analyzer](https://emailbump.com/tools/email-header-analyzer.md) for message evidence.

### 4. Publish DMARC and receive reports

DMARC combines identifier alignment, policy, and reporting. A syntactically valid TXT record is only part of the control.

Verify the record at the organizational or intended policy domain, parse every tag, confirm external report destination authorization when used, and retrieve a recent aggregate report through the real processing path. Document who reviews reports, how unfamiliar sources are classified, and how policy changes are approved.

Use the [DMARC record builder](https://emailbump.com/tools/dmarc-generator.md) to draft a policy. Policy enforcement should follow observed legitimate traffic and a change plan; do not copy an aggressive policy without understanding the inventory.

### 5. Prove DMARC alignment

An SPF pass or DKIM pass does not automatically mean DMARC passes. At least one authenticated identifier must align with the visible RFC 5322 From domain under the applicable relaxed or strict mode.

Inspect raw headers from each stream and receiver sample. Record:

- Visible From domain
- Envelope sender domain and SPF result
- DKIM signing domain and result
- DMARC alignment result
- Forwarding or intermediary effects where relevant

Alignment evidence is route-specific. A newsletter passing does not establish that billing, support, authentication, or a third-party survey stream passes.

### 6. Verify transport and DNS identity dependencies

Confirm that production infrastructure has the intended forward and reverse DNS relationships, uses TLS where required by the design or receiver rules, and emits standards-compliant message structure.

For shared providers, document which controls are provider-managed and retain evidence from their configuration or support contract. For dedicated infrastructure, record IP ownership, reverse DNS, hostname, certificate and transport behavior, pool assignment, and escalation path.

## Evidence family 2: consent and suppression

### 7. Retain permission evidence by subscription source

Permission evidence should answer who or what initiated the subscription, when it occurred, which source and form were involved, which disclosure or consent language applied, and how confirmation works.

Do not reduce consent to a single boolean if source, jurisdiction, purpose, brand, or time matters. Preserve version identifiers for forms and disclosures. Import workflows need their own source and approval evidence.

### 8. Protect acquisition forms against abuse

Public forms can be used for list bombing, harassment, and reputation damage. Test controls such as rate limits, anomaly detection, confirmation flows, bot resistance appropriate to risk, and alerting.

Evidence should include synthetic abuse tests, event samples, thresholds, the response owner, and a way to distinguish successful defense from silent data loss.

### 9. Govern imported and partner data

Every import should have a documented source, eligibility decision, duplicate and suppression treatment, age review, and approver. Contracts do not replace technical evidence.

Test a sample through the same downstream policy and suppression systems used by normal acquisition. Unknown provenance is not permission.

### 10. Provide a visible, functional unsubscribe

For subscription traffic, inspect the rendered message and follow the unsubscribe path as a recipient would. Confirm that the destination or preference action is usable, identifies the relevant scope, and does not create unnecessary friction.

Then verify the backend result. A successful confirmation screen is insufficient if queued or replicated sends continue.

### 11. Implement RFC 8058 one-click unsubscribe where applicable

RFC 8058 defines a HTTPS one-click mechanism using the List-Unsubscribe and List-Unsubscribe-Post fields. The test must cover:

- Correct personalized HTTPS URL construction
- A valid List-Unsubscribe-Post field
- DKIM coverage required by the standard
- Receiver-style POST behavior
- Safe opaque token handling
- Successful response
- Suppression propagation
- A subsequent no-send verification

Use the [List-Unsubscribe header generator](https://emailbump.com/tools/list-unsubscribe-header-generator.md) to build and inspect the header contract. The endpoint must perform the real operation; headers alone are not enough.

### 12. Keep suppression consistent across systems

Unsubscribes, complaints, permanent failures, policy suppressions, legal holds, and manual blocks can originate in different systems. Test whether every relevant sending path consumes the authoritative decision before enqueue or send.

Create a matrix of event type, source, authoritative store, propagation mechanism, consuming systems, expected latency, exception process, and reconciliation job. Run a cross-system fixture and record timestamps.

### 13. Verify complaint ingestion and action

Where complaint signals are available, verify event authenticity, identity mapping, idempotency, processing, suppression, metrics, and retention.

Complaint rate needs a documented numerator and denominator. Do not compare unlike provider dashboards without understanding how each metric is defined.

### 14. Verify delivery-event ingestion

Provider webhooks and event streams can fail quietly. Evidence should cover:

- Signature or authentication validation
- Timestamp and replay protection where supported
- Idempotent processing
- Retry and dead-letter behavior
- Processing lag
- Schema-version handling
- Reconciliation against provider totals
- Alerting on absence as well as explicit errors

A green endpoint health check does not establish that production events are complete.

## Evidence family 3: delivery operations

### 15. Preserve raw SMTP evidence and classify failures

Store the remote host, SMTP reply, enhanced status code where present, time, attempt, identity, stream, provider, message reference, retry history, and final action.

Classification is an operational hypothesis, not a replacement for raw evidence. Providers and receivers can use different language for similar conditions, and the same broad code family can require different actions.

Use the [SMTP bounce code decoder](https://emailbump.com/tools/bounce-code-decoder.md) to interpret a response and the [bounce rate calculator](https://emailbump.com/tools/email-bounce-rate-calculator.md) to analyze aggregate segments.

### 16. Make retry behavior cause-aware and bounded

Temporary failures may justify retry; permanent failures usually do not. Repeatedly retrying a terminal rejection wastes capacity and can worsen behavior.

Document which response classes retry, schedule and jitter, maximum age or attempts, queue priority, terminal transition, suppression interaction, and incident overrides. Test at least one temporary and one permanent fixture through the complete queue lifecycle.

### 17. Separate traffic where risk and purpose differ

Critical transactional mail should not be accidentally coupled to promotional volume, acquisition experiments, or a compromised stream. Separation can involve domains, subdomains, projects, credentials, pools, queues, policies, monitoring, and ownership.

The correct architecture depends on scale and provider. The control asks whether the chosen boundaries are explicit and observable, not whether every sender uses a dedicated IP.

### 18. Use an evidence-based launch or change ramp

A ramp is a change-control process, not a universal calendar. Start with wanted, eligible traffic; segment results by receiver and identity; define pause conditions; and record the owner who can stop the change.

Fixed daily multipliers copied from a generic schedule can hide receiver-specific failures. Preserve the dated plan, actual volume, change record, observed metrics, and decision at every stage. Use the [email warmup calculator](https://emailbump.com/tools/email-warmup-calculator.md) as a planning ledger, not a guarantee.

### 19. Document shared or dedicated pool choice

Dedicated IPs are not automatically better, and shared pools are not automatically safer. Record traffic volume and consistency, isolation needs, provider policy, reverse DNS responsibility, reputation ownership, migration plan, and escalation path.

Evidence should identify every active pool and which streams use it. Unexpected pool movement should be detectable.

### 20. Test message structure from every template family

Build raw fixtures for representative templates and verify headers, addresses, identifiers, MIME structure, transfer encoding, text and HTML alternatives, link construction, and unsubscribe fields where applicable.

Test the output after the provider has transformed or signed it. Source-template correctness does not prove the delivered message is correct.

### 21. Inventory and monitor link domains

Track owned and provider-managed click domains, redirect chains, certificates, DNS, destination ownership, and retirement state. Unexpected redirects, broken certificates, or inconsistent branding can damage recipient trust and obscure incidents.

Test representative links from raw delivered fixtures. Avoid placing sensitive recipient data directly in URLs.

### 22. Define metrics and denominators

Every operational metric needs a field contract:

- Event source
- Time basis
- Grain
- Numerator
- Denominator
- Deduplication rule
- Late-arrival treatment
- Segment dimensions
- Exclusions
- Retention

“Bounce rate” is ambiguous unless the team knows whether it means terminal failures divided by attempts, messages, unique recipients, or another provider-defined basis.

## Evidence family 4: monitoring and response

### 23. Configure receiver and provider monitoring

Maintain an inventory of provider dashboards, receiver portals, complaint signals, DMARC reports, queue telemetry, DNS monitoring, and internal metrics. Record verified identities, access owners, review cadence, and escalation contacts.

Google Postmaster Tools data is useful for eligible traffic but is not a complete view of every message or receiver. Provider dashboards are similarly scoped. Combine sources without pretending their measurements are interchangeable.

### 24. Retain enough raw evidence to reproduce incidents

Transient dashboards cannot be the only record. Define retention for raw headers, provider events, SMTP replies, configuration snapshots, change records, suppression decisions, and aggregate reports.

Apply access control and redaction appropriate to the data. Test retrieval from a recent message and a past incident.

### 25. Alert on actionable changes

Alerts should connect a condition to an owner, diagnostic context, and action. Test routing, acknowledgement, escalation, and absence detection.

Possible signals include:

- Authentication failures
- Complaint or terminal-failure shifts by receiver
- Event-ingestion lag or silence
- Queue growth
- DNS or certificate changes
- Unexpected identity or pool use
- Suppression latency
- Provider credential or quota failure

Thresholds should be based on the sender's traffic and change risk, with minimum-denominator handling to prevent tiny samples from creating noise.

### 26. Record material sender changes

Provider migrations, new domains, selector rotation, pool reassignment, tracking-domain changes, list-source additions, template changes, and volume changes can affect outcomes.

The change record should include owner, time, scope, rationale, before evidence, rollout, monitoring, pause condition, after evidence, and rollback.

### 27. Maintain and exercise an incident runbook

The runbook should define:

- Detection and triage
- Incident commander
- Authority to pause or isolate traffic
- Evidence preservation
- Provider and receiver contacts
- Stream protection priorities
- Communication
- Recovery gates
- Staged resumption
- Retrospective and follow-up ownership

Exercise the runbook with a plausible scenario. A document that has never been used is not verified.

### 28. Preserve audit history and schedule review

Keep the prior scope, statuses, evidence, accepted risks, closed gaps, unresolved tickets, approver, and next review trigger.

Material system changes should trigger a review even if the calendar date is distant. A recurring cadence catches slow drift, but event-driven review catches the highest-risk transitions.

## How to work the remediation queue

The tool sorts applicable gaps and unknowns by priority. Use the queue as a starting order, then adjust for dependency and blast radius.

1. **Contain active harm.** Pause or isolate traffic when permission, suppression, compromise, or severe failure evidence warrants it.
2. **Establish identity and eligibility.** Resolve unknown or failing authentication, inventory, permission, unsubscribe, and suppression controls.
3. **Restore observability.** Fix event ingestion, raw evidence, metric definitions, and alerting so later decisions use current data.
4. **Correct delivery behavior.** Repair retry, queue, pool, stream separation, structure, or link-domain problems.
5. **Verify recovery.** Repeat the exact failed test and observe the affected production evidence.
6. **Prevent recurrence.** Update the runbook, change process, monitoring, and audit schedule.

Assign an owner to every open item. “Messaging team” is acceptable only if that team has a real queue and clear accountability. Record dependencies, planned completion, exception authority, and the evidence required to close the item.

## A practical launch review

For a new subscription stream:

1. Inventory the application, provider, credentials, From domain, return-path, signing domain, selector, tracking domain, pool, queue, and owner.
2. Send a fixture through the real production route to controlled mailboxes.
3. Preserve raw headers and verify SPF, DKIM, DMARC, alignment, message structure, links, and unsubscribe fields.
4. Create a test subscriber through every acquisition source and retain permission evidence.
5. Exercise visible and one-click unsubscribe where applicable.
6. Confirm the test subscriber is suppressed before another message can leave each relevant queue.
7. Generate temporary and permanent delivery failures and confirm classification, retry, terminal state, and suppression.
8. Verify signed event ingestion, idempotency, lag, reconciliation, and absence alerts.
9. Confirm dashboards and receiver portals are accessible to named owners.
10. Approve a staged launch with receiver-segmented monitoring and explicit pause conditions.

## A practical incident review

When reputation or delivery changes:

1. Record detection time, affected identities, streams, providers, receivers, regions, templates, sources, and first known change.
2. Preserve raw replies, headers, events, configuration, dashboards, queue state, and change history before data expires.
3. Determine whether the issue is authentication, eligibility, complaint, content, infrastructure, routing, volume, compromise, or provider-specific.
4. Contain the highest-risk traffic while protecting critical transactional streams.
5. Verify event and metric completeness before trusting rate changes.
6. Use receiver-specific evidence; avoid treating a global average as universal.
7. Make the smallest defensible correction and define a recovery test.
8. Resume in stages only when the failed control and outcome evidence improve.
9. Record what changed, why, who approved it, and which alerts or controls should prevent recurrence.

## Export semantics

### Text brief

The brief summarizes scope, readiness state, counts, top remediation items, findings, and the tool's boundary. It is suitable for a ticket or review note.

### CSV

The CSV contains one row per control with:

- Stable control identifier
- Category and title
- Priority and applicability rule
- Derived applicability
- Effective status
- Owner
- Operator proof or reference
- Test procedure
- Expected evidence
- Remediation action

The operator proof and expected evidence are intentionally different fields. Expected evidence describes what a valid handoff should contain; proof records what this audit actually observed.

### JSON

The JSON preserves scope, timestamps, controls, analysis, category coverage, queue, and findings. Treat it as a portable snapshot, not an authorization to send.

## Common questions

### Does verified authentication guarantee inbox placement?

No. Authentication establishes identity and policy evidence. Receivers consider additional reputation, behavior, traffic, content, security, and contextual signals.

### Can I mark a control verified without entering proof?

The interface permits it so work can be staged, but the integrity review flags the missing evidence and the overall state remains incomplete.

### Should every sender use a dedicated IP?

No. Pool choice depends on volume consistency, isolation, provider operations, and ownership. Document and test the chosen architecture.

### Is every temporary failure safe to retry?

No. Preserve the exact response and use a cause-aware, bounded policy. Similar broad codes can represent different conditions.

### Does not applicable mean the control is unimportant?

No. It means the declared scope excludes it. Record the reason and revisit applicability when stream purpose, receiver population, or sender requirements change.

### How often should the audit run?

Use a documented recurring cadence and repeat after material sender, provider, domain, list-source, template, suppression, routing, or volume changes. Incidents should also trigger review.

### Does the audit upload evidence?

No. It operates locally in the browser. Avoid entering secrets or unnecessary personal data even when the data stays local.

## Primary standards and receiver guidance

- [Gmail email sender guidelines](https://support.google.com/mail/answer/81126?hl=en)
- [Gmail sender requirements FAQ](https://support.google.com/mail/answer/14229414?hl=en)
- [RFC 7208 — Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 6376 — DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html)
- [RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc7489.html)
- [RFC 8058 — Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html)
- [RFC 3463 — Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html)

## Related tools and guidance

- [SPF record checker](https://emailbump.com/tools/spf-record-checker.md)
- [SPF record generator](https://emailbump.com/tools/spf-record-generator.md)
- [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md)
- [DMARC record builder](https://emailbump.com/tools/dmarc-generator.md)
- [List-Unsubscribe header generator](https://emailbump.com/tools/list-unsubscribe-header-generator.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [SMTP bounce code decoder](https://emailbump.com/tools/bounce-code-decoder.md)
- [Email blacklist checker](https://emailbump.com/tools/email-blacklist-checker.md)
- [Email warmup calculator](https://emailbump.com/tools/email-warmup-calculator.md)
- [Google Postmaster Tools guide](https://emailbump.com/blog/google-postmaster-tools-guide.md)
- [Domain reputation guide](https://emailbump.com/blog/check-email-domain-reputation.md)
- [IP reputation guide](https://emailbump.com/blog/check-sending-ip-reputation.md)
- [DMARC and phishing guide](https://emailbump.com/blog/dmarc-phishing-protection.md)
- [Deliverability documentation](https://emailbump.com/docs/deliverability.md)