# Email Deliverability Score and Message Risk Analyzer

> Score the evidence in a received email fixture, expose missing sender controls, and produce an ordered remediation handoff without pretending to predict inbox placement.

- **Canonical page:** [https://emailbump.com/tools/email-deliverability-score](https://emailbump.com/tools/email-deliverability-score)
- **Interactive tool:** [Open the email deliverability score](https://emailbump.com/tools/email-deliverability-score)
- **Category:** Deliverability diagnostics and message QA
- **Updated:** July 2026
- **Model:** Transparent browser-only point ledger across identity, permission, message, and operations
- **Privacy:** Pasted headers, HTML, declarations, calculations, and exports remain in the browser
- **Boundary:** The score is not a live DNS lookup, blocklist query, reputation measurement, SMTP acceptance test, certification, or inbox-placement prediction

## What this tool answers

The tool answers a narrow but useful question:

> Based on this received-message fixture and these declared operating conditions, which mechanical deliverability controls are represented, which are missing, and what should be repaired first?

It evaluates four evidence families:

1. **Identity:** SPF, DKIM, DMARC alignment, visible From identity, forward and reverse DNS evidence.
2. **Permission:** recipient relationship, visible unsubscribe, one-click headers, DKIM coverage, suppression.
3. **Message:** core fields, MIME alternatives, links, image alternatives, display identity, narrow copy warnings, HTML size.
4. **Operations:** TLS evidence, complaint rate, hard-bounce rate, volume change, complaint monitoring.

Every check has:

- an identifier;
- an evidence family;
- an applicable point maximum;
- earned points;
- state;
- observed or declared evidence;
- and a remediation action.

This lets an operator reproduce the number instead of trusting an unexplained score.

## What the score does not answer

Mailbox providers evaluate signals that a browser tool cannot observe. These can include:

- IP and domain reputation;
- DKIM-domain reputation;
- URL and redirect reputation;
- ASN and infrastructure history;
- historical volume and consistency;
- per-recipient engagement;
- complaint signals unavailable to the sender;
- traps, invalid recipients, and acquisition quality;
- account-level filtering;
- content classifiers;
- current attack or compromise indicators;
- receiver policy changes;
- provider pool behavior;
- and the complete SMTP conversation.

A score of 100 means only that the applicable checks in this model earned all available points. It does not mean a receiver will accept the message or place it in the inbox.

## Why evidence coverage is separate

The interface displays both:

- **Mechanical score:** points earned from applicable checks.
- **Evidence coverage:** how much of the applicable point surface is supported by observed fixture evidence, operator declarations, or no evidence.

Observed evidence receives the strongest coverage weight. Examples include:

- Authentication-Results from a received message;
- From, Date, Message-ID, MIME-Version, and Content-Type fields;
- List-Unsubscribe and List-Unsubscribe-Post fields;
- the DKIM signed-header list;
- HTTPS link destinations;
- image alt attributes;
- and visible unsubscribe markup.

Declarations receive partial coverage weight because the browser cannot reproduce them. Examples include:

- forward and reverse DNS verified;
- TLS verified;
- suppression tested;
- permission model;
- complaints monitored;
- current complaint and hard-bounce rates;
- and recent volume behavior.

Missing evidence receives no coverage credit.

A high mechanical score with modest coverage should trigger more evidence collection. A lower score with high coverage can be operationally useful because the team knows exactly what failed.

## Use a received production-route fixture

Template source is not enough. Providers can:

- add or change Message-ID;
- construct a return path;
- add or replace DKIM signatures;
- rewrite links;
- inline CSS;
- insert tracking resources;
- change MIME boundaries;
- fold header fields;
- encode content;
- and add unsubscribe fields.

Send a representative fixture through the same provider account, identity, stream, and route used in production. Copy the headers from the received message, not from the pre-send composer.

Choose a receiver sample relevant to the investigation. Authentication-Results expresses what that receiving system observed. One receiver fixture does not prove identical behavior at another receiver.

Before sharing an export, inspect raw headers for:

- recipient addresses;
- Message-ID values;
- internal hostnames;
- routing details;
- unsubscribe tokens;
- campaign identifiers;
- and other personal or operational data.

Redact data that the reviewer does not need. Never paste credentials, private keys, API keys, bearer tokens, or complete audience records.

## Identity scoring

### SPF from Authentication-Results

SPF is evaluated against the envelope sender or HELO identity used by the receiver. Publishing SPF at the visible From domain does not prove that the message's actual SPF identity passes.

The tool looks for an SPF verdict in Authentication-Results:

- pass earns the applicable points;
- an explicit non-pass result fails;
- no result is unknown.

This is a simple parser. Preserve the complete field and use the [email header analyzer](https://emailbump.com/tools/email-header-analyzer.md) when the message has several Authentication-Results fields, forwarding, ARC, nested comments, or provider-specific output.

Use the [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md) to inspect the current DNS policy. A DNS check and a received-message result answer different questions.

### DKIM validation

The model looks for dkim=pass in Authentication-Results. A DKIM-Signature field existing is not equivalent to successful validation.

Operational evidence should retain:

- signing domain;
- selector;
- algorithm;
- receiver verdict;
- aligned or non-aligned role;
- and message route.

Use the [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md) to inspect the public selector and key. Use the [DKIM record generator](https://emailbump.com/tools/dkim-record-generator.md) only to create a new key package with a controlled private-key handoff.

### DMARC and alignment

DMARC evaluates alignment between the visible RFC 5322 From domain and a passing SPF or DKIM identity. SPF pass and DKIM pass in isolation do not guarantee DMARC pass.

The score requires an observed dmarc=pass result for full DMARC points. If the result is missing, the model does not infer alignment from similar-looking strings.

[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) is the current DMARC specification. Use the [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md) to draft and review policy syntax, but use aggregate reports and received-message evidence to understand real traffic.

### Visible From identity

The parser extracts the domain from the From field and checks that one domain-bearing mailbox is represented. It also flags a narrow consumer-Gmail impersonation pattern when the message claims an @gmail.com visible identity without corresponding Gmail authentication evidence.

Human review must still answer:

- Is the display name truthful?
- Does the recipient recognize the sender?
- Is the identity stable for this message category?
- Does the address receive replies or direct them appropriately?
- Does the identity separate promotional and transactional risk where needed?

### Forward and reverse DNS

Gmail and Yahoo publish forward and reverse DNS expectations for sending IPs. The browser does not query DNS, so this input is a declaration.

Good evidence includes:

- sending IP;
- PTR result;
- forward resolution of the PTR hostname;
- timestamp;
- resolver or authoritative trace;
- provider ownership boundary;
- and production-route message reference.

Mark the state unknown rather than verified when the provider is assumed to handle it but no current evidence is available.

## Permission scoring

### Confirmed opt-in

Confirmed opt-in receives full model credit because an additional recipient action can reduce accidental or abusive subscriptions. Evidence should still preserve:

- acquisition source;
- event time;
- recipient or privacy-safe reference;
- form and disclosure version;
- confirmation event;
- consent scope;
- expected sender;
- and expected frequency.

Confirmation is not a substitute for honest disclosure or appropriate purpose.

### Explicit single opt-in

Explicit single opt-in receives nearly full credit. The remaining model point represents the additional uncertainty around typos, automated abuse, and third-party signups.

Mitigate that risk with:

- rate controls;
- anomaly detection;
- duplicate handling;
- typo feedback;
- source monitoring;
- and confirmation when the abuse risk is material.

### Existing customer or service relationship

This relationship can support genuine transactional traffic when the message is expected and tied to the service purpose. It receives lower credit for subscription traffic because a purchase or account relationship does not automatically establish an ongoing promotional subscription.

Do not classify a promotional message as transactional merely to remove unsubscribe controls from the score.

### Mixed, purchased, scraped, or appended data

Mixed or incomplete provenance is a failed control because eligibility cannot be established consistently.

Purchased, scraped, or appended data receives no permission points. Stop sending and quarantine the source. Authentication, design quality, and low initial bounce measurements cannot manufacture recipient expectation.

### Visible unsubscribe

For a subscription profile, the static HTML scanner looks for a visible unsubscribe or preference link. This is a mechanical presence check only.

It does not verify:

- whether the link is visible after rendering;
- token validity;
- authentication or login friction;
- preference-scope clarity;
- server response;
- processing latency;
- suppression propagation;
- or the no-send outcome.

Test the received message as a recipient, complete the flow, inspect the suppression event, and verify that a subsequent eligible send is stopped.

### RFC 8058 one-click unsubscribe

For a high-volume subscription profile, the model checks:

- an HTTPS URI in List-Unsubscribe;
- List-Unsubscribe-Post with List-Unsubscribe=One-Click;
- and whether the DKIM h= signed-header list includes both fields.

[RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) requires a valid DKIM signature covering List-Unsubscribe and List-Unsubscribe-Post for its one-click mechanism.

The static check cannot prove:

- the personalized URI identifies the correct subscription safely;
- the opaque component resists forgery;
- a receiver-style POST works;
- the endpoint avoids prohibited authentication dependencies;
- the endpoint avoids redirects;
- the operation completes;
- or suppression propagates.

Use the [List-Unsubscribe header generator](https://emailbump.com/tools/list-unsubscribe-header-generator.md) to inspect and document the complete endpoint contract.

### Transactional applicability

The scorer marks body unsubscribe, one-click headers, and one-click DKIM coverage not applicable when the profile is transactional.

This is a scoring decision, not a legal conclusion. Some service streams benefit from preference or stop controls, and some messages called transactional contain promotional content. Apply the classification to the real message purpose, expectation, and governing requirements.

## Message scoring

### Core message fields

The parser checks for:

- From;
- Date;
- Message-ID;
- and MIME-Version.

This is not a complete RFC 5322 validator. It does not prove:

- exactly one valid From mailbox;
- mailbox syntax;
- header encoding;
- line length;
- field ordering;
- unique identifier quality;
- valid MIME boundaries;
- transfer encoding;
- or standards compliance after the provider's complete transformation.

Use a raw-message parser and received-client tests for deeper validation.

### Plain-text and HTML alternatives

The model gives full points when Content-Type declares multipart/alternative. It cannot inspect the actual body parts because the input asks for the rendered HTML separately.

Verify that:

- both parts exist;
- both carry equivalent meaning;
- text URLs are usable;
- unsubscribe works in both;
- personalization fallbacks do not diverge;
- and the MIME structure is valid.

### Link destinations

The scanner extracts href values and warns about:

- insecure absolute HTTP destinations;
- a small set of public URL shorteners;
- javascript URLs;
- and data URLs.

No request is made. The tool does not resolve redirects, inspect certificates, evaluate destination content, or query URL reputation.

Inventory:

- owned destination domains;
- provider tracking domains;
- redirect sequence;
- certificate ownership;
- DNS ownership;
- branding;
- and retirement process.

Unexpected or inconsistent link domains deserve investigation even when every URL uses HTTPS.

### Image alternatives

The tool checks whether img elements have alt attributes. It cannot determine whether the value is useful.

Informative images need meaningful alternatives. Decorative images usually need an explicit empty alt value. Functional images need an alternative that communicates the action.

Test with images disabled and representative assistive technology.

### Copy warnings

The scanner uses deliberately narrow patterns for:

- reply or forward cues;
- high-pressure urgency;
- repeated all-caps words;
- embedded form elements;
- and script elements.

These are review signals, not a list of forbidden words and not a spam-filter emulator. Context, truth, recipient expectation, reputation, and message purpose matter more than swapping one isolated word.

Do not rewrite useful security urgency merely to satisfy a generic score. Make the identity and required action precise, and test the real stream.

### Display name

The model flags a small set of subject-like or deceptive display-name patterns. Google's sender guidance says display names should identify the sender and should not be used for deceptive urgency, recipient-name tricks, or fake thread cues.

A stable person, brand, or truthful hybrid identity is usually easier for recipients to recognize. Evaluate the complete From name and mailbox together.

### HTML size

The model gives full points below 80 KB, a warning from 80 KB through 102 KB, and fails above 102 KB.

This is conservative implementation headroom, not a universal protocol limit. Gmail is widely known to clip large HTML messages, but provider transformations, encoded size, and MIME structure can change the effective payload.

Measure:

- source template;
- compiled HTML;
- provider-processed HTML MIME part;
- total message size;
- and received rendering.

Remove redundant markup, repeated inline declarations, unused modules, and excessive tracking parameters before cutting accessible content.

## Operations scoring

### Complaint rate

The model awards:

- full points at or below 0.1%;
- partial points above 0.1% and below 0.3%;
- zero at or above 0.3%.

Gmail and Yahoo publish 0.3% as an important spam-rate boundary in their sender guidance. It is not a healthy target. A sender operating near it has little margin for source, frequency, or content mistakes.

Rates are comparable only when their definitions are comparable. Record:

- receiver;
- numerator;
- denominator;
- delivered versus attempted basis;
- time window;
- identity;
- traffic stream;
- minimum volume;
- deduplication;
- and late-arriving events.

Yahoo notes that its spam rate is based on messages delivered to the inbox, which can differ from a sender's internal denominator.

### Hard-bounce rate

The model gives full points at or below 0.5%, partial points above 0.5% and below 2%, and zero at or above 2%.

These are operational triage thresholds, not receiver standards. Segment before acting:

- acquisition source;
- domain or receiver;
- campaign;
- list age;
- verification state;
- provider;
- and SMTP response family.

Stop retrying terminal failures and preserve the raw response. Use the [SMTP bounce decoder](https://emailbump.com/tools/bounce-code-decoder.md) for individual responses and the [email bounce rate calculator](https://emailbump.com/tools/email-bounce-rate-calculator.md) for denominator-aware aggregate analysis.

### Volume change

A stable stream or controlled ramp receives full points. A sudden spike fails.

This does not prescribe one universal warmup schedule. A safe change plan should state:

- previous and proposed volume;
- identity and receiver segments;
- start population;
- stage sizes;
- stop conditions;
- complaint, bounce, and deferral checks;
- responsible owner;
- and rollback authority.

Use the [email warmup calculator](https://emailbump.com/tools/email-warmup-calculator.md) as a planning ledger, not an inbox guarantee.

### Complaint monitoring

Mark monitoring verified only when a person or team owns:

- receiver or provider source;
- identity coverage;
- denominator definition;
- threshold;
- alert;
- suppression action;
- investigation procedure;
- and recurring review.

Dashboards without an owner or response path are visibility, not control.

## Receiver requirement lenses

The interface includes directional lenses for Gmail, Yahoo/AOL, and Outlook.com. They are scope-aware summaries of checks already in the ledger.

They are not receiver emulators and do not predict placement.

### Gmail

[Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) distinguish all senders from senders of more than 5,000 messages per day to personal Gmail accounts.

The high-volume lens looks for:

- SPF;
- DKIM;
- DMARC pass and alignment;
- complaint control;
- visible body unsubscribe for subscription traffic;
- and RFC 8058-style one-click mechanics for subscription traffic.

Google's FAQ says mailto alone does not meet its one-click requirement.

### Yahoo and AOL

[Yahoo's sender requirements](https://senders.yahooinc.com/best-practices/) distinguish all senders from bulk senders but do not publish one universal bulk-volume threshold.

The high-volume lens checks authentication, DMARC alignment, complaints, body unsubscribe, and list-unsubscribe mechanics for the declared subscription profile.

Yahoo's published guidance says promotional and marketing one-click requests should be honored within two days. The tool cannot test processing time.

### Outlook.com consumer domains

[Microsoft's high-volume sender announcement](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) describes SPF, DKIM, and DMARC requirements for domains sending more than 5,000 messages per day to Outlook.com consumer services.

The lens checks the observed authentication trio for the declared high-volume profile. Microsoft's filtering and reputation systems remain outside the tool.

## Reading the result bands

### Strong mechanical evidence

There are no failed controls and the score is at least 90.

Next actions:

- review evidence coverage;
- send to representative receivers;
- inspect SMTP acceptance and placement;
- archive received fixtures;
- monitor complaints, bounces, and deferrals;
- and re-run after material changes.

### Review before send

There are no failed controls, but partial points or unknown evidence keep the score below 90.

Resolve unknown evidence and decide whether warnings reflect an intentional, tested design.

### Material risk found

At least one control fails or the score is materially reduced.

Follow the ordered repair queue. Identity and permission failures appear before cosmetic message warnings.

### Blocked by core gaps

The score is low and one or more controls fail.

Do not use content rewrites or a different scoring tool to hide missing authentication, permission, unsubscribe, or suppression controls.

## Ordered remediation

The queue sorts:

1. failed identity and permission checks;
2. other failed checks;
3. unknown evidence;
4. warnings;
5. larger point losses within the same tier.

This order reflects risk concentration, not implementation effort. A one-point warning can be quick to fix; a failed alignment path can require provider, DNS, and architecture changes.

After a repair:

1. change the source configuration;
2. compile the final message;
3. send through the production route;
4. collect a fresh received fixture;
5. re-run the score;
6. inspect receiver results;
7. archive evidence with the revision and time.

## Export formats

### Point-ledger CSV

The CSV contains:

- check identifier;
- category;
- state;
- earned points;
- maximum points;
- evidence source;
- title;
- evidence summary;
- and action.

Use it for review and ownership assignment.

### JSON QA manifest

The manifest contains:

- generation time;
- model version;
- boundary statement;
- non-sensitive input summary;
- score;
- result band;
- evidence coverage;
- category composition;
- blocker and review counts;
- static message inspection;
- complete checks;
- repair queue;
- and receiver lenses.

The export intentionally replaces raw headers and HTML with redaction reminders. Include raw fixtures in an access-controlled evidence system only when necessary.

### Plain-text score brief

The brief contains the score, evidence coverage, category results, top actions, and method boundary. It is suitable for a pull request, ticket, launch review, or incident note.

## Recommended workflow

### Before launch

- classify the real stream;
- verify permission source;
- send a production-route fixture;
- collect received headers;
- paste the final HTML;
- enter receiver-defined complaint data;
- enter terminal-failure data;
- review the repair queue;
- fix blockers;
- resend and archive evidence.

### During a deliverability incident

- preserve raw SMTP responses before changing traffic;
- segment by receiver, identity, pool, source, and template;
- compare recent configuration and volume changes;
- use the scorer to identify missing mechanical controls;
- do not treat a high score as evidence the receiver is wrong;
- reduce or pause risky traffic when appropriate;
- coordinate with the provider using message IDs and timestamps;
- and record recovery gates.

### After a provider or domain migration

- test every stream separately;
- confirm return-path behavior;
- confirm all DKIM signatures and selectors;
- confirm DMARC alignment;
- inspect unsubscribe transformation;
- inventory tracking domains;
- confirm event and suppression processing;
- stage volume;
- and compare receiver outcomes with the previous route.

## Related tools and guidance

- [Email deliverability readiness audit](https://emailbump.com/tools/email-deliverability-readiness-audit.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md)
- [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md)
- [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md)
- [List-Unsubscribe header generator](https://emailbump.com/tools/list-unsubscribe-header-generator.md)
- [Email bounce rate calculator](https://emailbump.com/tools/email-bounce-rate-calculator.md)
- [SMTP bounce decoder](https://emailbump.com/tools/bounce-code-decoder.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)
- [Reduce transactional spam complaints](https://emailbump.com/blog/reduce-transactional-email-spam-complaints.md)
- [Email deliverability definition](https://emailbump.com/glossary/email-deliverability.md)
- [Sender reputation definition](https://emailbump.com/glossary/sender-reputation.md)
- [Inbox placement definition](https://emailbump.com/glossary/inbox-placement.md)