Skip to main content

Email Deliverability Checks

In addition to traditional RBL and URIBL data sources, we run a set of Email Deliverability checks that verify the DNS and HTTPS configuration most receiving mail servers use to score inbound mail. These checks are designed for IPs and domains that send mail. They catch the misconfigurations that quietly cause mail to land in spam folders or get rejected outright.

All Email Deliverability checks are opt-in. Even when your Monitoring Profile is set to Stay in-sync with us, none of the deliverability checks run unless you specifically enable them. You can pick and choose individual checks based on what's relevant to a given host.

To enable them, go to RBL Monitoring ➡️ Monitoring Profiles ➡️ Data Sources, switch to the Email Deliverability tab, and check off the ones you want.

Most hosts in your account probably aren't mail servers. A web server, a database host, or a CDN edge IP doesn't need to publish SPF, DMARC, MTA-STS, or have FCrDNS - and enabling these checks on those hosts will generate noise alerts for problems that don't actually affect anything.

The recommended pattern is to create a second Monitoring Profile specifically for your mail-sending hosts:

  1. Go to RBL Monitoring ➡️ Monitoring Profiles and click Add Profile.
  2. Name it something like "Email Servers".
  3. Open its Data Sources, switch to the Email Deliverability tab, and enable the relevant checks.
  4. On each of your mail server hosts, switch the Monitoring Profile assignment to the new Email Servers profile.

Your other (non-mail) hosts stay on your default profile and don't run any of the deliverability checks. This keeps your alert volume sane and ensures the failures you do see are actionable.

When Does a Check "Fail"?​

Unlike RBL checks (which alert you when your host appears on a blacklist), Email Deliverability checks alert you when something is misconfigured or missing. A failure means the receiver-side check would have a reason to penalize your mail, such as a missing SPF record, a PTR record that points nowhere, or an MTA-STS policy that can't be fetched.

When a check fails, it triggers exactly the same alerts and webhooks as a blacklist listing, so you can hook them into the same notification flow.

Available Checks​

IP-Based Checks​

These checks run against hosts of type IPv4 or IPv6.

Domain-Based Checks​

These checks run against hosts of type URIBL or URI.

Pricing​

Email Deliverability checks bill at the same per-check rate as any other RBL check on your account. They count toward your usage in the same way, so enabling them on a profile will increase your check volume.

Common Questions​

Why are these checks opt-in?

The deliverability checks are useful for hosts that send mail. They're noise for hosts that don't (e.g. an IP that runs a website but never sends mail doesn't need rDNS). To avoid surprising users with new alerts on hosts where they don't apply, none of these checks run unless you explicitly enable them on a Monitoring Profile.

Can I run these checks on a domain instead of an IP?

The IP-based checks (rDNS, FCrDNS, Generic PTR Pattern, PTR Format) require an IP address and only run on hosts of type IPv4 or IPv6. The domain-based checks run on hosts of type URIBL or URI.

What happens when a check fails?

You'll see the failure on the host's check history and on your Monitoring Profile reports. Webhooks fire on the same rbl.host.listed event used for blacklist listings, so you can wire failures into the same notification pipeline you already have for RBL listings.

Do you check DKIM?

Not currently. DKIM verification requires knowing the selector for your domain (e.g. default._domainkey.example.com or selector1._domainkey.example.com), and there's no standard way to discover selectors from outside the domain. We may add a DKIM check in the future once we have a per-host selector configuration.