Loading…
Loading…
Paste the Authentication-Results header from any email you received. The parser shows DKIM signers, SPF, DMARC, and which signatures align with the visible From: address, useful for verifying DKIM when your sender uses random selectors that DNS scans can't enumerate (Amazon SES, SendGrid, Mailgun, Postmark).
Free tool
Several large ESPs (Amazon SES, SendGrid, Mailgun, Postmark) sign DKIM with auto-generated random selectors that aren't enumerable from outside. A DNS-only DKIM checker will return 'not found' even when DKIM is correctly configured. The definitive verification is to read what a mail receiver actually saw: the Authentication-Results header on every email those receivers deliver.
Paste any inbound email's Authentication-Results header and the parser reports the DKIM signers (including selectors and alignment with the From: domain), SPF result, DMARC verdict, and a plain-English interpretation of what's wired up correctly and what isn't. Especially useful before raising your DMARC policy from p=none. You want concrete proof that your sending paths are aligned, not a DNS-scan heuristic.
This page is written for people searching for Authentication-Results parser, same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like. Paste your URL above for a live score on your site.
Example A, fully aligned mail (ready to raise DMARC)
Both DKIM and SPF aligned with the From: domain. DMARC pass. Safe to raise policy from p=none to p=quarantine.
DKIM signer aligned
header.i=@example.com matches header.from=example.com, DKIM alignment confirmed.
DMARC pass via both mechanisms
DMARC will pass through forwarding (DKIM survives) and through direct delivery (SPF survives). The combination is resilient.
Example B, DMARC pass via DKIM only
DKIM aligned and passing; SPF MAIL FROM is on a bounce-handling subdomain that doesn't align with From:. This is normal, many ESPs work this way.
DKIM is the load-bearing mechanism here
If DKIM signing breaks, mail will start failing DMARC immediately. Monitor reports closely after any ESP change.
Verify DKIM before raising DMARC
p=none → p=quarantine → p=reject is a one-way ratchet for mail flow. Confirm DKIM is signing and aligning before each step.
Aim for both DKIM and SPF aligned
Either alone passes DMARC, but DKIM is the more resilient leg. It survives forwarding. Configure both where possible.
Watch DMARC aggregate reports for unfamiliar senders
If a third-party tool ('AS SCorifya.com') appears in your DMARC reports, either align it (DKIM/SPF) or remove it before raising your policy.
Use this parser to verify random-selector ESPs
Amazon SES, SendGrid, Mailgun, and Postmark use randomly-generated DKIM selectors that aren't visible in DNS scans. A pasted Authentication-Results header is the cleanest way to confirm those are signing correctly.
Don't trust a single 'pass', test multiple sending paths
Transactional, marketing, password-reset, and team-notification mail may route through different senders. Test each one against an external mailbox you control.
For weights and penalties behind each category, see How Scorifya works.
Background explainers for what this tool checks.
Every email you receive has one. In Gmail, open the message → ⋮ menu → 'Show original' → copy everything after 'Authentication-Results:'. In Outlook, open the message → File → Properties → Internet headers. In Apple Mail, View → Message → All Headers.
The website scanner probes DNS for common selector names (default, google, selector1, etc.). ESPs like Amazon SES, SendGrid, Mailgun, and Postmark generate random selector names that don't appear in any curated list. The Authentication-Results header reflects what a real mail receiver did, which is the definitive source of truth.
header.i is the signing identity ('Authentication-Results: i='), typically '@your-domain.com'. header.d is the d= tag from the DKIM-Signature header, usually the same domain. header.from is the visible From: domain. DMARC alignment requires header.from to match (or be a subdomain of) header.i / header.d.
No. The parser runs entirely client-side in your browser. Nothing is sent to Scorifya's servers, logged, or stored. You can verify by opening the network tab in DevTools, there's no request when you click Parse.
DMARC checks whether the domain that authenticated (via DKIM or SPF) matches the From: domain the user sees. Relaxed alignment (the default) treats subdomains as matching the parent, 'bounces.example.com' aligns with 'example.com'. Strict alignment requires an exact match. The parser shows relaxed alignment, which is what almost everyone uses.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly, without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on config or deploying changes, you'll likely run multiple checks as you tighten things up. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.