Email authentication checks
This page lists the 13 email authentication checks HostRepute runs under Email authentication and in check profiles. They read the DNS records receivers use to decide whether mail really comes from you, such as SPF (Sender Policy Framework, the servers allowed to send for a domain), DMARC (what receivers should do with mail whose SPF and DKIM don’t match the From domain) and reverse DNS (the name an IP address points to).
| Check | Applies to | What it checks |
|---|---|---|
| Reverse DNS | IP addresses | Checks that the IP address has a reverse DNS (PTR) record naming a host. Many mail servers refuse mail from IP addresses without one. |
| Forward-confirmed Reverse DNS | IP addresses | Checks that the hostname in the PTR record points back to the same IP address. Receivers use this round trip to trust that the name really belongs to the sender. |
| Generic PTR Pattern | IP addresses | Checks that the PTR hostname doesn’t look like a home or dynamic connection, such as one containing “dsl” or the IP address spelled out. Generic names make mail look like it comes from a compromised computer. |
| PTR Hostname Format | IP addresses | Checks that the PTR record holds a complete hostname with a domain, which mail servers expect. |
| MX Health | Domains | Checks that the domain publishes MX records saying which servers accept its mail. Without them, replies and bounces can’t be delivered and some receivers distrust the domain. |
| SPF Record | Domains | Checks that the domain has exactly one SPF record. SPF lists the servers allowed to send its mail, and two or more records break it. |
| SPF Strict Policy | Domains | Checks that the SPF record ends with -all, so mail from servers that aren’t listed fails SPF. A softer ~all ending only marks that mail as suspicious. |
| SPF Lookup Limit | Domains | Checks that SPF stays within 10 DNS lookups (each include, a, mx, ptr, exists and redirect counts). Past that, SPF fails for every message. |
| DMARC Record | Domains | Checks that the domain has a DMARC record. DMARC tells receivers what to do with mail whose SPF and DKIM don’t match the From domain, and where to send reports. |
| DMARC Strict Policy | Domains | Checks that the DMARC policy is quarantine or reject, so mail that fails is held or refused. A p=none policy only reports; it doesn’t stop anyone from sending mail that pretends to be you. |
| MTA-STS Policy | Domains | Checks for an MTA-STS record, which tells other mail servers to deliver to you only over encrypted, verified connections. |
| TLS-RPT Record | Domains | Checks for a TLS-RPT record, which asks other mail servers to report to you when they can’t connect securely. |
| BIMI Record | Domains | Checks for a BIMI record, which lets inboxes that support it show your logo next to your mail. It only works once DMARC is set to quarantine or reject. |
Results
Section titled “Results”| Status | Meaning |
|---|---|
| Passing | This check found what it looks for. |
| Needs work | This check found something to improve, for example a PTR hostname that looks generic or isn't fully qualified. A run with such a check and no failing one reads Needs work overall; each one takes 8 points off the email authentication part of the reputation score. |
| Failing | This check found a problem, for example no SPF record, more than one SPF record or no MX record. Any failing check makes the whole run Failing; each one takes 18 points off the email authentication part of the reputation score. |
| Not checked | The check doesn't apply to the target, for example a domain-only check on an IP, or it needed a PTR record that isn't there. A run where nothing applied reads Not checked overall. |
| All good | Overall result of a run where at least one check passed and none failed or needed work. |
- Applies to: a check runs only on the kind of address it is for. An IP check on a domain, or a domain check on an IP, is skipped and shows as not checked.
- DKIM isn’t checked: its record sits under a selector name that only your mail provider knows. Your provider’s dashboard can confirm it.
- Every plan includes all the checks. A one-off check uses credits; checks in a check profile with email authentication turned on run with each scheduled scan and use none. How many such profiles a team can have, and how long the history is kept, depends on the plan (see plans and limits).
Related
Section titled “Related”- Blocklists HostRepute checks lists the blocklists a check profile can include.
- Statuses and what they mean explains how email authentication feeds the reputation score.
- Glossary defines the email authentication terms.