How the InboxGreen Checker Works

Last updated June 2026

This page explains the exact method used by the InboxGreen domain checker at /check. It covers what each check does, how results are determined, and what the tool cannot detect. Serious tools explain their limitations.

All checks query public DNS records only. No emails are sent. No private systems are accessed. Every result you see is based on the same data that every mail server in the world reads when deciding what to do with your email.

DNS Lookup Method

The checker uses PHP's native dns_get_record() function to query public DNS over the standard resolution path. Queries are made directly against the domain's authoritative DNS records via the system resolver.

TXT records are retrieved and filtered by prefix. For SPF, the checker looks for a TXT record starting with v=spf1. For DMARC, it queries _dmarc.yourdomain.com for a TXT record starting with v=DMARC1. For DKIM, it constructs selector._domainkey.yourdomain.com and checks for a valid TXT record.

DNS propagation delays apply. If you updated a record recently and the checker shows an old result, wait 15-30 minutes and check again.

SPF Validation

SPF (Sender Policy Framework) is defined in a single TXT record at your root domain. The checker validates the following:

Pass conditions

Exactly one TXT record starting with v=spf1 exists at the domain root
The record ends with -all (hard fail) or ~all (soft fail)

Warning conditions

~all instead of -all: soft fail means mail from unlisted senders is still delivered but marked. It is acceptable but weaker than hard fail.
+all: permits any server to send as your domain. This is a misconfiguration.
Estimated DNS lookup count approaching 10: SPF resolves include:, a, mx, exists, ptr, and redirect mechanisms via DNS lookups at delivery time. The RFC 7208 limit is 10. Exceeding it causes a permanent SPF fail called a "permerror".

Fail conditions

No v=spf1 TXT record found at the domain
Multiple v=spf1 records present (only the first is used, causing unpredictable behavior)

What SPF cannot tell you

SPF only covers the envelope sender (the MAIL FROM address used during SMTP). It does not validate the From: header that recipients see. A spoofed display name with a legitimate-looking From address passes SPF. DMARC alignment closes this gap.

DKIM Detection

DKIM (DomainKeys Identified Mail) works by publishing a public key in DNS at selector._domainkey.yourdomain.com. The selector name is chosen by your email provider and is not standardised. This is the core limitation of any automated DKIM checker.

How detection works

The checker probes a list of known common selectors by querying each one and looking for a valid TXT record containing both v=DKIM1 and a public key (p=) with a minimum key length. The full selector list currently probed:

selector1, selector2, selector3, default, dkim, dkim1, dkim2, mail, mail2, smtp, smtp2, s1, s2, s3, s4, k1, k2, k3, key1, key2, m1, m2, e1, e2, mx1, mx2, outbound, newsletter, sig1, google, amazonses, sendgrid, sg, em, mailgun, postmark, pm, pm2, sparkpost, sendinblue, brevo1, brevo2, brevo3, mailjet, mandrill, ac, cmail1, cmail2, hs1, hs2, hubspot1, klaviyo1, drip, intercom, zendesk1, zendesk2, fd, pardot, sfdc, et, mkt, zoho, fm1, fm2, fm3, protonmail, protonmail2, protonmail3, mxroute, mxroute2, resend, loops, icloud, apple, yandex

Pass condition

At least one selector from the list above returns a valid TXT record with v=DKIM1 and a non-empty public key.

Fail condition

No valid DKIM record found on any probed selector. This does not guarantee DKIM is absent. Your provider may use a custom selector not in the list above (for example pm, 20230601, or a UUID-style string). If you use a provider not listed here and your DKIM shows as failing, check your provider's DNS setup guide and verify the selector name directly.

What DKIM cannot tell you

DKIM detection only confirms a public key exists in DNS. It does not verify that your mail server is actively signing outgoing messages with the matching private key, or that the signature survives forwarding. A full DKIM verification requires inspecting the headers of a received message.

DMARC Parsing

DMARC (Domain-based Message Authentication, Reporting and Conformance) is published as a TXT record at _dmarc.yourdomain.com. The checker retrieves and parses this record to extract the policy and alignment settings.

Pass conditions

A valid v=DMARC1 TXT record exists at _dmarc.yourdomain.com
The policy tag is p=quarantine or p=reject

Warning conditions

p=none: monitoring mode. Receiving servers log failures and send aggregate reports to your RUA address, but take no action on failing or spoofed messages. This offers zero spoofing protection and is treated as a warning, not a pass.
No rua= tag: without an aggregate report address, you receive no data about who is sending as your domain.

