These checks inspect published policies for the submitted domain and, where relevant, its receiving mail hosts. They do not prove that a particular message passes authentication or that every sender and receiver applies the policy.
Record states
SPF, DMARC, MTA-STS, and TLS-RPT can be reported as present, absent, invalid, or DNS error. Present means a record was found, not that it enforces a strong policy. Read syntax, effective policy, issues, and reporting destinations together.
An absent record calls for a policy decision. A DNS error calls for investigation of the lookup before making that decision.
SPF
Sender Policy Framework (SPF) describes which systems may send mail for a domain. The SPF row shows syntax and the reported all qualifier or redirect target. For an all mechanism, pass (+all) allows any sender, neutral (?all) makes no authorization claim, softfail (~all) says a sender is probably unauthorized, and fail (-all) says it is unauthorized. A missing all qualifier or a redirect needs the rest of the policy to be interpreted. The result describes the published policy, not a test of every legitimate sending service.
Before tightening it, inventory the systems authorized to send mail for the domain. Retest after changes and verify real sending paths separately.
DMARC
Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties authentication results to the visible sender domain. DMARC results show the published none, quarantine, or reject policy, the percentage where provided, alignment modes, and reporting destinations. A none policy requests monitoring without a quarantine or rejection action; quarantine requests suspicious treatment and reject requests rejection for messages that fail DMARC. Receiver handling can vary. Strict and relaxed alignment describe how identifier matching is evaluated.
The displayed DKIM alignment setting is part of the DMARC policy. SSLBoard does not present a DKIM-selector assessment in this report. Do not interpret this section as verification of every DKIM key or of signed messages.
MTA-STS
Read the DNS record, fetched policy, mode, syntax, and MX matching together. Modes are none, testing, and enforce. Fetch results can be not attempted, success, timeout, HTTP error, TLS error, or too large.
A DNS record alone does not establish an accessible or enforcing policy. The policy’s allowed MX patterns must also agree with the intended receiving hosts. See the MTA-STS specification for protocol behavior.
TLS-RPT
SMTP TLS Reporting (TLS-RPT) identifies reporting destinations for transport-security reports. A present record does not prove that reports arrive, are processed, or trigger action. Confirm that the destination belongs to the intended operator and that someone reviews incoming reports.
DANE
DNS-based Authentication of Named Entities (DANE) results associate TLSA records with an MX host and port. Record status can be absent, valid, invalid, or DNS error. The separate DNSSEC status can be secure, insecure, bogus, or DNS error, and the result includes the number of matching certificate associations.
Read the association and DNSSEC state together. A published TLSA value without the required authenticated DNS context is not equivalent to a validated DANE deployment. Different mail hosts and ports can produce different results.
Verify policy changes
Allow for DNS caching, run a fresh scan, and inspect the intended policy and remaining issue text. Then validate real mail operation with the mail provider. Keep transport findings and policy findings together when diagnosing delivery or authentication problems.
For protocol details, consult the SPF specification, DMARC specification, and SMTP DANE specification.