{{ summaryHeading }}
{{ scoreDisplay }}
{{ summaryLine }}
{{ statusLabel }} Blockers {{ statusCounts.Fail }} Warnings {{ statusCounts.Warn }} Pass {{ statusCounts.Pass }} {{ activeProfile.label }}
Auth DMARC Unsub {{ routeStageScoreLabel }}
Enter a bare domain. Use Check DNS to add live DNS evidence to the scorecard.
{{ dnsStatusLine }}
Choose the receiver family you are preparing for before reviewing volume, unsubscribe, and authentication gaps.
The 5,000+ level activates stricter Google and Outlook bulk sender review.
messages/day
Pick the stream represented by the pasted evidence.
Leave this equal to the sending domain unless your sample headers show a different From domain.
Keep the rate below 0.30%; the strict profile warns above 0.10%.
%
Use a preset to test pass, warning, and blocked states quickly.
Paste one message sample or checklist note set. Drop TXT/EML/headers files onto the textarea.
{{ sourceStatusLine }}
Use delivery logs, ESP docs, or rDNS checks for each outbound IP.
Paste TLS evidence in the notes when available.
Use production unsubscribe logs or ESP settings for this evidence.
Requirement Status Source Evidence Next action Copy
{{ row.requirement }} {{ row.status }} {{ row.source }} {{ row.evidence }} {{ row.action }}
Priority Fix area Action Verification Copy
{{ row.priority }} {{ row.area }} {{ row.action }} {{ row.verification }}
No blocker or warning rows. Keep monitoring spam rate, reports, and authentication drift.
Evidence type Observed Detail Copy
{{ row.type }} {{ row.observed }} {{ row.detail }} 
{{ launchReport }}
Tags: Email, Security
Email Header Analyzer Check raw email headers in your browser for relay delays, SPF/DKIM/DMARC alignment, ARC context, sender mismatches, and spoof-risk clues.
DKIM DNS Record Generator Generate a DKIM DNS TXT record from a selector, domain, and public key with key-strength checks, split-string guidance, and DNS publish fields.
DMARC DNS Record Generator Build a DMARC TXT record with owner labels, policy tags, report URIs, external authorization notes, rollout warnings, and DNS split guidance.
SPF Record Generator Build an SPF TXT record from real sender paths, provider includes, IP ranges, A/MX options, redirects, and lookup-budget warnings.
Customize
Advanced
:

Large consumer mailbox providers now judge bulk mail before the campaign copy is ever considered. A sending domain has to prove that the message came from an authorized source, that the visible identity matches the authenticated identity, that recipients can leave the list without friction, and that complaints stay low after delivery. Missing any one of those signals can turn a normal launch into spam-folder placement, throttling, or rejection.

Bulk sender readiness is not one DNS record. SPF names the servers that may send for a domain. DKIM signs the message so receivers can verify that a domain took responsibility for it. DMARC ties SPF or DKIM back to the visible From domain and publishes a policy for failures. Forward and reverse DNS, TLS transport, message format, and unsubscribe handling fill in the operational evidence that mailbox providers expect around those authentication records.

Readiness area Evidence that matters Common mistake
Authentication SPF and DKIM pass on a real delivered sample. Publishing records but never checking message-level pass evidence.
Identity DMARC aligns the visible From domain with SPF or DKIM. Authenticating a vendor or bounce domain that recipients never see.
Opt out Marketing and subscribed mail has one-click headers and a visible body link. Treating a footer link as enough when provider policy requires header support.
Recipient reaction Complaint data stays below provider limits and warning levels. Fixing DNS while ignoring list quality, consent, or a recent complaint spike.
Bulk sender evidence path from domain authentication through DMARC alignment and unsubscribe checks to mailbox acceptance.

Provider rules are similar, but they are not identical. Gmail applies a defined high-volume path for senders over 5,000 messages per day to personal Gmail accounts. Yahoo describes bulk senders by significant volume rather than a public fixed number. Microsoft added high-volume authentication requirements for Outlook.com, Hotmail, and Live.com recipients in 2025. A sender preparing for multiple receiver families should use the strictest relevant expectation, then verify the result with real headers from each message stream.

The biggest false sense of safety comes from checking only planned settings. A marketing stream can pass in a DNS review and still fail in a delivered message because the ESP used a different DKIM selector, the bounce domain did not align, the unsubscribe endpoint required a login, or a burst of low-quality addresses pushed complaints over the provider limit. Readiness is strongest when DNS, header evidence, operations, and complaint data all describe the same stream.

How to Use This Tool:

