Tools/Email Deliverability Report

Email Deliverability Report

Predicted inbox-placement score for Gmail, Outlook/M365, Yahoo and Apple iCloud - with AI-drafted executive summary, prioritised fix list, and copy-paste DNS records. Share the saved report with a client or your team.

Critical Deliverability at risk (40/100) - 1 critical issue. Email from this domain is likely going to spam.
Overall score
40
out of 100
Grade
F
Summary
The domain example.com currently has an overall deliverability score of 40 out of 100, a grade of F, with estimated inbox placement of 35% at Gmail, 38% at Outlook/M365, 37% at Yahoo, and 43% at Apple iCloud, where the first three are rated critical and iCloud is rated poor. The report identifies one critical gap, and that single gap is the main reason mail is landing outside the inbox across all four major providers. Recommended next step: have the email operations or engineering team review and correct the flagged authentication gap on example.com, then re-run the deliverability check to confirm the score improves.
Predicted inbox placement
Gmail
critical
35/ 100 inbox
35%
Gmail downgrades unsigned mail heavily
Outlook/M365
critical
38/ 100 inbox
38%
Outlook hard-rejects senders without matching PTR
Yahoo
critical
37/ 100 inbox
37%
Yahoo enforces DMARC alignment strictly
Apple iCloud
poor
43/ 100 inbox
43%
Findings, largest impact first
Critical dkim -35 points
No discoverable DKIM

None of 50+ common ESP selectors (Google, Microsoft, SendGrid, Mailgun, AWS SES, Postmark, Maileroo, Resend, Brevo, etc.) resolved. Without DKIM, messages can't be cryptographically attributed to your domain - Gmail and Yahoo downgrade heavily.

Copy-paste fix
Type and host
TXT <selector>._domainkey.example.com
Value
v=DKIM1; k=rsa; p=<public-key>

Generate keys via /tools/dkim-generator and publish the TXT at the selector your mail provider expects.

Warning ptr -14 points
Primary MX has no PTR / reverse DNS

Outlook/Hotmail hard-rejects messages from sending servers without matching forward+reverse DNS. Gmail reduces score.

Ask your mail provider / IP owner to set a PTR record on the sending IP pointing back to the MX hostname.

Warning dmarc -5 points
DMARC has no rua reporting

Without a rua= address, you're flying blind - no visibility into which sources are failing alignment for your domain.

Copy-paste fix
Type and host
TXT _dmarc.example.com
Value
v=DMARC1; p=...; rua=mailto:[email protected]

Add rua=mailto: pointing at an inbox you monitor, or a DMARC aggregator (Postmark, Dmarcian, Valimail).

Info mta_sts -3 points
MTA-STS not published

MTA-STS forces inbound mail to use TLS and only to whitelisted MX hostnames. Strong signal to Gmail/Microsoft but not required - missing it is common, just a bonus point loss.

Steps
  1. Publish TXT at _mta-sts.example.com: 'v=STSv1; id=20261104T000000;'
  2. Serve policy file at https://mta-sts.example.com/.well-known/mta-sts.txt
  3. Start with 'mode: testing', flip to 'mode: enforce' after a week of clean TLS-RPT reports
Info tls_rpt -2 points
TLS-RPT not published

TLS-RPT tells senders where to report TLS-delivery failures for your inbound mail. Only useful paired with MTA-STS.

Copy-paste fix
Type and host
TXT _smtp._tls.example.com
Value
v=TLSRPTv1; rua=mailto:[email protected]

Only valuable if you have MTA-STS enabled.

Info bimi -1 points
BIMI not configured

Optional. Publishing a VMC-verified BIMI record makes your brand logo appear next to your emails in Gmail/Yahoo/Apple Mail - strong trust signal.

Requires DMARC at p=quarantine/reject + SVG logo hosted at HTTPS + (Gmail/Yahoo) a Verified Mark Certificate. See bimigroup.org.

