emlcheck: One Email Diagnostic Tool, Six Package Registries

I started this last year as a tiny WordPress plugin because I kept getting dragged into email problems for WordPress CMS client sites and I wanted one fast way to see what was broken without juggling five tools and a bunch of DNS commands. After a while I noticed something I could not unsee: legitimate businesses are constantly getting wrecked by their deliverability while phishing and spam operations somehow show up with cleaner auth setups than half the companies trying to do the right thing.

If you send email long enough you run into the same pattern over and over – SPF is half configured, DKIM selector changed and nobody updated DNS, DMARC left at p=none forever, IP reputation quietly tanks, and then everybody acts shocked when Gmail and Outlook bury everything. Meanwhile obvious junk mail keeps landing because the bad actors are weirdly disciplined about their sender setup.

That is why I built emlcheck. I wanted one command that gives a real answer, fast, in either human output or JSON.

emlcheck check yourdomain.com --full

It checks:

• SPF record presence and syntax
• DKIM across 17 common selectors (google, mailchimp, sendgrid, amazonses, and more)
• DMARC policy and enforcement level
• MX records
• PTR (reverse DNS)
• 41 real-time blacklists

Then the project kind of took on a life of its own.

Six Registries Later

Deliverability is not a one-language problem. Go teams need this, Java teams need this, Node/Python/PHP shops need this, PowerShell admins need this. So the goal became simple: same emlcheck command everywhere, with idiomatic APIs for each stack.

Here is where it landed:

Go

go install github.com/mmediasoftwarelab/emlcheck@latest

https://pkg.go.dev/github.com/mmediasoftwarelab/emlcheck

Node.js

npm install -g mmedia-deliverability

https://www.npmjs.com/package/mmedia-deliverability

Python

pip install mmedia-deliverability
emlcheck check yourdomain.com

https://pypi.org/project/mmedia-deliverability

PHP

composer require mmediasoftwarelab/deliverability

https://packagist.org/packages/mmediasoftwarelab/deliverability

Java

<dependency>
  <groupId>com.mmediasoftwarelab</groupId>
  <artifactId>deliverability</artifactId>
  <version>1.0.0</version>
</dependency>

https://central.sonatype.com/artifact/com.mmediasoftwarelab/deliverability

PowerShell

Install-Module -Name MMedia.Deliverability
Invoke-DeliverabilityCheck -Domain yourdomain.com

https://www.powershellgallery.com/packages/MMedia.Deliverability

And for WordPress developers, there is a free plugin on WP.org: M Media Email Deliverability Inspector.

What Shipping On Each Platform Was Like

Go was the easiest. pkg.go.dev basically just works if your module and repo are clean.

npm had the passkey/browser auth flow. Once I knew that was the path it was straightforward, just different from the older OTP flow people still talk about.

PyPI is polished. The twine + authenticator workflow is clean and the package presentation is strong.

Packagist is low-friction. Hook the GitHub repo once and it keeps itself up to date.

Maven Central is the hard mode lane. DNS TXT namespace verification, GPG signing, sources and javadoc jars, metadata checks – a lot of requirements, but you end up with signed, verifiable artifacts.

PSGallery is straightforward once account setup is done, and honestly there are not enough practical tools in that ecosystem for this problem.

Why I Split It Into Six Repos

Each platform has its own GitHub repo:

• github.com/mmediasoftwarelab/emlcheck
• github.com/mmediasoftwarelab/emlcheck-node
• github.com/mmediasoftwarelab/emlcheck-python
• github.com/mmediasoftwarelab/emlcheck-php
• github.com/mmediasoftwarelab/emlcheck-java
• github.com/mmediasoftwarelab/emlcheck-powershell

Separate repos gives the flexibility for separate release cycles, separate issue queues, and docs that actually match the audience. A Java developer should land on Java docs, not Go internals. A Node user should see npm usage first, not XML snippets.

Core logic is implemented natively in each language – DNS queries, parsing, blacklist sweep – no runtime bridge hacks and no shared binary wrapper pretending to be idiomatic.

Why I Still Care About This

Deliverability failures are usually boring configuration misses, but the business impact is not boring at all. Password resets fail, onboarding emails disappear, invoices do not get seen, and sales teams think their pipeline died when really their sender reputation is broken.

All of this is diagnosable because the signals are public in DNS and reputation feeds. The gap is speed and clarity, and that is the whole point of emlcheck.

emlcheck is MIT licensed. Use it in your stack, wire it into CI, or run it manually whenever email starts acting weird and you could use some peace of mind.

GitHub: https://github.com/mmediasoftwarelab

Free WordPress plugin: https://wordpress.org/plugins/mmedia-email-deliverability-inspector/