An email spam test is useful only when you know what it measured. A content check can flag wording. A public DNS check can inspect records. A receiver can authenticate a message. A sending log can record SMTP acceptance. A seed inbox can show where a particular test message appeared. Each answers a different question.
A clean result at one layer does not establish the result at the next. Use this worked example to separate the evidence before deciding what to fix.
What each email test can establish
| Check | Evidence to keep | Limit |
|---|---|---|
| Content | The inspected text and the rule that flagged it | A phrase match does not measure a recipient's spam decision. |
| Public DNS and blocklists | Queried domain or IP, records, named lists, responses and time | Public configuration and list coverage do not expose a mailbox provider's private reputation or inbox decision. |
| Message authentication | Receiver's SPF/DKIM results, evaluated identities and DMARC alignment | A published record alone does not prove that a particular message authenticated. |
| SMTP acceptance | Final response after the message data, with the destination server | Acceptance establishes a transport handoff; it does not name the eventual folder. |
| Observed placement | The matched test message in each observed seed mailbox and folder | The observation covers that test and those mailboxes, not every recipient. |
These are evidence categories, not five interchangeable scores. Google's sender guidance addresses authentication, DNS, recipient feedback and sending practices; it also says third-party open rates may be inaccurate and low opens need not indicate a deliverability problem. Gmail sender guidelines.
A worked example: SPF passes, placement is unknown
Offline educational example, run September 30, 2026. We ran a local Python evaluator on synthetic files. No email was sent, no DNS or blocklist service was queried, and no seed inbox was read. The output below is an actual result of that local computation. It is not a live Folderly test, a customer result or proof that any product operates correctly.
The fixture uses example.com, example.net and example.org, reserved for documentation, plus 192.0.2.25 from a documentation address block. Do not use this configuration for sending. IANA example domains; RFC 5737.
Visible From: support@example.com
SMTP MAIL FROM: bounces@example.net
Synthetic sending IP: 192.0.2.25
Fixture TXT for example.net:
v=spf1 ip4:192.0.2.25 -all
Fixture TXT for _dmarc.example.com:
v=DMARC1; p=none; aspf=s; adkim=s
DKIM-Signature: absent
Authentication-Results: absent
Subject: Act now: confirm your workshop place
Body includes: Act now if you would like to reserve a place.1. Content: an observable phrase, no spam verdict
The local rule counts the phrase act now across the subject and body, ignoring case. It finds two occurrences. That is a reproducible text finding. We deliberately assign no spam score and no prediction: this rule is illustrative, not a measured mailbox-provider filter. Review the wording for clarity and accuracy, then investigate other layers if delivery is still in doubt.
2. Public infrastructure: configuration has a scope
The synthetic DNS file also contains an MX record and a PTR hostname whose forward A record contains the synthetic IP. The local evaluator reports those fixture facts. An MX record describes routing for incoming mail; it does not establish which IP sent an outgoing message. SMTP routing, RFC 5321.
The blocklist fixture records a simulated NXDOMAIN for illustrative-rbl.invalid and leaves a second illustrative zone unqueried. Neither is a real blocklist result. In a live investigation, retain each actual list and response separately; a timeout or unqueried list is unresolved. A check against an operator's named lists cannot establish absence from every list. Spamhaus's checker, for example, checks whether an IP or domain appears on its own blocklists. Spamhaus Reputation Checker.
3. Authentication: inspect the identity that passed
The synthetic IP matches the fixture's ip4 mechanism, so the local SPF calculation returns pass for example.net. SPF evaluates the SMTP identity and connecting IP; it is not simply a check of the visible From address. SPF identity, RFC 7208.
The visible From domain is example.com. The fixture explicitly requests strict alignment, so it does not align with example.net. There is no DKIM signature. With no aligned authenticated identifier, the expected DMARC result is fail. The p=none policy does not convert failure into a pass; it expresses no handling preference. DMARC validation and policy tags, RFC 9989.
The evaluator does not verify DKIM cryptography and rejects messages containing a signature or an Authentication-Results field. For a live message, use authentication results from a receiver within an established trust boundary; copying or inventing that field is not verification. DKIM verification, RFC 6376; authentication-result trust, RFC 8601.
4. SMTP: acceptance occurs after the data
The synthetic transcript finishes a DATA transaction with 250 2.0.0 queued as OFFLINE-001. The evaluator reports simulated_accepted. An earlier 250 after RCPT TO is insufficient: the server can still reject the message after reading its data. In a live transaction, final acceptance transfers responsibility for delivering or relaying the message. It does not identify an inbox, spam folder or later reader action. Replies after DATA, RFC 5321.
5. Placement: missing observations stay missing
The fixture has no placement observations. The output is not_measured, with zero observations and a null inbox rate. Zero observations is not zero percent placement. Nothing in the phrase count, SPF calculation or simulated SMTP response fills that gap.
A live seed test would need the actual message matched to actual observed mailboxes and folders. Report the mailbox coverage, observation period, missing results and denominator. Those measurements describe the test; they cannot establish placement for every future recipient.
Reproduce the core calculation offline
This self-contained excerpt uses Python's standard library. Save it as reproduce_core.py and run python3 reproduce_core.py. It contains the example inputs directly and performs no network requests. It is a narrow teaching calculation, not a general SPF/DMARC validator or SMTP client.
"""Self-contained, offline excerpt also printed in the article."""
from ipaddress import ip_address, ip_network
# Synthetic fixture: no email send, DNS request, DKIM check or inbox observation.
author_domain = "example.com"
mail_from_domain = "example.net"
sending_ip = "192.0.2.25"
spf_network = "192.0.2.25/32" # v=spf1 ip4:192.0.2.25 -all
policy = "none" # v=DMARC1; p=none; aspf=s; adkim=s
signature_present = False
text = "Act now: confirm your workshop place\nAct now to reserve a place."
post_data_reply = "250 2.0.0 queued as OFFLINE-001" # simulated final reply
placement_observations = []
spf_pass = ip_address(sending_ip) in ip_network(spf_network)
aligned_spf = spf_pass and author_domain.lower() == mail_from_domain.lower()
# No DKIM signature in this fixture, so no aligned DKIM pass can exist.
print("phrase_matches:", text.lower().count("act now"))
print("spf:", "pass" if spf_pass else "fail")
print("strict_spf_alignment:", aligned_spf)
print("dkim_signature_present:", signature_present)
print("dmarc:", "pass" if aligned_spf else "fail", "policy:", policy)
print("simulated_post_data_code:", int(post_data_reply[:3]))
print("placement_observations:", len(placement_observations))
print("inbox_rate:", None) # Unknown, not zero and not 100%.
Observed output:
phrase_matches: 2
spf: pass
strict_spf_alignment: False
dkim_signature_present: False
dmarc: fail policy: none
simulated_post_data_code: 250
placement_observations: 0
inbox_rate: None
The fuller local evaluator checked the unsigned message, fixture DNS table and simulated SMTP transcript. Its 14 tests passed with none skipped. They cover the identity mismatch, an aligned comparison, unsupported SPF syntax, RCPT-only responses, final deferral/rejection, invented authentication fields and absent placement. The aligned comparison changed only the envelope domain and its fixture SPF record: the calculated DMARC result became pass; placement remained unmeasured.
Choose the next check from the missing evidence
For this example, the immediate authentication question is why the envelope domain differs from the visible From domain and why no DKIM signature is present. In a real sending setup, verify the provider's authenticated domain configuration and the actual receiving headers. Do not enforce a stricter policy merely to improve a score before checking legitimate mail streams.
- Review wording: use the spam words checker for text findings, then assess the context yourself.
- Inspect public setup: Folderly Lens documents public DNS/IP and blocklist checks. Its methodology says it does not measure inbox placement or private mailbox-provider reputation. Lens methodology.
- Inspect a real message: Folderly Flash documents real-message setup checks. Its methodology separates the setup grade from placement and reports placement only when seed observations qualify. Check which evidence the specific result contains. Flash methodology.
- Measure test placement: Inbox Insights is Folderly's placement-testing product. Keep the observed test mailboxes and results separate from a claim about all recipients.
These links identify the next diagnostic job. The offline example did not validate onboarding, complete a product test or establish an outcome guarantee. For the broader distinction, read email delivery versus deliverability.