Start with the receiver family and one real sending stream. The checker works best when the pasted evidence comes from a delivered message that matches the domain, message type, and infrastructure you plan to review.

  1. Enter the Sending domain as a bare domain, then use Check DNS when live DNS evidence is needed. The DNS status line should report SPF, DMARC, MX, and DKIM selector hits when records are found.
  2. Choose the Mailbox profile. Use Google and Yahoo bulk baseline for the common Gmail/Yahoo preflight, Outlook.com high-volume for Microsoft consumer mailboxes, or Strict multi-provider launch when you want lower complaint and stronger DMARC policy gates.
  3. Set Daily receiver volume, Message stream, Visible From domain, and Reported spam rate. The volume and stream choices change whether high-volume and one-click unsubscribe checks are treated as blocking.
  4. Paste Sample headers or evidence notes from a real message. Include Authentication-Results, DKIM-Signature, From, List-Unsubscribe, List-Unsubscribe-Post, ARC, List-ID, TLS notes, and any provider checklist evidence you have.
  5. Use Evidence preset, Browse TXT, Ready sample, or Reset only to load or clear evidence. Switch back to custom evidence before signing off a live sender.
  6. Open Advanced when PTR, TLS, unsubscribe SLA, sender role, message format, DKIM selectors, or resolver choice changes the review. Add the exact DKIM selectors used by your ESP because generic DNS cannot discover every selector.
  7. Read Requirements Scorecard first. If the summary says Launch blocked, use Remediation Queue before relying on the coverage map, launch report, or JSON export.
A low-volume warning is not a clean pass. It means the selected profile's high-volume threshold may not apply yet, but SPF, DKIM, DMARC, unsubscribe, and complaint evidence should still be fixed before volume grows.

Interpreting Results:

The summary score is useful for progress, but the fail count decides launch readiness. Launch blocked means at least one required row failed for the selected profile. Evidence gaps means the sender may be close, but the checker lacks enough DNS, header, or operational proof. Ready to monitor means the rows currently pass and complaint monitoring remains the next operational check.

  • Requirements Scorecard shows each row's status, evidence, action, and weight. Fix failed authentication, alignment, unsubscribe, and spam-rate rows before lower-weight warnings.
  • Authentication Evidence separates message-header observations from DNS evidence, which helps catch a record that exists but did not pass on a real message.
  • Requirement Coverage Map is a coverage view, not an inbox-placement prediction. It cannot account for content, history, engagement, or hidden provider reputation data.
  • Launch Report is the clearest artifact for handing fixes to an ESP, DNS owner, deliverability team, or campaign operator.

A high score does not guarantee delivery. Recheck after DNS changes propagate, after the ESP rotates IPs or selectors, and after any campaign that changes list source, message type, or daily volume.

Technical Details:

Bulk sender review combines policy rules with evidence quality. A DNS TXT record can show intent, but a receiver decides from the message it actually handled. That is why SPF and DKIM are stronger when the pasted headers show pass results, and why DMARC alignment is checked against the visible From domain rather than only the domain typed into the form.

The provider profile changes several gates. Gmail and the combined Google/Yahoo profile use 5,000 messages per day as the high-volume threshold and warn at 0.10% spam rate before failing at 0.30%. Yahoo is treated as always in scope because Yahoo does not publish a fixed bulk threshold. Outlook.com uses the 5,000-message high-volume threshold, warns at 0.15%, and fails at 0.30%. The strict launch profile removes the volume threshold, warns at 0.10%, fails at 0.20%, and expects DMARC at p=quarantine or stronger.

Score Formula Core:

Each row contributes a weighted value. A pass contributes full credit, a warning contributes half credit, and a fail contributes zero. The final score is rounded to a whole number from 0 to 100.

score = round ( 100 × ∑ i=1 n wi × vi ∑ i=1 n wi )

Here w is the row weight and v is 1 for Pass, 0.5 for Warn, and 0 for Fail. A single failed high-weight row can leave a respectable percentage while still blocking the launch.

Requirement Weight Pass evidence Failure or warning trigger
Bulk volume scope 4 Daily receiver volume reaches the selected profile threshold, or the profile has no fixed threshold. Below a defined threshold warns because the sender may still need preflight work before scaling.
SPF authentication 12 Header evidence shows SPF pass, or DNS evidence at least shows an SPF record when headers are missing. SPF failure or no SPF proof after DNS lookup.
DKIM authentication 12 Header evidence shows DKIM pass, or a queried selector publishes a DKIM key when headers are missing. DKIM failure or no signed-message proof for the stream.
DMARC policy record 14 A DMARC record meets the profile's minimum policy, usually p=none and p=quarantine for strict launch. No DMARC policy after DNS lookup, or a policy weaker than the selected profile target.
DMARC alignment 14 Header DMARC pass, or SPF/DKIM domains appear aligned with the visible From domain. DMARC fail or no aligned SPF/DKIM pass evidence.
Forward and reverse DNS 8 PTR and forward-confirmed DNS are marked verified for the sending IPs. Missing or mismatched PTR/FCRDNS fails; unchecked evidence warns.
TLS transmission 6 TLS is marked verified or headers/notes show ESMTPS/TLS evidence. Missing TLS fails; unverified delivery evidence warns.
Spam complaint rate 12 Complaint rate is below the profile warning threshold. At or above the warning threshold warns; at or above the profile limit fails.
One-click unsubscribe 12 Marketing-like mail has both List-Unsubscribe and one-click POST evidence where the profile requires it. Missing one-click evidence can fail marketing or subscribed mail for Gmail/Yahoo-style profiles.
Easy unsubscribe process 8 Requests are marked as honored within 2 days and a visible body unsubscribe path is present. Slow, login-gated, or unverified unsubscribe handling fails or warns.
Message format and identity 6 Message format is marked clean and the From domain does not impersonate Gmail. RFC 5322 issues or non-Gmail infrastructure using a Gmail From domain fail.
Forwarder and list hygiene 4 Forwarding or mailing-list streams show ARC and List-ID evidence. Forwarding/list traffic without ARC or List-ID fails; one of the two warns.

