These checks read the policies you publish for your domain and, where relevant, for your receiving mail hosts. They describe what you have declared. They do not test whether a particular message passes authentication, or whether a given receiver honors what you asked for.
The recurring theme: present is not the same as enforcing. Every record here has a valid, published, completely toothless configuration. For the encryption side of mail rather than the policy side, see how to check if your mail server uses TLS.
Record states
SPF, DMARC, MTA-STS, and TLS-RPT each report as present, absent, invalid, or DNS error. Read the syntax, the effective policy, the issues, and the reporting destinations together rather than stopping at present.
An absent record is a decision waiting to be made. A DNS error is a lookup to investigate before you make it.
SPF
SPF declares which systems may send mail for your domain. The row shows the syntax and the reported all qualifier or redirect target.
| Qualifier | What you are saying |
|---|---|
+all | Anyone may send as you. Effectively no policy |
?all | Neutral. No authorization claim at all |
~all | Softfail. This sender is probably not authorized |
-all | Fail. This sender is not authorized |
A missing all qualifier or a redirect means the rest of the policy has to be read to know what you declared.
Before tightening, inventory every system that sends mail as you: the marketing platform, the invoicing tool, the ticketing system, the CI pipeline. Each one people forget becomes a delivery failure. The result describes your published policy and is not a test of your sending paths. RFC 7208 has the semantics.
DMARC
DMARC ties authentication results to the domain your recipients actually see, and tells receivers what to do when they do not match.
Results show the published policy (none, quarantine, or reject), the percentage where provided, the alignment modes, and the reporting destinations. none asks for monitoring only. quarantine asks for suspicious treatment, reject asks for outright rejection. Receiver handling still varies. Strict and relaxed alignment describe how identifier matching is evaluated.
The safe rollout is none with reporting first, read reports until every legitimate sender is accounted for, then quarantine, then reject. See RFC 7489.
On DKIM: the DKIM alignment setting shown is part of your DMARC policy. SSLBoard does not present a DKIM-selector assessment in this report, so do not read this section as verification of your DKIM keys or of signed messages.
MTA-STS
MTA-STS lets you tell sending mail servers to require TLS when delivering to you. It has more moving parts than the others, which is why the report separates them.
Read the DNS record, the fetched policy, the mode, the syntax, and the 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 on its own establishes neither an accessible policy nor an enforcing one, and the policy’s allowed MX patterns have to agree with your real receiving hosts. See RFC 8461.
TLS-RPT
TLS-RPT names where transport-security reports should be sent. A present record does not prove reports arrive, get processed, or lead to anything.
Check the destination belongs to the operator you intended, and that a human or a system actually reads what turns up.
DANE
DANE binds your TLSA records to an MX host and port, using DNSSEC as the trust anchor. Record status can be absent, valid, invalid, or DNS error, with a separate DNSSEC status of secure, insecure, bogus, or DNS error, plus the number of matching certificate associations.
Read the association and the DNSSEC state together. A published TLSA value without the authenticated DNS context behind it is not a validated DANE deployment, it is a record nobody can trust. Different mail hosts and ports can produce different results. See RFC 7672.
Verify policy changes
Allow for DNS caching, run a fresh scan, and read the intended policy along with any remaining issue text. Then confirm real mail flow with your provider, because a correct policy and working delivery are separate claims.
Keep transport findings alongside these when diagnosing anything. Encryption in transit and sender authentication solve different problems and fail in different ways.