Public DNS evidence, queried names, selectors, timestamps, and protocol records.
How Relayera interprets email authentication
Observable evidence first. Deterministic interpretation second. No synthetic security grade.
Deterministic interpretation of published SPF, DKIM, and DMARC evidence.
Resolver failures or evidence that cannot be established reliably remain unknown rather than becoming confident claims.
Published sender policy
Relayera evaluates the SPF TXT policy published for the exact domain, including syntax, mechanisms, modifiers, include and redirect dependencies, lookup risk, and terminal all policy where they can be determined.
Multiple SPF records are treated as invalid. Relayera does not label a domain with a generic “SPF pass” because an SPF result depends on message and sending-IP context.
Selector-scoped evidence
DKIM public keys are queried only for a specific selector at
selector._domainkey.domain.
Relayera does not guess or brute-force selectors. Without a supplied or previously known selector, DKIM remains not assessed rather than being declared globally absent.
Published authentication policy
Relayera interprets DMARC using the current RFC 9989 model, including published policy, subdomain and non-existent-domain policy, alignment, reporting configuration, test mode, and effective policy source.
DNS evidence describes published policy. It does not prove that a future message will pass DMARC.
Changes are semantic, not DNS noise
Observations are normalized and fingerprinted. A policy event is created only when the authentication meaning changes — for example a DMARC policy transition, an SPF terminal-policy change, or a change to a known DKIM key.
TTL changes, record ordering, and equivalent representation changes are not intended to become meaningful policy events.
Permanent reports are read from persisted state
Domain reports, authentication history, Recent, and sitemap discovery are served from persisted observations. Crawler GET requests do not initiate live DNS scans.