Domain audited: permitintelbrief.com (our own outreach domain; mailboxes eva@ and team@) Audit window: October 20–26, 2026 Method: DNS record inspection, deliverability-platform audit readings, and — decisively — inspection of the real headers of real sent mail. A domain is not "fixed" when a dashboard turns green; it is fixed when a delivered message's authentication results pass.

Every public checker said this domain was healthy. One scored it 100/100. The mail was leaving unsigned anyway: the DKIM key was published in DNS, but the sending server was not signing outbound messages with it — so the domain's most important authentication simply did not exist on the wire. The defect was isolated from real message headers, fixed at the provider, and proven fixed the only way that counts: a fresh test message whose Gmail Authentication-Results read dkim=pass, spf=pass, dmarc=pass.

The DNS side looked complete: a DKIM public-key record (1024-bit RSA) published at default._domainkey, SPF passing, DMARC configured. But a seed test sent October 23 from eva@permitintelbrief.com told the truth in its headers: spf=pass, dmarc=pass — and no dkim result at all. No DKIM-Signature header existed anywhere in the message, and the copy in the Sent folder was independently marked "DKIM: none." The provider's outbound server simply wasn't signing. Why dashboards missed it: the 100/100 health score came from a checker that inspects records, not signatures — a published key is not a signed message. The sending platform's own audit did flag "DKIM not verified" across six consecutive daily readings, and warm-up scores plateaued in the 60s while it stayed broken. Fix applied: after the provider's support confirmed the test message was unsigned and prescribed the remedy, the domain's DMARC configuration was deleted and re-set-up in the provider panel on October 26, which re-armed signing. Proof: a test send that morning (07:10 CDT) arrived with a DKIM-Signature header present and Gmail Authentication-Results reading dkim=pass (header.i=@permitintelbrief.com, header.s=default), spf=pass, dmarc=pass.

Even after the header proof, the sending platform's DKIM row still read "not verified" on the next readings — that platform verifies DKIM only from its own test traffic, not from anyone else's headers. So the audit's closing step was the platform's own inbox placement test (October 26, 25 seeds, real campaign content): 80% inbox · 0% promotions · 20% spam · 0% unreceived — Google 100% inbox, Microsoft 50% inbox / 50% spam, SMTP seeds 100% inbox. That is the honest post-fix picture: authentication repaired and proven, Google placement clean, and Microsoft placement of a young domain named plainly as the remaining weak leg instead of smoothed over.

The same audit readings flagged the draft campaign's configured volume — 80/day per mailbox — as 167% over the 30/day ceiling appropriate for a five-day-old domain. Young domains sending old-domain volume is how domains get burned; the launch configuration was set to the ceiling, to ramp weekly with age and score.

It reads headers, not just dashboards — the failure above was invisible to a 100/100 score.

It separates the three places authentication must agree: the DNS record, the real send's headers, and the platform's own verification state.

It ends with a fix list written for whoever manages your domain, and a placement test that shows where your mail actually lands, provider by provider.

And it is willing to publish its own domain's failure, fix, and imperfect placement numbers. That is the standard your domain gets too.

This report: the records checked, the header evidence, the findings in priority order, the fix list for your domain manager, and the post-fix verification — proof, not reassurance.