Free Domain Reputation Check
Check a domain against public reputation sources, understand each result, and connect it to the sending IP and message evidence that determine deliverability.
What is a domain reputation?
Domain reputation is a measure of the trustworthiness and credibility of a domain based on its sending behavior and overall online activity. Email providers and spam filters use domain reputation to determine whether emails from a specific domain should be delivered to the inbox, sent to the spam folder, or blocked entirely. Factors that influence domain reputation include spam complaint rates, bounce rates, engagement levels (like opens and clicks), and the presence of proper email authentication protocols (SPF, DKIM, and DMARC). Even if you use different IP addresses, your domain reputation follows you, making it crucial to maintain good sending practices. A strong domain reputation ensures better email deliverability and helps build trust with both email providers and recipients.
How to read your domain reputation result
| Result | What it means | What to do |
|---|---|---|
| Clean | The public sources checked returned no current domain detections. | Confirm the actual outbound IP, authentication, and a real message before treating the delivery incident as resolved. |
| One or more detections | At least one public reputation source associates the submitted domain with a listing or risk signal. | Open the source evidence, confirm it applies to your domain, fix the underlying sending or compromise issue, then follow that operator's review process. |
| Unavailable | A source could not be queried or did not return a reliable answer from the current resolver. | Treat it as unknown, not clean. Use the linked operator lookup or check again from an approved resolver. |
Run the check with the incident context
Submit the visible From domain, then preserve the campaign or message path, send time, provider, and reported symptom. A domain check is most useful when it is tied to a specific delivery event. If the problem is a rejection or spam placement, inspect the original message headers or bounce to identify the actual outbound IP and authentication identities.
A clean domain result is not an inbox guarantee
Public domain sources are one evidence layer. Mailbox providers also maintain private reputation, complaint, engagement, and recipient-specific signals that this checker cannot access. A website host's IP may also be unrelated to the system sending email. Check the confirmed outbound address with the IP reputation tool and send a representative message through the email deliverability test.
Related reputation checks
Email authentication knowledge base
Every tag and mechanism across DMARC, SPF, and DKIM — explained in one place.
DMARC
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage
- The Percentage tag is relevant exclusively for domains operating under a ‘quarantine’ or ‘reject’ policy. It specifies the proportion of email failures to which the chosen policy should apply. The remainder is managed under a less stringent policy. For instance, with ‘pct=70’ set on a domain with a ‘quarantine’ policy, this policy is enforced on only 70% of failed emails, while the other 30% are treated as if under a ‘none’ policy. Similarly, for a domain with ‘p=reject’ and ‘pct=70’, the ‘reject’ policy is applied to 70% of failures, with the remaining 30% defaulting to ‘quarantine’.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.
SPF
- v
- The version tag must exclusively be “spf1”. Incorrect or missing versions result in the SPF record being disregarded.
- ip4
- This tag lists IPv4 addresses authorized to send emails for the domain.
- ip6
- This tag specifies IPv6 addresses permitted to email on the domain’s behalf.
- a
- The A record tag permits sender validation via the domain’s IP address, defaulting to the current domain if unspecified.
- mx
- The MX record tag validates the mail server’s MX record, defaulting to the current domain if not specified.
- ptr
- The PTR tag initiates a PTR check for client IP hostnames, advised against in RFC 7208 due to excessive DNS lookups.
- exists
- The exists tag verifies the presence of an A record on the specified domain.
- include
- The include tag is crucial for accurate SPF records, confirming all listed domains/subdomains as legitimate sending sources to recipients.
- all
- The all tag is mandatory, positioned at the SPF record’s end, guiding recipients on handling emails from unauthorized sources based on its qualifiers (~, +, -, ?).
DKIM
- v
- The version tag specifies DKIM’s version, consistently required to be 1.
- p
- The public key tag, a character string created in DKIM setup, must not be left empty to remain valid.
- t
- This tag enumerates flags as a colon-separated sequence, with “y” and “s” as defined flags; any undefined flags should be disregarded.
- s
- This tag details service types relevant to the record. Absent or unrecognized service types must be overlooked by receiving servers.
- h
- This tag specifies permitted hash algorithms, defaulting to allow all. Receivers should ignore unknown algorithms, with the sender determining the list’s entries.
- n
- This tag serves as an optional note field for administrators, recommended for use only when needed.