strictmx mail health audit · €179 · 48h

Your mail lands in spam. I'll tell you exactly why.

A fixed-price audit of your sending and receiving mail setup: SPF, DKIM, DMARC, reverse DNS, reputation, TLS, MTA-STS, DANE, on any mail server and any ESP. Written report with prioritized fixes in 48 hours. €179, flat.

headers — rejected message, mx.google.com 3 findings
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=example.com ok
dkim=pass header.i=@example.com header.s=s1 ok
dmarc=fail (p=none, no alignment) header.from=example.com fail
Received: from mail.example.com ([2001:db8::2f])
PTR: missing (AAAA) — no reverse record for IPv6 sender fail
MTA-STS: policy not found at mta-sts.example.com
Get your audit — €179

one-time payment · report in 48h · no account, no call

Why not just use a free checker

Free scanners tell you that something fails. They can't read the headers of your rejected message, they don't know your MTA, and they can't rank nine warnings by which one costs you delivery. The audit is the interpretation layer: your setup, your symptom, a fix list in the order to apply it.

What gets checked

Outbound

Why you land in spam.

  • SPF — syntax, lookup count (RFC 7208 10-lookup limit), alignment
  • DKIM — keys, selectors, rotation, alignment
  • DMARC — policy, alignment mode, reporting setup
  • Reverse DNS / PTR — IPv4 and IPv6 (a classic silent Gmail killer)
  • IP & domain reputation, blocklist status
  • Header analysis of one real affected message (you send it with the intake)
  • Your MTA or ESP configuration review: any SMTP server (Postfix, Exim, OpenSMTPD, Stalwart, others) or managed sender

Inbound

rarely audited

What senders and security scanners see.

  • MX and TLS posture — protocols, ciphers, certificates
  • MTA-STS policy
  • TLS-RPT
  • DANE / TLSA
  • Certificate validity & chain
example.com zone, before and after the audit
before
_dmarc TXT "v=DMARC1; p=none"
@ TXT "v=spf1 include:_spf.a.net include:b.net
include:c.io include:d.com ~all" 11 lookups
2001:db8::2f (no PTR)
mta-sts (absent)
after
_dmarc TXT "v=DMARC1; p=quarantine; adkim=s;
rua=mailto:dmarc@example.com"
@ TXT "v=spf1 include:_spf.a.net ip4:203.0.113.24
ip6:2001:db8::2f -all" 6 lookups
2001:db8::2f PTR mail.example.com.
_mta-sts TXT "v=STSv1; id=20260812T000000"
https://mta-sts.example.com/.well-known/mta-sts.txt 200 OK
Values from a real audit, domain and addresses changed. Your report carries the same shape: the current record, the replacement, the order to apply them.

Every audit covers this ground. Which parts decide the outcome depends on what you send — the failure modes for transactional mail like password resets and receipts, opt-in newsletters under the bulk sender rules, cold outreach and internal business correspondence are genuinely different, and each of those pages works one of them through end to end.

What you receive

  1. 01 A written report (PDF/HTML). Findings ordered by severity, each with the exact DNS record or config change to apply, in the order to apply them.
  2. 02Copy-paste-ready record values for your zone.
  3. 03 One round of follow-up questions by email, included.
  4. 04 Delivered within 48 hours of receiving your completed intake form.
not included
Implementation, ESP migration, ongoing monitoring, calls.

Implementation help after the audit: a separate 30-minute session, €90.

Who's doing the audit

I run my own production mail infrastructure: OpenSMTPD and Stalwart Mail Server, Dovecot, rspamd, self-hosted for years. I debug deliverability here at the protocol level, not in a vendor dashboard.

The last hard one took a week: Gmail was dropping my mail on and off because OVH had put an IPv6 address on the interface with no PTR behind it. The IPv4 path checked out, so the free scanners reported a clean bill.

The audit is stack-agnostic: Postfix, Exim, OpenSMTPD, Stalwart, haraka, or a managed stack like Google Workspace, Microsoft 365, SES, Postmark. The protocols are the same, and the protocols are what I read.

I'm building StrictMX, a mail transport security monitoring tool. The inbound checks in this audit come from that work.

Based in the EU. The server and the mailbox that carry your intake are in Canada, which the EU covers by adequacy decision — the privacy notice says exactly what is stored, where, and for how long. Intake data is used only for the audit and deleted on request.

More about who I am and why I do this →

How it works

  1. 1 Pay €179. Stripe — card, Apple Pay, Google Pay. VAT handled at checkout, reverse charge with an EU VAT ID.
  2. 2 Fill the intake form. Domain(s), sending stack, symptom, full headers of one affected message, optional test address.
  3. 3 Within 48 hours, your report lands in your inbox.
  4. 4 Reply with questions. One follow-up round is included.

If the report isn't useful to you, say so within 14 days and I'll refund it.

€179 · one-time · no subscription

Get your audit — €179

Not sure it covers your setup? Ask before you buy: audit@strictmx.com

Questions

Will you fix it for me?

No. The report tells you exactly what to change, with the record values ready to paste, and you or your admin apply it. If you want a second pair of hands, book an implementation session after the audit.

I use Google Workspace / SES / Postmark — is this for me?

Yes. ESP setups have their own failure modes: alignment against a custom return-path, a subdomain with no DMARC policy of its own, a second sending service missing from your SPF record. Your provider's dashboard covers their side of the handoff and stops there.

I self-host — is this for me?

Especially. I self-host my own mail on OpenSMTPD and Stalwart, and self-hosted stacks are most of the hard cases. Which MTA you run makes little difference: Postfix, Exim, Stalwart, something exotic. The audit works at the DNS, protocol, and reputation level, which is the same for everyone.

Do you know my specific mail server?

Almost certainly, and it almost doesn't matter. SPF, DKIM, DMARC, PTR, TLS, MTA-STS and reputation live in DNS and on the wire, not inside your MTA. The report gives you exact records and settings to change, and where a fix is MTA-specific I'll reference your server's actual configuration directives.

What do you need from me?

The intake form: your domain(s), your sending stack, the symptom, and the full headers of one affected message. No server access, no credentials, no DNS delegation.

Why not a free checker?

A free checker lists what fails. It can't read your rejected message's headers, and it can't rank nine warnings by which one costs you delivery.

48 hours from when?

From the completed intake, not from payment. If something is missing I'll ask once, and the clock starts when you answer.

Not broken yet? Leave your email. I'm building continuous monitoring for these same checks (StrictMX). No spam, one announcement.