SPF, DKIM & DMARC validation for developers
Maildog runs full SPF, DKIM, and DMARC validation on every message your app sends into the sandbox. See exactly why a message would pass or fail authentication — alignment, signatures, and policy — before a single email reaches a real inbox.
Email authentication is invisible until it breaks
A single misconfigured DNS record sends your password resets and receipts straight to spam, or gets them bounced with a hard 550 rejection — and you usually find out in production, after a customer complains.
You can't test against a real provider safely
Sending test blasts to Gmail or Yahoo to "see if it lands" risks your domain reputation and pollutes real inboxes. There's no safe way to confirm authentication against a live receiver.
DNS and crypto are unforgiving
A trailing ~all instead of -all, a DKIM selector that points at a rotated key, or a missing body hash will silently fail authentication with no obvious error message.
DMARC alignment is subtle
SPF and DKIM can both technically "pass" while DMARC still fails, because neither authenticated domain aligns with the visible From: address that receivers actually check.
The 2024 sender requirements raised the bar
Since February 2024, Gmail and Yahoo require bulk senders to publish a valid DMARC policy and pass authentication that aligns with the From: domain. Get it wrong and your mail is throttled or rejected.
Validate real messages, not just records
Maildog is an email sandbox that captures every message your application sends and runs complete authentication analysis on it — no production sending, no inbox risk. Point your app's SMTP transport at mail.maildog.io on port 2525 (STARTTLS) or 587 and every captured message is parsed and validated against live DNS.
SPF authorization. Maildog confirms whether SPF authorizes the sending IP for the envelope-from (Return-Path) domain, evaluating every mechanism in the published v=spf1 record.
DKIM signature verification. It checks that the DKIM-Signature verifies — both the body hash and the header signature — against the public key published at selector._domainkey.yourdomain.com.
DMARC alignment. It evaluates whether DMARC would pass, including the critical question of alignment with the From: header domain and the effective policy a receiver would apply.
A faithful receiver preview. Because Maildog validates the same SPF alignment, DKIM signatures, and DMARC policy Gmail and Yahoo evaluate, you see how real receivers will treat your mail. Pair it with the tooling at /dns-security to fix records at the source.
Key features
SPF record check
Maildog resolves the v=spf1 TXT record for your envelope-from domain, evaluates every mechanism (ip4, ip6, a, mx, include), confirms the sending IP is authorized, and flags the 10-DNS-lookup limit before it triggers a permerror.
DKIM signature verification
For each DKIM-Signature header, Maildog fetches the public key, recomputes the canonicalized body hash (bh=), and cryptographically verifies the header signature (b=) — catching stale selectors and transit rewrites instantly.
DMARC alignment analysis
Maildog reads your _dmarc TXT record and evaluates whether SPF or DKIM both pass and align with the From: domain. It distinguishes relaxed vs strict alignment and shows the effective policy (none, quarantine, or reject).
Full header inspection
Inspect the raw, captured headers of any message — Return-Path, From, DKIM-Signature, Authentication-Results — side by side with Maildog's verdict. No more guessing what your mail library actually emitted.
Deliverability scoring
Maildog rolls SPF, DKIM, and DMARC results into a single deliverability signal so you can tell at a glance whether a message is inbox-ready and exactly which check needs attention.
Sandbox capture, zero risk
Every message is captured in the sandbox and never relayed to the outside world, so you can hammer your authentication setup without touching your domain reputation or polluting real inboxes.
The records and signature Maildog validates
Here is a real-world example of the three records and the DKIM signature Maildog checks, plus how to fetch them yourself with dig.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=maildog.io; s=mail2024; t=1719628800;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=dzQ8wY4kq3l1xXr7vN2cP9fH0mB6sT5aU8eK4jL1...v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
vPq7n3wZ2k...truncated...2048-bit-public-key...IDAQABv=spf1 ip4:198.51.100.25 include:_spf.maildog.io -allv=DMARC1; p=reject; rua=mailto:dmarc-rua@maildog.io; ruf=mailto:dmarc-ruf@maildog.io; adkim=s; aspf=r; pct=100# SPF
dig +short TXT maildog.io
# DKIM public key (selector "mail2024")
dig +short TXT mail2024._domainkey.maildog.io
# DMARC policy
dig +short TXT _dmarc.maildog.ioWhy developers choose Maildog
Faster debugging
Stop bisecting your mail config in production. Maildog shows the exact header, record, and check that failed, so you fix the root cause in minutes instead of hours.
Safe email testing
Every message is captured in the sandbox. Nothing reaches real inboxes, so you can hammer your authentication setup without touching your domain reputation.
Better deliverability
Ship mail that passes SPF, DKIM, and DMARC with proper alignment, so it lands in the inbox and clears the Gmail and Yahoo 2024 sender requirements.
Improved workflow
Wire Maildog into CI and QA the same way you test the rest of your app — catch authentication regressions on every build, before they ship.
Manual checks vs Maildog validation
Manual dig checks confirm your records exist. Maildog confirms your messages actually pass authentication — which is what receivers care about.
| What gets validated | Manual dig / online lookups | Maildog sandbox |
|---|---|---|
| What's validated | Raw DNS records in isolation | Real captured messages vs live DNS |
| SPF | You read the record by hand | Sending IP evaluated automatically |
| DKIM | Checks the public key exists | Body hash + signature verified on the message |
| DMARC alignment | Hard to reason about manually | Alignment with From: computed for you |
| Inbox risk | Test sends pollute real inboxes | |
| Reproducible in CI/QA | ||
| Catches the actual email |
Frequently asked questions
What is the difference between SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are three complementary email authentication standards. SPF publishes which IP addresses may send mail for a domain. DKIM cryptographically signs each message so receivers can verify it wasn't altered and came from the claimed domain. DMARC ties them together: it tells receivers what to do when SPF and DKIM results don't align with the visible From: address.
What is DMARC alignment?
DMARC alignment is the requirement that an authenticated domain match the domain in the message's From: header. SPF aligns when the Return-Path (envelope-from) domain matches From:; DKIM aligns when the signature's d= domain matches From:. DMARC passes only when at least one of SPF or DKIM both passes and aligns. Relaxed alignment allows subdomains to match; strict alignment requires an exact domain match.
How does SPF validation work?
SPF validation checks the sending server's IP against the v=spf1 TXT record published for the envelope-from (Return-Path) domain. The receiver evaluates each mechanism in order and returns a result based on the qualifier — -all (hard fail), ~all (soft fail), or +all (pass everything, never use this).
What is the SPF 10-DNS-lookup limit?
SPF allows a maximum of 10 DNS lookups during evaluation (via include, a, mx, ptr, and exists mechanisms). Exceeding it returns a permerror, which most receivers treat as an SPF failure. Flatten nested includes or consolidate providers to stay under the limit. Maildog flags records that are close to or over the limit.
What does the DKIM body hash (bh=) do?
The bh= value in a DKIM-Signature header is a cryptographic hash of the message body after canonicalization. The receiver recomputes the body hash and compares it to bh=. If they differ — for example, because a mail relay altered the body — DKIM fails even when the signature itself is otherwise valid.
Should I use 1024-bit or 2048-bit DKIM keys?
Use 2048-bit DKIM keys. 1024-bit keys are now considered cryptographically weak and some receivers may distrust them. The only caveat is that a 2048-bit public key may exceed a single DNS TXT string's 255-character limit, so it must be split into multiple quoted strings within the same record.
What does p=none, p=quarantine, and p=reject mean in DMARC?
These are DMARC enforcement policies. p=none is monitor-only — receivers report but take no action. p=quarantine tells receivers to treat failing mail as suspicious (typically routing it to spam). p=reject instructs receivers to refuse failing mail outright. Most domains start at p=none to gather rua reports, then ramp to quarantine and finally reject.
Why does my email pass SPF and DKIM but still fail DMARC?
Because DMARC requires alignment, not just authentication. If SPF passes for your Return-Path domain but that domain differs from your From: domain, SPF doesn't align. The same applies if the DKIM d= domain differs from From:. DMARC fails unless at least one mechanism both passes and aligns with From:. Maildog surfaces exactly which condition is missing.
Keep exploring
Validate email authentication before you ship
Capture a real message and see its SPF, DKIM, and DMARC verdict in seconds — then harden your records with the DNS tools.
Explore DNS security tools