An invalid-domain error is a diagnosis to investigate, not a standardized explanation of one fault. A name can be syntactically malformed, syntactically valid but nonexistent, temporarily unresolvable, unsuitable for mail routing or rejected by a server's local identity policy. Preserve the entire diagnostic and the field it refers to before editing DNS. Changing the wrong name can disrupt working mail without addressing the error.
Identify the field and grammar
References: RFC 5321 §2.3.5, RFC 5321 §4.1.2.
Record whether the rejected value is in EHLO, MAIL FROM, RCPT TO, a visible header or a DNS record. These contexts do not share one universal grammar. For ordinary SMTP domain names, RFC 5321 defines label rules and discusses address literals separately. An underscore in an SMTP hostname is not made valid merely because underscores are used in special DNS owner names such as _dmarc or _domainkey.
RFC 5321 sections 2.3.5 and 4.1.2 are the appropriate starting points for SMTP domain syntax. Do not use a simplistic hostname regular expression to validate every email address, internationalized address or DNS record. The local fixture intentionally covers only a bounded ASCII letter-digit-hyphen name subset and reports that limit.
Separate resolution from syntax
References: RFC 1035 §4.1.1, RFC 5321 §5, RFC 7505 §3.
A syntactically valid name can return NXDOMAIN, indicating that the queried name does not exist in that DNS response. A temporary resolution failure such as SERVFAIL is not equivalent to nonexistence and should not be repaired by inventing a new SPF record. Preserve the queried owner, type, resolver, response status, answers and timestamp. Check authoritative data and delegation through the organization's normal diagnostic process when authorized.
For recipient routing, inspect MX and the applicable SMTP fallback rules rather than testing only whether the domain has a website. A domain can resolve for web use without accepting mail. A null MX explicitly states that the domain accepts no mail; it is not a missing MX record to replace casually. RFC 7505 defines this distinction. A host's A or AAAA record is not evidence of a functioning mail service.
Keep record-parser errors separate
References: RFC 7208 §4.5, RFC 7208 §4.6, RFC 7208 §6.
An authentication record can have an invalid mechanism, conflicting records or an unsupported construct while its DNS owner name is valid. Those are record interpretation problems. A duplicate SPF record is not an invalid domain label. Conversely, a correct-looking SPF value cannot repair an illegal hostname used by a client. Follow the parser and specification for the particular record rather than using a generic domain checker as the final authority.
The retained offline fixture classifies mail.example.test as valid in its narrow hostname grammar, bad_name.example.test and -bad.example.test as invalid, and missing.example.test as syntactically valid. A separate synthetic DNS mapping labels the missing name NXDOMAIN, a different name SERVFAIL and an example MX answer as null MX. No public DNS query or production correction is performed. The exercise demonstrates why these states should not collapse into one red indicator.
Repair only the confirmed cause
References: RFC 5321 §4.2.
For syntax, correct the generating application or configured identity. For DNS existence, confirm ownership and the intended service before adding a record. For temporary DNS failures, investigate resolver or authoritative availability. For SMTP policy, read the full server response and current provider documentation. Do not replace a valid identity with an unrelated domain to silence an error.
After a change, repeat the same transaction or query and retain both results. A valid syntax result, successful DNS answer and accepted SMTP command are separate checkpoints. Close the incident only when the original failing operation works under the intended security and routing policy.
Compare real SPF parser outcomes
References: RFC 7208 §4.5, RFC 7208 §4.6, RFC 7208 §6.
The retained 7 November 2026 parser test uses pyspf 2.0.14 rather than the original token whitelist. Its DNS lookup hook supplies fixed TXT answers for parser.test and performs no network lookup. The annotated positive record is v=spf1 ip4:127.0.0.2 -all: the version selects SPF, ip4 authorizes the controlled origin address, and -all fails other hosts. The parser returns pass for a query from 127.0.0.2.
Replacing the mechanism with bogus returns permerror because an unknown mechanism is not ignored. Returning two selected v=spf1 records also returns permerror, independently of whether one would authorize the host. Adding future=abc to the positive record returns pass: this is a syntactically valid unknown modifier, which RFC 7208 section 6 requires evaluators to ignore. The record annotations and exact input, expected result, actual result and parser explanation are retained for all four cases. See RFC 7208 sections 4.5, 4.6 and 6.
These observations separate invalid mechanisms, multiple selected records and unknown modifiers instead of collapsing them into one unsupported label. They are parser tests with controlled DNS input, not public DNS observations or an exhaustive SPF conformance suite. They also do not change the hostname syntax result: record semantics and the domain name containing the record are distinct layers. The original whitelist is retained only as a labelled historical subset illustration, not as the source of these standards-grounded conclusions.