Header parsing looks for common authentication and list-management signals such as SPF pass or fail, DKIM pass or fail, DMARC pass or fail, signing domains, envelope sender domains, visible From domains, ARC, List-ID, List-Unsubscribe, List-Unsubscribe-Post, body unsubscribe notes, and TLS evidence. The parser is evidence-oriented, so ambiguous notes should be replaced with a fresh delivered sample before final sign-off.

Accuracy and Privacy Notes:

DNS checks are point-in-time lookups through the selected public resolver. Pasted headers and local files are read in the browser for scoring, while DNS lookups send queried domain names, DMARC names, MX names, and DKIM selector names to the selected resolver.

  • Use headers from a real delivered message to the receiver family you care about, not only ESP setup screens.
  • Check marketing, transactional, mixed, forwarding, and mailing-list streams separately when infrastructure or identity differs.
  • Verify unsubscribe processing with operational logs because header presence does not prove the endpoint honors requests within 2 days.
  • Repeat the review after DNS propagation, selector rotation, IP pool changes, or complaint-rate spikes.

Advanced Tips:

  • Keep Visible From domain equal to the customer-facing domain unless the delivered headers prove a different From identity. DMARC alignment is judged against that visible identity.
  • Add one DKIM selector per line in DKIM selectors to query for each ESP, product, or sub-stream. A missing selector query should not be read as proof that DKIM is absent.
  • Use Strict multi-provider launch when warming a new sender or moving from monitoring to enforcement because it lowers the complaint fail limit and expects p=quarantine or stronger.
  • For forwarding services and mailing lists, set Sender role and Message stream accordingly so ARC and List-ID evidence is evaluated instead of being ignored.
  • When Authentication Evidence and DNS results disagree, trust the delivered header as the receiver-facing proof and then repair the DNS or ESP setting that caused the mismatch.

Worked Examples:

Launch-ready marketing stream

A sender reviewing 6,500 daily Gmail and Yahoo recipients chooses Google and Yahoo bulk baseline, sets the stream to marketing, enters a 0.08% complaint rate, and pastes headers with SPF pass, DKIM pass, DMARC pass, one-click unsubscribe, a visible body unsubscribe link, TLS evidence, and clean message format. The scorecard should show no blockers and the summary should move toward Ready to monitor.

Authentication record without signed-message proof

A domain publishes SPF and DMARC, but the sample headers show dkim=none and dmarc=fail. The DNS evidence helps explain the intent, but Requirements Scorecard should still prioritize DKIM signing and DMARC alignment because the receiver did not see a passing aligned message.

Complaint-rate boundary before a major send

A strict launch review with a 0.22% reported spam rate can fail even though the common Gmail/Yahoo provider limit is 0.30%. That stricter result is useful before a risky list expansion because the next action is list suppression, consent review, and throttling rather than another DNS edit.

FAQ:

Does a DMARC record alone satisfy the authentication checks?

No. DMARC passes only when SPF or DKIM passes and aligns with the visible From domain. The scorecard can warn or fail when a record exists but the pasted message does not show aligned pass evidence.

Why does Yahoo show as bulk scoped without a 5,000-message threshold?

Yahoo describes bulk senders by significant volume and does not publish a fixed threshold. The Yahoo profile treats the review as in scope so senders do not mistake an unknown cutoff for a safe exemption.

Why did one-click unsubscribe fail for marketing mail?

Marketing and subscribed mail need List-Unsubscribe plus one-click POST evidence for Gmail/Yahoo-style profiles. A body link alone can still leave the one-click row failing or warning.

Can I use DNS results instead of pasted headers?

DNS results improve SPF, DMARC, MX, and DKIM selector confidence, but delivered headers prove what the receiver actually evaluated. Use both when approving a live sender.

What should I do when the domain lookup fails?

Confirm the domain is bare, try another DNS resolver, and paste header or checklist evidence while DNS propagates. Treat the affected DNS rows as unresolved until a lookup or authoritative check succeeds.

Glossary:

SPF
Sender Policy Framework, a DNS record that authorizes mail servers for a domain.
DKIM
DomainKeys Identified Mail, a cryptographic signature that lets receivers verify message responsibility and integrity.
DMARC
A policy and alignment check that connects SPF or DKIM authentication to the visible From domain.
Visible From domain
The domain in the message From header that recipients see and DMARC alignment checks.
PTR/FCRDNS
Reverse DNS and forward-confirmed DNS evidence for the sending IP address.
One-click unsubscribe
A List-Unsubscribe header pattern that lets a mailbox provider submit an opt-out request without extra user steps.
Complaint rate
The share of delivered messages that recipients marked as spam through provider reporting.

References: