IP Reputation Check
Check any sending IP against major blacklists and reputation databases.
What is an IP Reputation?
An IP Reputation refers to the trustworthiness of an IP address based on its history of sending emails or online activity. Email servers and security systems use IP reputation to determine whether messages from a particular IP should be delivered, flagged as spam, or blocked. Factors affecting IP reputation include spam complaints, sending volume, blacklist listings, and engagement rates. This check also runs a reverse DNS lookup on the address, returning the PTR record that maps the IP back to a hostname. Mailbox providers expect a sending IP to have one, and a missing PTR record is a common reason mail from an otherwise clean IP is treated as suspicious.
Email authentication knowledge base
What is a reverse DNS lookup?
A reverse DNS lookup takes an IP address and asks DNS which hostname that address maps back to. The answer comes from a PTR record, published in a special namespace rather than in your own domain's zone: IPv4 addresses live under in-addr.arpa with the octets reversed, so 192.0.2.25 is queried as 25.2.0.192.in-addr.arpa, and IPv6 addresses live under ip6.arpa. It is the opposite direction to an ordinary lookup, which starts with a hostname and returns an address. This tool runs that query for any IP you enter and shows the hostname it returns, or tells you plainly when no PTR record exists.
Why does my sending mail server need a reverse DNS record?
Receiving mail servers use reverse DNS as a basic identity check on whoever opened the SMTP connection. An IP with no PTR record looks anonymous, and that alone is enough for some receivers to treat the mail as suspicious or refuse it. Google's sender guidelines require bulk senders to send from IP addresses with valid forward and reverse DNS. One thing to know before you go looking for the setting: you usually cannot publish a PTR record yourself. Reverse DNS is controlled by whoever owns the IP address range (your hosting provider, cloud platform, or email service) so fixing a missing PTR record normally means asking them, not editing your own DNS zone.
What is forward-confirmed reverse DNS?
Forward-confirmed reverse DNS means the check works in both directions. You look up the IP address, get a hostname back from its PTR record, then look that hostname up as an A record for IPv4 or an AAAA record for IPv6 and confirm the original IP address appears in the answer. A PTR record on its own only proves someone published a name; forward confirmation proves the name and the address agree with each other, which is what makes it useful as an identity signal. RFC 1912 recommends that PTR and address records match for Internet hosts. Passing this check is not the same as passing authentication: it says nothing about whether a message cleared SPF, DKIM, or DMARC.
Why is IP reputation important for email deliverability?
IP reputation plays a crucial role in email deliverability because it determines how email servers perceive and handle your messages. When you send an email, receiving servers check the reputation of your sending IP address to decide whether to deliver it to the inbox, mark it as spam, or block it entirely. A strong IP reputation, built through good sending practices (e.g., low spam complaints, consistent sending volumes, and proper authentication), ensures that your emails reach your recipients. On the other hand, a poor IP reputation can result in emails being filtered into spam folders or rejected, significantly impacting communication and marketing efforts.
What factors can negatively impact my IP reputation?
Several factors can negatively impact your IP reputation and hinder email deliverability. High spam complaint rates are a major contributor, as frequent reports signal to email providers that your messages are unwanted. Sending emails to invalid or outdated addresses can result in high bounce rates, indicating poor list hygiene. Being listed on blacklists is another significant issue, often caused by sending spam-like content or failing to comply with best practices. Sudden spikes in email volume, especially without proper IP warming, can raise suspicions with receiving servers. Low engagement rates, such as poor open and click-through rates, suggest that recipients are uninterested in your emails, further damaging your reputation. Additionally, using purchased or scraped email lists often leads to spam trap hits and disengaged recipients. Failing to implement proper email authentication protocols like SPF, DKIM, and DMARC can also make your emails appear less trustworthy, increasing the chances of them being flagged as spam.
How long does it take to improve a damaged IP reputation?
Improving a damaged IP reputation can take anywhere from a few days to several weeks, depending on the severity of the damage and the corrective actions taken. Minor issues, such as a small increase in spam complaints or temporary sending spikes, may be resolved within a few days by adopting better sending practices and cleaning email lists. However, if your IP has been blacklisted or has a history of consistent poor sending habits, it can take several weeks or even months to fully recover. Key steps to speed up the process include reducing spam complaints, improving engagement rates, authenticating emails with SPF, DKIM, and DMARC, and gradually rebuilding trust through consistent, low-volume sending (a process known as IP warming). Regular monitoring of your IP reputation is essential to track improvements and ensure long-term deliverability success.
How does being blacklisted affect my IP reputation?
Being blacklisted has a significant negative impact on your IP reputation and email deliverability. When your IP address is added to a blacklist, it signals to email providers and spam filters that your emails may be suspicious or unwanted. As a result, your messages are more likely to be blocked or directed to recipients' spam folders, drastically reducing open rates and engagement. Blacklisting can occur for various reasons, including sending high volumes of spam-like content, receiving excessive spam complaints, hitting spam traps, or having poor list hygiene. The longer your IP remains on a blacklist, the more your reputation suffers, making it essential to identify the cause, resolve the issue promptly, and request removal from the blacklist. Regular monitoring and following best sending practices are key to avoiding blacklisting and maintaining a healthy IP reputation.
Can a new IP address have a bad reputation?
Yes, a new IP address can have a bad reputation, although it’s typically considered "neutral" until email activity begins. In some cases, if the IP address was previously assigned to another sender with poor sending practices, it may inherit a negative reputation. This can lead to deliverability issues even before you send your first email. Additionally, new IPs without any established reputation can be viewed with caution by email providers, making it essential to "warm up" the IP by gradually increasing sending volume to build trust. Monitoring the IP’s reputation and implementing best practices like proper email authentication (SPF, DKIM, and DMARC), maintaining clean email lists, and ensuring high engagement rates can help establish and maintain a positive reputation over time.
What’s the difference between IP reputation and domain reputation?
IP reputation and domain reputation both play crucial roles in email deliverability, but they assess trustworthiness from different angles. IP reputation is based on the sending behavior associated with a specific IP address. Email providers evaluate factors like spam complaints, bounce rates, and sending patterns to determine if emails from that IP should be delivered or blocked. This is especially important for businesses using dedicated IPs, where the sender has full control over the IP’s reputation. On the other hand, domain reputation focuses on the sender’s domain rather than the IP address. It follows the domain across different IPs and email service providers, making it a more consistent measure of trust. Even if you change your IP address, a poor domain reputation can still harm your deliverability. Email providers use domain reputation to prevent abuse from users who frequently switch IPs to avoid blacklisting. In essence, IP reputation is tied to the infrastructure sending the emails, while domain reputation is linked to the sender’s identity. Both are important, and maintaining a positive reputation for both ensures better inbox placement and overall email success.
How often should I monitor my IP reputation?
You should monitor your IP reputation regularly, with the frequency depending on your email sending volume and business needs. For businesses that send emails daily, especially in high volumes, weekly or even daily monitoring is recommended to quickly catch and address any issues that could impact deliverability. If you send emails less frequently, monthly checks may be sufficient, though more frequent monitoring is beneficial if you're running critical campaigns or notice sudden drops in engagement. Proactive monitoring helps identify problems like blacklisting, spam complaints, or bounce rate increases early, allowing you to take corrective actions before they harm your email performance. Using automated reputation monitoring tools can streamline this process and provide real-time alerts for any changes.
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 (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- 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.