{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}: {{ badge.value }}
Session-only input. Drop one TXT, EML, headers, or log file under 1 MB onto the textarea.
{{ sourceStatusLine }}
Yahoo publishes no fixed bulk threshold; Gmail and Outlook use more than 5,000 messages per day.
Enter one bare public domain. No DNS request runs until you choose Check DNS.
Provider thresholds are receiver-family specific; this is not total mail across every destination.
messages/day
Choose the stream represented by the pasted delivered-message evidence.
Keep this equal to the sending domain unless the delivered sample uses a different visible From domain.
Google recommends staying below 0.10% and avoiding 0.30% or higher; Yahoo requires below 0.30%.
%
Presets change the header and operational evidence together so pass, review, and block paths can be inspected.

{{ dnsStatusLine }}

Use the role that actually adds or changes the message before final delivery.
A clean result should come from the same delivered sample used above.
Changing the resolver affects only the next explicit DNS lookup.
One selector per line, up to 12. The sample includes common operational guesses only.
The neutral default keeps only current gaps and blockers in the queue.
{{ includeMonitoringBool ? 'Include monitoring steps' : 'Only gaps and blockers' }}
RequirementStatusEvidenceNext actionCopy
{{ row.label }}{{ statusLabel(row.status) }}{{ row.evidence }}{{ row.action }}
PriorityFix areaActionVerificationCopy
{{ row.priority }}{{ row.area }}{{ row.action }}{{ row.verification }}
No blockers or evidence gaps. Keep monitoring complaint rates and provider reports.
Evidence typeObservedDetailCopy
{{ row.type }}{{ row.observed }}{{ row.detail }}
{{ launchReport }}
Email Header Analyzer Inspect raw email headers locally to trace relay delays and compare recorded SPF, DKIM and DMARC evidence while spotting sender mismatches.
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.
DMARC DNS Record Generator Build a current or legacy DMARC TXT record with policy inheritance and reporting destinations plus DNS string splitting and rollout review.
SPF Record Generator Build an SPF TXT record from real sender paths with ordered mechanisms and lookup-budget planning plus DNS packaging and rollout checks.

Mailbox providers judge bulk mail from evidence spread across DNS, delivered-message headers, sending infrastructure, complaint reports, and unsubscribe handling. Publishing SPF, DKIM, and DMARC records is necessary, but a record alone does not prove that a real message passed authentication or aligned with the address recipients saw.

Sender scope is measured by recipient network. Gmail and Outlook.com apply their high-volume rules to domains sending more than 5,000 messages per day to their respective consumer mailboxes. Yahoo does not publish one fixed numeric threshold and can classify a sender as bulk from its sending behavior. Counts to unrelated business or consumer providers should not be combined into one reassuring average.

Mailbox familyBulk scopeCore authenticated-mail expectationComplaint and unsubscribe emphasis
Gmail personal accountsMore than 5,000 messages per daySPF and DKIM, DMARC at least p=none, and From alignmentAim below 0.10% spam and never reach 0.30%; one-click plus a visible body link for marketing and subscribed mail
Yahoo-managed mailboxesNo fixed published countSPF and DKIM, DMARC at least p=none, and From alignmentBelow 0.30%; easy unsubscribe for marketing mail and requests honored within two days
Outlook.com, Hotmail, and LiveMore than 5,000 messages per daySPF, DKIM, and DMARC at least p=none with alignmentFunctional unsubscribe and sound list hygiene are recommended; authentication failures can be rejected

DMARC passes when the visible From domain aligns with an authenticated SPF envelope domain or an authenticated DKIM signing domain. A DKIM key found in DNS is not the same as dkim=pass on a delivered message. Likewise, an SPF record proves that a policy was published, not that the sending IP was authorized for the sample.

Marketing and subscribed streams carry the strongest unsubscribe obligations. RFC 8058 one-click support uses an HTTPS address in List-Unsubscribe together with List-Unsubscribe-Post: List-Unsubscribe=One-Click. A normal link in the message body remains useful but does not replace those headers for Gmail's one-click requirement.

Complaint rate is both a compliance signal and a lagging sign of consent, targeting, and list-quality problems. Google recommends staying below 0.10% and avoiding 0.30% or higher; Yahoo requires bulk senders to stay below 0.30%. A passing snapshot should therefore lead to continued monitoring, not a one-time launch approval.

Provider rules change, and each network applies additional reputation and abuse controls that are not fully public. A readiness review organizes current evidence; it cannot guarantee inbox placement, prevent throttling, or replace the provider's own dashboards and delivery logs.

How to Use This Tool:

Use one representative delivered message and operational measurements from the same sending stream.

  1. Paste Sample headers or evidence notes from a delivered message. Replace demonstration presets before production review.
  2. Choose the Mailbox profile, then enter the sending domain, daily volume to that receiver family, message stream, visible From domain, and current complaint rate.
  3. Record whether forward and reverse DNS, TLS delivery, unsubscribe processing, and message formatting have been verified. Use Not checked yet instead of treating an assumption as a pass.
  4. Enter the actual DKIM selectors when known and choose Check DNS. DNS cannot discover arbitrary selector names, so a missed guessed selector is not proof that DKIM is absent.
  5. Read Requirements scorecard before the percentage. Clear every failed rule and replace warning assumptions with fresh header, DNS, provider-report, or operational evidence.