Fail conditions

No TXT record found at _dmarc.yourdomain.com
Record exists but does not start with v=DMARC1

Tags parsed

The checker extracts p (policy), adkim (DKIM alignment, default relaxed), aspf (SPF alignment, default relaxed), and rua (aggregate report address). Subdomain policy (sp=) and percentage tag (pct=) are not currently surfaced in the UI but are present in the raw record.

Blacklist Checking

The blacklist checker at /tools/blacklist-checker checks your domain and its resolved IP addresses against DNS-based blocklists (DNSBLs). The lookup method uses reverse-DNS format queries: for an IP 1.2.3.4, the query is 4.3.2.1.blocklist.zone. A returned A record (typically 127.x.x.x) indicates a listing.

IP blocklists checked

Spamhaus ZEN (zen.spamhaus.org) - combined SBL, XBL, and PBL zones. The most widely used blocklist by major mail providers.
SpamCop (bl.spamcop.net) - volunteer-reported spam sources.
Barracuda (b.barracudacentral.org) - used by Barracuda email security appliances worldwide.
SORBS SPAM (spam.dnsbl.sorbs.net) - Spam and Open Relay Blocking System, spam-source zone.
Mailspike (bl.mailspike.net) - reputation-based blocklist focused on high-volume spam sources.
PSBL (psbl.surriel.com) - Passive Spam Block List, low false-positive community blocklist.
NiX Spam (ix.dnsbl.manitu.net) - German-origin blocklist used by many European ISPs and mail providers.

Domain blocklists checked

Spamhaus DBL (dbl.spamhaus.org) - domain reputation list for domains found in spam message bodies and sender addresses.
SURBL (multi.surbl.org) - domain-based blocklist checking domains found in spam message URIs. Used by SpamAssassin and many commercial filters.
URIBL (multi.uribl.com) - URI-based blocklist for domains appearing in spam. Widely used by enterprise mail gateways.

What blacklist checking cannot tell you

There are hundreds of DNSBLs. The checker covers the ten most impactful ones for real-world delivery at Gmail, Outlook, and Yahoo. A clean result here means you are not on any of the major lists used by the mail providers that handle the majority of business email. Being listed on an obscure or regional DNSBL not in this list rarely affects delivery at major providers.

List-Unsubscribe

List-Unsubscribe is an email header (defined in RFC 2369 and RFC 8058) that tells email clients to show a native unsubscribe button. Gmail and Yahoo have required this for bulk senders since February 2024.

List-Unsubscribe is an outgoing email header, not a DNS record. It cannot be verified by DNS lookup alone. The checker currently returns an "unknown" status for this field because verification requires inspecting the headers of an actual sent message from your domain.

To verify your List-Unsubscribe setup: send a test email to a Gmail address and check the raw headers (three-dot menu in Gmail, then "Show original"). Look for List-Unsubscribe and List-Unsubscribe-Post headers.

What the Tool Cannot Detect

What you might expect	Why we cannot check it
DKIM signing is active on outgoing mail	Requires inspecting a received message header, not DNS alone
SPF passes for your actual sending IP	We check the record exists and is valid, not whether your specific IP is covered
DMARC alignment passing	Alignment (SPF/DKIM domain matching the From: header) requires a live email test
List-Unsubscribe header present	Email headers are not visible in DNS
Gmail/Outlook inbox placement	Inbox placement depends on sender reputation, complaint rate, and content - not DNS alone
DKIM with a custom or UUID-style selector	We probe known common selectors only. Custom selectors are undetectable without knowing the name.
All blacklists worldwide	We check the four most impactful ones. There are hundreds of DNSBLs total.
MTA-STS and TLS-RPT	Not currently checked. These are transport-layer policies, not authentication records.
BIMI (Brand Indicators for Message Identification)	Not currently checked. Requires p=quarantine or p=reject DMARC first.

How the Health Score is Calculated

The score shown on check results is calculated as follows:

Check	Pass	Warn	Unknown
SPF	25 pts	12 pts	5 pts
DKIM	25 pts	12 pts	5 pts
DMARC	35 pts	17 pts	5 pts
List-Unsubscribe	15 pts	7 pts	5 pts

Scores map to labels: Safe (85-100), At Risk (40-84), Critical (0-39).

Check your domain now

Free SPF, DKIM, DMARC, and blacklist check. Results in under 10 seconds. No signup required.

Run a free check