PD Email Deliverability for WHMCS and Blesta

"My emails aren't arriving" is now a support ticket you can prevent.

Gmail rejects unauthenticated bulk mail outright. Microsoft followed. A domain with no SPF record, a DMARC record still sitting at p=none, a second SPF record somebody added last year, or an SPF record that quietly crossed the ten-lookup limit will land in spam or bounce — and you find out from the customer.

PD Email Deliverability checks every domain on an active hosting service and every domain in your WHMCS or Blesta domain list, grades it A to F, and tells you exactly what is wrong.

How it works

You install it and, if you like, tell it which DKIM selectors your mail platform uses.

The module reads every domain you host straight from DNS on a schedule, grades SPF, DKIM, DMARC, MTA-STS and the rest, and raises a finding in plain English. For each one it shows how to fix it: the exact record to publish, where it goes, why it matters, and a button to re-check that domain the moment you have published it. Where the right value depends on who sends the customer's mail, it says so instead of inventing a record that would authorise the wrong servers.

Your customer sees nothing. You fix it before they notice — which is the entire point.

Your DNS is never changed on its own. The module tells you exactly what to publish. Where one of our DNS modules manages the zone, Publish this record now writes it for you, but only after you confirm; the rest you publish where your DNS is hosted.

It follows the standards literally

That is the whole point, because the failures that matter are the ones nobody notices:

• More than one SPF record is a permanent error, not a warning. Two carefully-written records leave a domain worse off than one sloppy one, because receivers fail SPF entirely.
• SPF permits ten DNS lookups. include, a, mx, ptr, exists and redirect each cost one; ip4, ip6 and all are free. Add a fourth mail provider and you can cross the line silently.
• +all authorises the entire internet to send as the domain — worse than having no SPF at all.
• A DMARC record whose v=DMARC1 is not first is ignored by receivers, completely.
• A DKIM key published with an empty p= has been revoked, and every message it signs will fail. It looks like a working record until you read it.

It is careful about what it does not know

DKIM selectors cannot be discovered from DNS — there is no query that asks a domain which it uses. So a key not found is reported as not found at the selectors tried, with your platform's selector configurable, rather than as a confident "no DKIM".

A TXT lookup that fails, which happens on busy apex domains, is reported as unreadable — never as "no SPF". A monitoring tool that cries wolf is worse than none.

It gives you the record, not a lecture

Where the right answer is unambiguous — a DMARC record at the policy you choose, or v=spf1 -all for a domain that sends no mail — you get the exact record to publish, ready to copy.

It never touches your DNS on its own

A wrong edit to a live SPF record stops a business's mail, so nothing is changed without you. You get the record; where the zone is managed by one of our DNS modules on this install, one confirmed click publishes it, and anywhere else you publish it where your DNS lives.

And it keeps checking

A daily sweep, so a record someone deletes becomes a finding the same day rather than a mystery three weeks later — with an optional digest of what is newly broken.