Interpreting Results:

The readiness label is controlled by the strongest rule outcome, not the weighted percentage.

  • Launch blocked means at least one requirement failed. A high score does not offset missing authentication, identity, unsubscribe, transport, or complaint controls.
  • Evidence gaps means no rule failed but at least one item is incomplete, inferred from DNS alone, or marked not checked.
  • Ready to monitor means all twelve checks passed for the selected evidence. Keep watching receiver-family complaints, DMARC reports, delivery responses, and changes to sending sources.

The score is useful for ordering remediation, not comparing sender reputation between providers. Provider thresholds, stream type, and available evidence change what a given number represents.

Technical Details:

Bulk-sender readiness combines observed authentication with declared operational evidence. Delivered headers take precedence for SPF and DKIM pass or failure. DNS can fill an evidence gap, but a published record produces a warning until a delivered sample shows that the corresponding authentication actually passed.

Rule Core:

CheckWeightPass evidenceWarning or failure boundary
Bulk volume scope4Profile has no fixed threshold or volume is greater than 5,000At or below 5,000 is a warning for Gmail and Outlook profiles
SPF authentication12Delivered header records SPF passDNS-only SPF is a warning; explicit header failure or checked DNS with no record fails
DKIM authentication12Delivered header records DKIM passDNS-only key or missing pass is a warning; explicit header failure fails
DMARC policy14Observed policy meets the profile minimumWeaker policy warns; checked DNS with no policy fails
DMARC alignment14DMARC passes or the parsed SPF envelope or DKIM signing domain aligns with visible FromMissing identifiers warn; explicit DMARC failure fails
Forward and reverse DNS8Verified for sending IPsNot checked warns; missing or mismatched evidence fails
TLS transmission6Declared verified or visible in a Received headerNot checked warns; recorded plaintext or failure fails
Spam complaint rate12Below the profile warning valueAt or above warning is a warning; at or above the limit fails
One-click unsubscribe12Required headers are present for covered marketing streamsList-Unsubscribe without one-click warns; missing required evidence fails
Easy unsubscribe process8Visible body link and requests honored within two days for marketing-like mailIncomplete evidence warns; missing, slow, or login-gated process fails
Message format and identity6Formatting is marked clean and sender does not impersonate GmailNot checked warns; format issues or Gmail impersonation fail
Forwarder and list hygiene4ARC and List-ID are present for forwarding or list trafficOne present warns; both absent fail; direct streams pass this rule

Formula Core:

Pass receives full credit, Warning receives half credit, and Failure receives none. The weighted sum is normalized by the total weight and rounded to the nearest whole percentage.

S=round( 100× ∑i=112wici ∑i=112wi )

w is the rule weight and c is 1 for Pass, 0.5 for Warning, or 0 for Failure. The overall label remains Launch blocked for any failure, Evidence gaps for any warning without a failure, and Ready to monitor only when all rules pass.

Profile Thresholds:

ProfileBulk thresholdSpam warningSpam failureDMARC minimum
Google and YahooMore than 5,000/day0.10%0.30%p=none
GmailMore than 5,000/day0.10%0.30%p=none
YahooNo fixed count0.10%0.30%p=none
Outlook.comMore than 5,000/day0.15%0.30%p=none
Strict multi-providerAll volumes0.10%0.20%p=quarantine

Yahoo's 0.10% value, Outlook.com's complaint boundaries, and the strict profile are conservative operating guardrails in this model unless a provider source states otherwise. The strict profile also raises the DMARC policy minimum and applies one-click expectations at all volumes.

The alignment candidate accepts an exact visible From domain match or a parsed subdomain beneath it. It can be recorded even when the corresponding SPF or DKIM row does not pass, so those authentication rows must be checked separately. This is not a complete public-suffix or DMARC evaluation. Forwarders and mailing lists receive a separate ARC and List-ID check because they can legitimately alter authentication paths.

Privacy and Accuracy Notes:

Pasted headers and loaded files are analyzed in the browser and are not sent to a server. A file may be up to 1 MB, but only the first 256 KB enters the header analysis.

  • Choosing Check DNS sends the sending domain, DMARC owner, MX owner, and entered DKIM selector owner names to the selected public resolver.
  • Header parsing recognizes common authentication and unsubscribe signals; it does not cryptographically verify DKIM, evaluate the complete SPF record, or calculate reputation.
  • Headers can contain recipient addresses, message identifiers, internal hostnames, and sending IPs. Redact sensitive values before sharing results.
  • Use current provider dashboards and a freshly delivered message for final approval. Presets and manually selected statuses are demonstration or operator evidence, not independent verification.

References: