Checking mail deliverability
Whether your mail lands in the inbox or in spam is decided largely by DNS. The mail check reads the records responsible for that live and condenses them into a score.
Where to find it
Section titled “Where to find it”Domains → your domain → Monitoring & protection → Mail check, direct address:
dash.regfish.com/my/domains/<tld>/<sld>/mailcheck
What gets checked
Section titled “What gets checked”| Record | Purpose |
|---|---|
| SPF | Which servers may send for the domain |
| DKIM | Signature the recipient uses to verify origin |
| DMARC | What the recipient should do when SPF or DKIM do not line up |
| MTA-STS | Enforces encrypted delivery instead of merely offering it |
| TLS-RPT | Reports about when encrypted delivery failed |
| BIMI | Logo next to the sender line, requires DMARC at enforcement |
The score, the grade and the MX in use sit at the top. Below that the findings, in the same four classes as the DNS doctor.
The three most common findings
Section titled “The three most common findings”Several SPF records. Exactly one is allowed. With two, SPF becomes invalid, the recipient sees a PermError, and the domain loses the SPF check entirely. The records have to be merged into one.
No DKIM on common selectors. The check tries the widespread selectors. DKIM cannot be enumerated over DNS, so a miss proves nothing: if your provider uses its own selector, everything is fine. But if DKIM really is missing, deliverability drops and DMARC can only align through SPF.
No MTA-STS. Without MTA-STS, encryption during delivery is only offered, not required. An attacker in the middle can strip it.
For SPF, DMARC, CAA and MTA-STS there is a DNS assistant that generates the matching record. The same service exists as an API under generate records.