Every major deliverability problem in 2026 starts with authentication. SPF, DKIM and DMARC have been the baseline for a decade, but the subtleties — what counts as a pass, which alignment mode a receiver uses, how the three interact — still trip up senders who "set it up years ago and it worked."
This article is a one-page walkthrough of what each record does, what a pass actually means on the receiver side, and how the free one-click test at check.live-direct-marketing.online checks all three plus alignment in a single run.
Piecing together three separate tools (an SPF lookup, a DKIM validator, a DMARC XML parser) means jumping between outputs and missing the interactions. A one-click test that shares a single Authentication-Results view surfaces problems the isolated checks miss — especially alignment failures.
What each record does
One paragraph each, because everyone has read ten refreshers and one more will not help.
SPF
SPF (Sender Policy Framework) is a DNS TXT record that lists IPs and services allowed to send mail using your domain in the envelope MAIL FROM. Receivers check the IP of the connecting SMTP server against your record. Mismatch is a soft fail (~all) or hard fail (-all).
DKIM
DKIM (DomainKeys Identified Mail) adds a cryptographic signature header to each message. The receiver fetches the public key from selector._domainkey.yourdomain and verifies. A signature is either valid or invalid — there is no middle ground.
DMARC
DMARC (Domain-based Message Authentication) layers on top. It requires at least one of SPF or DKIM to pass and the passing domain to align with the From: header domain. A policy of p=reject tells receivers to bin failures.
SPF pass vs fail vs neutral
SPF returns one of seven results. In practice three matter.
- pass — sending IP is explicitly allowed. Result used for DMARC alignment.
- softfail — IP not allowed, but the record ends in
~all. Receiver chooses whether to accept. Gmail accepts; stricter filters may reject. - fail — IP not allowed, record ends in
-all. Usually rejected outright.
neutral, none, temperror and permerror all count as "no SPF to rely on" for DMARC purposes. The most common cause of permerror is exceeding 10 DNS lookups — a record with five include: statements that each chain into more includes. Flatten or prune.
DKIM valid signature vs alignment
A DKIM signature can be cryptographically valid but not aligned. Valid means the math checks out against the public key. Aligned means the d= tag in the signature matches (in strict mode) or shares a registered organisational domain (in relaxed mode) with the From: header.
A common failure: your ESP signs with d=esp.mailsender.combut your From is hello@yourbrand.com. DKIM is cryptographically valid. DMARC fails alignment. You land in spam. Fix: enable your ESP's custom-domain DKIM, republish the TXT record under your own domain, re-verify.
DMARC strict vs relaxed alignment
DMARC supports two alignment modes per authentication method, controlled by the aspf and adkim tags.
- Relaxed (default) — organisational domain must match. So
mail.brand.comandbrand.comalign. - Strict — full domain must match exactly.
mail.brand.comandbrand.comdo not align.
Most senders should stay on relaxed. Strict mode is for high-security scenarios (banking, government) where subdomain impersonation is part of the threat model.
What the three-in-one report looks like
A well-designed one-click test produces a view like this:
- SPF: pass (
include:_spf.google.commatched sending IP). - DKIM: pass (selector
s1, d=yourdomain.com). - DMARC: pass (DKIM aligned, policy
p=reject). - Alignment: SPF aligned ✓, DKIM aligned ✓.
When any of these fails, the report should show why, not just fail/pass. "DMARC fail because SPF aligned but DKIM signature d=esp.net does not share organisational domain with From brand.com" is a useful message. "DMARC: fail" is not.
Three common failure scenarios
SPF and DKIM pass, DMARC fails
The classic. Your ESP signs DKIM with its own domain and the envelope sender (SPF domain) is the ESP. Both authentications individually pass but neither aligns with From:. Fix: custom-domain DKIM from your ESP (standard feature).
SPF permerror because of lookup limit
Ten lookups is a hard limit per RFC 7208. Adding another ESP pushes you over. SPF then returns permerror, which counts as no-SPF for DMARC. Fix: flatten your SPF record by expanding one or two heavy include: into direct IPs, or use SPF flattening services with caution (the flattening service rebuilds when the underlying IPs change).
DKIM signed but body-hash fails
Mailing-list software, some archivers, and any relay that modifies the body (adds a footer, rewrites URLs, changes line endings) breaks the DKIM body hash. Signature validates on the header but fails on the body. Fix: put DMARC-protected domains behind ARC-aware relays only.
GlockApps includes an authentication report in its paid tier. The data it presents is the same data you can pull from any mail server's Authentication-Results header. A free one-click test that parses the same header and your live DNS gives you the same fidelity. Pay for monitoring and alerting, not for access to public-DNS authentication checks.