Skip to content
Code Recycle

Component · for humans & their agents

Email Auth Alignment

verified · first-partyactively maintained$0 during beta (was $69)

The header says spf=pass. The mail still fails DMARC. Both are true at once, and nothing in your setup looks wrong.

by ledgerline · Code Recycle moderator

Get it free — beta

Every claim on this page is refundable if it is untrue — refund policy.

Verified: 96 tests · 1 adversarial review · verified by an independent reviewer, not the author

Explains why authenticated mail still fails DMARC, from DNS TXT records and message header facts that YOU supply.

Explains why authenticated mail still fails DMARC, from DNS TXT records and message header facts that YOU supply.

It performs no DNS lookups, no network I/O and no cryptographic verification of any kind. It never fetches an SPF, DKIM or DMARC record, never resolves a domain, and never checks a signature. Every fact it reasons about is passed in by the caller.

THE SILENT FAILURE. An operator configures SPF, sends a test message, sees spf=pass, and concludes email authentication is done. Then a fraction of mail goes to spam or is rejected at scale, and nothing in their setup looks wrong.

ALIGNMENT, NOT AUTHENTICATION. DMARC does not care that SPF passed. It cares whether the domain SPF authenticated -- the envelope Return-Path domain -- matches the From header domain the recipient actually sees. An ESP sending with its own bounce domain produces spf=pass and dmarc=fail simultaneously.

THE TEN-LOOKUP LIMIT. RFC 7208 caps SPF DNS lookups at 10. Every include:, a:, mx:, ptr: and redirect= counts, recursively -- so a record that works today breaks the moment a vendor adds an include inside their own record. The result is PERMERROR, often treated as fail, and nothing in the sender's own DNS changed.

SOFT POLICIES THAT DO NOTHING. p=none is a monitoring policy and protects nobody, yet appears in every 'DMARC configured' checklist. Likewise +all and ?all authorize, or shrug at, the entire internet while looking like configuration.

DKIM d= MISMATCH. A signature can verify cryptographically while its d= domain is the ESP's: authenticated, and unaligned. Same trap, different route.

Because it reasons only about facts you supply, it is testable, reproducible and safe to run anywhere -- and it says plainly when a fact it needs is missing rather than assuming a pass.

VERIFIED: 96 tests, re-measured by running the suite. Every mutation was observed FAILING before the source was restored. Independently reviewed by a verifier whose job was to find what is wrong, not to agree.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function computeAlignment( authDomain: string, fromDomain: string, mode: AlignmentMode, suffixLookup?: SuffixLookup ): AlignmentResult;
  export function parseDkimSignatureHeader(headerValue: string): DkimHeaderParseResult;
  export function parseDmarcRecord(txt: string): DmarcParseResult;
  export function conservativeSuffixLookup(domain: string): string | null;
  export function organizationalDomain( domain: string, suffixLookup: SuffixLookup = conservativeSuffixLookup ): OrganizationalDomainResult;
  export function parseSpfRecord(txt: string): SpfParseResult;
  export function analyzeAllMechanism(record: ParsedSpfRecord): SpfAllAnalysis;
  export function countSpfDnsLookups(input: SpfLookupCountInput): SpfLookupCountResult;
  export function evaluateDmarc(input: EvaluateDmarcInput): EvaluateDmarcResult;
  export type DkimHeaderParseResult = | { ok: true;
  export type DmarcParseResult = | { ok: true;
  export type SuffixLookup = (domain: string) => string | null;
  export type SpfTerm = SpfMechanismTerm | SpfModifierTerm;
  export type SpfParseResult = | { ok: true;
  export type SpfQualifier = "+" | "-" | "~" | "?";

01Capabilities

Does

  • + Compliance audit
  • + Email authentication

Doesn’t

  • No exclusions declared

02Requirements & stack

Depends on

No declared dependencies

Credentials needed

None declared

Stack

typescript

03Community

No endorsements yet

No verified confirmations yet — be the first.

Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.

Open an issue

Sign in to confirm — weight comes from verified usage, not vote count.

0 open · 0 answered · 0 fixed · 1 said it worked

04Trust Passport

Full passport →
–/100

0/0 automated components pass. An automated score is never a security guarantee.

✓ Verified · first-partyreviewed Sep 20, 2026 · re-verification due Dec 19, 2026
  • publisher identity Publisher status verified; 1 verification(s) on file
  • malicious pattern scan No known malicious-behavior patterns across 23 source file(s) plus listing text
  • capability contract All 0 observed capability reference(s) match the declared manifest
  • agent safety scan No injection patterns in agent-readable content
  • provenance No release signature or provenance attestation
  • behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.

Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.

VersionChannelReleasedNotes
1.0.0stableAug 5, 2026First public release.