PD Email Deliverability — SPF, DKIM & DMARC Auditing for Every Domain You Host
Find out your customers' email is broken before their customers do
Made and supported by Projektif Digital Ltd.
Runs inside PD Modules, the panel
every module installs into.
Monitoring & Alerts
The admin view of Email Deliverability — everything in one place.The admin view of Email Deliverability — everything in one place.The admin view of Email Deliverability — everything in one place.1 / 3
PD Email Deliverability checks the email authentication of every domain you host and tells you what is broken before your customers' mail starts bouncing. For each domain it reads SPF, DKIM and DMARC straight from DNS, gives it a grade from A to F, explains each problem in plain language and shows you the exact record to publish. Where one of the PD DNS modules manages the zone, you can publish the fix from the panel after you confirm.
It is built for hosting companies and email providers who are tired of finding out about a missing DMARC record from an angry customer. Gmail and Microsoft now expect authentication from anyone sending in volume, and this finds the domains that do not have it.
Why hosts choose PD Email Deliverability
Every domain, graded. It checks the domains on your hosting services and the domains registered through you, both on by default, and gives each an A to F grade. A domain with no records never grades well, so the list sorts itself into what to fix first.
Each finding comes with its fix. No finding ends at "SPF is wrong". Each shows the record to publish, built from the DMARC policy (p=none by default) and report address you set, with a Copy button.
It counts the SPF lookups you cannot see. SPF allows ten DNS lookups. The module follows includes and redirects and counts the lookups inside them. Over ten is critical, because receivers stop evaluating and SPF fails; nine or ten is a warning, because one more sender breaks it.
Honest about what DNS cannot tell it. DKIM selectors cannot be discovered from DNS, so it checks a list of common selectors that you can edit. When it finds nothing it says "no key at the selectors checked", not "no DKIM". A key published but empty is reported as revoked. A TXT lookup that fails on a domain that resolves is reported as "could not be read", never as a missing SPF record.
Rechecked without you. Domains are rechecked automatically in batches (300 by default), and a failure is reported as a failed run. An optional digest email tells you when something changes.
No account and no third-party service. Only DNS queries for the domains you host leave your server. No customer data goes anywhere.
How it works
Install it and run Check now. Domains are picked up from your hosting services and your domain list on the first check.
Read the grades. The Domains list shows every domain with its SPF and DMARC records and its grade.
Open a finding. It explains why the problem matters and gives the record to publish.
Publish and recheck. Publish it yourself, or let the module write it where a PD DNS module manages the zone, then check the domain again to close the finding.
The Domains list: every domain graded A to F, with its SPF and DMARC records and the customer it belongs to
What you get in Blesta
What it checks
SPF: no record or more than one record is critical, +all is critical, ?all or a missing all is a warning, ptr is a warning, and the ten-lookup limit is counted through includes and redirects
DKIM: looked for at the listed selectors, with revoked keys reported separately from missing ones
DMARC: missing is flagged, a malformed record is critical, p=none is a warning (switchable with "treat none as a problem"), pct below 100 is a warning and no rua address is a note
MTA-STS, TLS-RPT and BIMI are recorded when present, and their absence is never treated as a fault
Needs attention: what is wrong with each domain's email authentication, worst first, with what it means in plain words
Fixing it
Every finding explains in plain words why it matters
The exact record to publish, host name and value, built from your DMARC policy and report address
Where a PD DNS module hosts the zone, a Publish this record now button writes it after you confirm. DNS is never changed on its own
A finding: why a missing DMARC record matters, a Publish this record now button, and the exact record to copy if you prefer to publish it yourself
Running it day to day
A Needs attention list, worst first, with Check now
A Domains list with search and the records found for each domain
Domains that do not send mail are checked only when you ask. They are advised to publish a null SPF record, the cheapest protection against spoofing a domain that never sends
A grade is a summary for scanning a long list; the findings are what you act on
An optional digest email when something changes, to your chosen addresses or the system address
The assistant tools can read grades and findings
Built to be trusted
A checker that cries wolf gets switched off, so the rules are deliberately careful. A parked domain with no mail records is not treated as a broken mail setup. A lookup that failed is never reported as a missing record.
Security built in
It never changes DNS by itself. Publishing happens only when you press the button for a zone one of the PD DNS modules manages.
Only DNS queries for your domains are made. No third-party service, no account and no customer data.
One product, every feature
PD Email Deliverability is one paid module with everything included, at £15 per month or £150 per year. There are no tiers to compare.
If your subscription lapses, the domain list and the results already collected stay readable. Checks and fixes pause until you renew, and no further DNS queries are made.
Requirements
Blesta 6 or later and PHP 8.2 or later
PD Modules (free), which installs PD Email Deliverability
The ionCube Loader
Questions
Why does it say "no DKIM key found" when I definitely have DKIM?
Because DKIM selectors cannot be discovered from DNS — there is no query that asks a domain which selectors it uses. The module tries the common ones and reports honestly that it found nothing at the selectors tried. Add your platform's selector in Settings and the finding clears.
Why is having two SPF records worse than one bad one?
The standard allows exactly one. When a receiver finds two, the result is a permanent error and SPF fails entirely — so a domain with two carefully-written records is worse off than a domain with one sloppy one. They need merging into a single record.
What is the ten-lookup limit?
SPF evaluation is capped at ten DNS lookups. include, a, mx, ptr, exists and redirect each cost one; ip4, ip6 and all cost nothing. Add a fourth mail provider and you can silently cross the limit, after which receivers stop evaluating and SPF fails. The module counts them for you.
Does it change my DNS?
It never changes DNS on its own, because a wrong edit to a live SPF record stops a business's mail. Every finding comes with the exact record to publish. When the domain's zone is managed by one of our DNS modules on this install, a "Publish this record now" button writes it there after you confirm; when the DNS lives elsewhere, you publish it where it lives.
Should I set p=reject on all my customers' domains?
No — not without checking each one. p=reject tells receivers to refuse mail that fails authentication, including legitimate mail from a sender nobody remembered to add. Start at p=none, read the reports for a fortnight, then tighten.
Does a parked domain need SPF?
Not to send mail, because it does not send mail. But v=spf1 -all on a domain that never sends is the cheapest anti-spoofing measure there is. Turn on "Also check domains that do not send mail" to see which of yours are missing it.
Does anything leave my server?
Only DNS queries for the domains you host. No third-party service, no account to hold, and no customer data — a lookup contains a domain name and nothing else.
Is anything shown to my customers?
No. This is an operator tool with no client-area surface.
Which Blesta and PHP versions does it need?
Blesta 6.0 or later, on PHP 8.2 or later. It installs alongside whatever else you run — it adds its own tables and templates rather than modifying Blesta files, so it does not collide with other vendors' modules or with a customised template. Uninstalling removes its own tables and settings and leaves no orphans behind.
How do I get help?
Open a ticket from your client area, or use Get help inside the PD Modules panel, which attaches a diagnostic report — you see a preview of exactly what it contains, and can exclude any part of it, before anything is sent. Support is included with an active subscription; bug reports are welcome whatever your licence state.
What’s new in 0.2.23
Publishing a fix straight into your DNS now works for zones kept in PD Route 53 DNS, PD Google Cloud DNS, PD Cloudflare DNS, PD cPanel DNS, PD DirectAdmin DNS and PD Plesk DNS, not only PD DNS Manager, PD Azure DNS, PD PowerDNS and PD BIND 9 DNS.
If the domain list cannot be read from your billing system, the check now fails and says so, instead of reporting there are no domains and clearing the list.
The change email now lists only what is newly broken. A DMARC record that is published but not valid is reported as malformed rather than missing, and a revoked DKIM key is no longer also reported as not found.
A DMARC record whose policy is not none, quarantine or reject is now reported as malformed, because receivers ignore it.
The SPF lookup limit now counts the lookups inside the records you include, so a record that receivers already reject is no longer shown as within the limit.
Messages name your billing platform correctly.
Tables keep long explanations readable on narrower screens.
The findings list keeps its explanations readable on narrower admin screens instead of squeezing them into a thin column.
Links on this module's screens open the right client, service and product pages on every platform.
Featured