Priority plan
example.com scores 40/100 (grade F), and the dominant problem is DKIM: no discoverable DKIM record was found, which is a critical finding worth 35 points of impact. Without a DKIM signature that receivers can verify, outbound mail from example.com loses one of the two primary authentication signals, so messages are more likely to land in spam or be rejected outright, particularly by providers that enforce DMARC. The PTR finding compounds this: the primary MX has no reverse DNS, and many receivers treat missing PTR records as a strong negative signal for inbound and outbound mail reputation, so deliverability suffers on both the sending and receiving side. Brand trust takes a hit too, because the domain is effectively unauthenticated from a recipient's perspective. Fix in this order. Start with DKIM: publish a TXT record at the selector you use for signing (the form is <selector>._domainkey.example.com), since this is the single largest gain and everything downstream depends on it. Confirm your signer actually uses that selector and that the signature passes before moving on. Next, add the rua reporting address to DMARC by publishing a TXT record at _dmarc.example.com, because DMARC enforcement is only as trustworthy as the visibility you have into failures; once DKIM and SPF are passing, you can move the policy toward enforcement with real data behind the decision. Set PTR (reverse DNS) for the primary MX with your hosting or mail provider, since that is a provider-side change rather than a DNS record you publish yourself. Verify SPF alignment at the same time, because DMARC passes on either aligned SPF or aligned DKIM, and you want both healthy. Once core authentication is solid, the remaining items are refinements. Publish TLS-RPT at _smtp._tls.example.com to get reports on TLS failures in inbound delivery. MTA-STS is a multi-step deployment (policy file plus DNS record) that enforces TLS for inbound mail, so plan it as a separate project after the basics are stable. BIMI is worth considering only after DMARC is at an enforcing policy, since it requires that as a prerequisite and mainly adds brand visibility in supporting mailboxes.
Creates a snapshot link that works for 30 days. Anyone with the link can view it.
Raw check data
{
  "spf": {
    "ok": "true",
    "error": "",
    "host": "example.com",
    "record": "v=spf1 -all",
    "mechanisms": [
      "-all"
    ],
    "all_mechanism": "-all",
    "includes": [],
    "ip4": [],
    "ip6": [],
    "a": [],
    "mx": [],
    "exists": [],
    "ptr": [],
    "redirect": "",
    "dns_lookups": "0",
    "status": "ok",
    "status_message": "Strict SPF (-all). Unauthorized senders are rejected."
  },
  "dmarc": {
    "ok": "true",
    "error": "",
    "host": "example.com",
    "record": "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s",
    "tags": {
      "v": "DMARC1",
      "p": "reject",
      "sp": "reject",
      "adkim": "s",
      "aspf": "s"
    },
    "policy": "reject",
    "subdomain_policy": "reject",
    "percentage": "100",
    "rua": "",
    "ruf": "",
    "alignment_dkim": "s",
    "alignment_spf": "s",
    "status": "ok",
    "status_message": "Strict DMARC policy enforced. Spoofed mail is rejected."
  },
  "mx": {
    "ok": "true",
    "error": "",
    "host": "example.com",
    "records": [
      "#<struct MxLookup::Record priority=0, exchange=\"\", ips=[]>"
    ],
    "provider": "",
    "status": "ok",
    "status_message": "MX configured (1 record(s))."
  },
  "dkim": {
    "ok": "true",
    "host": "example.com",
    "selectors_probed": "84",
    "hits": [],
    "status": "warning",
    "status_message": "No DKIM records found for 84 common selectors. Either none configured or using custom selector name.",
    "error": ""
  },
  "dnssec": {
    "ok": "true",
    "error": "",
    "host": "example.com",
    "has_dnskey": "true",
    "has_ds": "true",
    "dnskey_count": "4",
    "ds_count": "1",
    "signed": "true",
    "status": "ok",
    "status_message": "DNSSEC validates - the chain of trust from the parent zone checks out.",
    "keys": [
      {
        "tag": 36315,
        "role": "ZSK",
        "algorithm": 13,
        "algorithm_name": "ECDSAP256SHA256",
        "deprecated": false
      },
      {
        "tag": 9776,
        "role": "ZSK",
        "algorithm": 13,
        "algorithm_name": "ECDSAP256SHA256",
        "deprecated": false
      },
      {
        "tag": 34505,
        "role": "ZSK",
        "algorithm": 13,
        "algorithm_name": "ECDSAP256SHA256",
        "deprecated": false
      },
      {
        "tag": 2371,
        "role": "KSK",
        "algorithm": 13,
        "algorithm_name": "ECDSAP256SHA256",
        "deprecated": false
      }
    ],
    "ds_records": [
      {
        "tag": 2371,
        "algorithm": 13,
        "digest_type": 2,
        "digest_name": "SHA-256",
        "deprecated": false,
        "matched": true
      }
    ],
    "validation": "secure",
    "resolver_error": "",
    "issue": ""
  },
  "bimi": {
    "ok": "true",
    "error": "",
    "host": "default._bimi.example.com",
    "record": "",
    "logo_url": "",
    "authority_evidence_url": "",
    "version": "",
    "status": "info",
    "status_message": "No BIMI record at default._bimi.example.com. BIMI is optional but recommended for brand recognition in Gmail/Yahoo/Apple Mail."
  },
  "mta_sts": {},
  "tls_rpt": {},
  "ptr": {
    "ok": "false",
    "error": "Could not resolve  to an IP",
    "host": "",
    "input": "",
    "ip": "",
    "ptr_records": [],
    "status": "error",
    "status_message": "Could not resolve  to an IP"
  }
}

Scores come from deterministic rules; the summary and plan are written by Claude Haiku 5.5 and never change the numbers.

Save example.com and this check runs daily, with an email when the result changes. Sign up free