SPF DKIM DMARC DNSSEC in One Scan

Why Four Separate Tools Isn't a Workflow — It's a Recipe for Missed Problems

Most engineers still run email and DNS security checks the way we did in 2015: one tool for SPF, another for DKIM, another for DMARC, and a fourth for DNSSEC. Each tool gives a green tick in isolation, the engineer moves on, and nobody notices that the four greens don't actually compose into a working security posture. The problem isn't any single record — the problem is that authentication, alignment, and the underlying DNS trust chain only work when they're evaluated together.

That's the case for a unified scan. One request, one domain, one report that evaluates SPF and DKIM together (because DMARC's alignment check depends on both), DMARC against the actual From: domain (because alignment is a runtime property), and DNSSEC as the foundation that signs all of the above. This article walks through why that matters in 2026, what checks a unified scan should cover, and how to read the combined output. IntoDNS.ai runs exactly this kind of unified scan, for free, in under sixty seconds.

The Four Records, Briefly

To make the case for unification, it helps to remember what each record does on its own.

SPF — Sender Policy Framework (RFC 7208)

A TXT record on your sending domain that lists which IPs are authorised to send mail on your behalf. Receivers check the envelope sender (return-path) domain against this list. If the IP isn't authorised, SPF fails.

DKIM — DomainKeys Identified Mail (RFC 6376)

A cryptographic signature added to outbound mail headers. The public key lives at a selector-specific subdomain (<selector>._domainkey.example.com). Receivers verify the signature against the published key. If the signature doesn't match, DKIM fails.

DMARC — Domain-based Message Authentication (RFC 7489)

A policy record at _dmarc.example.com that tells receivers what to do when SPF and DKIM disagree with the visible From: domain. Also specifies reporting endpoints so you can see what's happening at scale.

DNSSEC — DNS Security Extensions (RFC 4033/4034/4035)

A cryptographic signing layer on your DNS zone. Signed responses carry proof that the data came from the authoritative source and wasn't tampered with in transit. Without DNSSEC, any of the above records can be spoofed at the DNS level, and everything downstream is only as trustworthy as the resolver that fetched it.

Why Four Scans Miss Problems

Run four separate tools and the following failure modes routinely slip through:

SPF passes, DKIM passes, DMARC fails. A very common pattern. The return-path domain and the From: domain don't align, so SPF passes on the wrong domain. DKIM is signed by a different organisational domain than the From:. Both individual checks show green, DMARC fails, and the mail gets quarantined. No single tool reveals it — you need to see SPF, DKIM, and the From: domain together.
DKIM public key resolves, but no messages are actually signed. DNS presence is not the same as signature application. A DKIM selector check that stops at "the record exists" tells you nothing about whether your vendor is actually using the key.
DMARC is p=reject, but DMARC reports reveal 40% of mail fails alignment. Without aggregate reports feeding back into the scan, you have no visibility into this.
DNSSEC is enabled, but the parent DS record was never updated. The domain has DNSKEYs but no chain of trust — every validator that checks treats the domain as insecure, not secure. A tool that just checks "DNSKEY present" reports a green tick on a broken deployment.
MTA-STS policy published, but the HTTPS policy file is a 404. The TXT record says v=STSv1, the scanner ticks it, and senders that try to enforce TLS get no policy — because the .well-known/mta-sts.txt endpoint is broken.

All five of these are silent failures under one-tool-at-a-time scanning. A unified scanner catches them because it has the cross-record context to know what to compare.

What "Alignment" Really Means

The word alignment gets thrown around a lot in email authentication, usually without definition. Here's what it actually is.

When a receiver evaluates DMARC, it looks at three domains in the message:

The envelope sender domain (also called Return-Path or MAIL FROM). This is what SPF authenticates.
The DKIM signing domain (the d= tag in the DKIM-Signature header). This is what DKIM authenticates.
The header From domain (the From: address the recipient sees). This is what DMARC cares about.

DMARC alignment requires that at least one of SPF or DKIM authenticates a domain that matches (strictly or by organisational domain) the header From. If SPF passes on bounces.marketing.example.com and DKIM signs for mailgun.org, but the header From is [email protected], neither aligns — DMARC fails, regardless of how green SPF and DKIM look in isolation.

This is why a unified scan beats four individual checks. You can't evaluate alignment without seeing all three domains at once.

The DNSSEC Foundation

DNSSEC is often treated as a separate concern, filed under "nice to have for compliance." In 2026 that framing is outdated.

Without DNSSEC, every DNS response your mail records return is trustable only as far as the resolver that fetched it. A determined attacker with position on the network (or with an off-path DNS cache-poisoning attack) can return forged SPF, DKIM, and DMARC records to a receiver, and the receiver has no way to know. The email authentication stack is built on top of DNS, and if DNS is lying, authentication is a theatre.

DNSSEC signs every record in your zone. A validating resolver walks the chain of trust from the root through the TLD to your zone, checks the signatures, and only then trusts the answers. That's what makes the SPF/DKIM/DMARC records reliable.

A Note on .ai and Other Unsigned TLDs

Not every TLD supports DNSSEC. The .ai ccTLD (Anguilla), for example, does not currently accept DS records at the registry — which means domains under .ai cannot be fully DNSSEC-signed regardless of what the domain owner does. A unified scanner should report this accurately rather than flagging it as an owner-fixable issue. The right remediation in those cases is either accept the trade-off, migrate to a DNSSEC-capable TLD, or layer other controls (MTA-STS, HSTS preload, certificate transparency monitoring) to compensate.

What a Unified Scan Should Produce

A good unified scan returns the following in one request:

DNSSEC chain-of-trust verdict: Secure, Insecure, or Bogus, with the specific step of the chain that failed if applicable.
SPF record, parsed: all mechanisms expanded, total DNS lookup count, qualifier, and PermError risk flagged if the 10-lookup limit is exceeded.
DKIM selectors discovered: common selectors probed in parallel, each with its key algorithm, key length, and a flag if the record is revoked (empty p=).
DMARC record, decoded: policy, percentage, rua/ruf destinations, alignment modes, and subdomain policy.
Alignment simulation: for each sending source discovered in SPF or DKIM, a simulated check of whether mail from that source would pass DMARC against the root domain.
MTA-STS: both the DNS record and the HTTPS policy file, with TLS enforcement mode reported.
TLS-RPT: reporting destination, if configured.
BIMI: record presence, logo URL reachability, certificate (if present) validity.
An overall score with transparent weighting, so you can see what's driving the number.

Reading the Combined Output

Here's an example of what a unified scan reveals about a real domain:

Domain: example.com

DNSSEC: SECURE (RSASHA256, DS verified at parent)

SPF: v=spf1 include:_spf.google.com include:mailgun.org -all
  - DNS lookups: 6 of 10 (OK)
  - Qualifier: -all (hardfail, OK)
  - Authorised sources: Google Workspace, Mailgun

DKIM selectors found:
  - google._domainkey.example.com  (RSA 2048, active)
  - k1._domainkey.example.com       (RSA 1024, WEAK - upgrade recommended)

DMARC: v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100
  - Policy: quarantine (OK, post-Feb-2024 compliant)
  - Reporting: rua configured
  - Alignment: adkim=r, aspf=r (relaxed)

Alignment simulation:
  - Google Workspace (aspmx.l.google.com): PASS (SPF aligns, DKIM aligns)
  - Mailgun (mxa.mailgun.org):               PARTIAL (SPF aligns, DKIM uses d=mailgun.org not example.com)

MTA-STS: enforce mode, policy reachable, valid
BIMI: record present, logo reachable, no certificate (CMC recommended)

Overall: 87/100

The alignment simulation row is what makes this a unified scan. Mailgun signs with d=mailgun.org, so DKIM alignment fails for the DMARC check — the mail still passes DMARC because SPF aligns, but if the return-path ever changes (a common consequence of vendor migrations) the whole chain breaks. A single-tool SPF check or single-tool DKIM check would never surface this.

Running the Unified Scan

You can run this exact unified scan on any domain using IntoDNS.ai. It's free, there's no signup, and the full report arrives in under sixty seconds. We intentionally link every finding to the relevant RFC so you can independently verify what we reported — the output is meant to be auditable, not a black box.

The Case for Doing It This Way

A unified scan isn't just ergonomic. It's epistemically correct. SPF, DKIM, and DMARC are a composed protocol, not three independent checks. DNSSEC is the substrate that makes all three trustable. Evaluating them one at a time is like testing the brakes, steering, and engine of a car in isolation and calling it safe to drive — each component can pass individual tests while the integrated system fails. The point of the scan is to verify the system, not the components.

NIS2 and PCI DSS 4.0 auditors have started noticing this too. The compliance framing in both regimes is shifting from "record X is present" to "demonstrable alignment and chain-of-trust validation." The unified-scan output is what evidence-grade reporting looks like in 2026.

Three Things to Fix If Your Unified Scan Comes Back Yellow

Most domains score somewhere between 60 and 85 on their first unified scan. The three fixes that move the score the fastest are:

Rotate old DKIM keys to 2048-bit RSA (or Ed25519). 1024-bit RSA keys were deprecated years ago; many receivers now treat them as failed verification outright.
Advance DMARC from p=none to p=quarantine. Monitor aggregate reports for two weeks, confirm no legitimate senders are failing, and move. p=none no longer meets Gmail/Yahoo's bulk sender requirements.
Publish a valid MTA-STS policy in enforce mode. Low effort, high signal for the overall score, and demonstrably improves TLS enforcement on inbound mail.

How the Unified Scan Handles Edge Cases

Production domains produce edge cases that toy scanners trip over. A good unified scan explicitly handles each of them:

Subdomain delegation. Many organisations use subdomains (mail.example.com, news.example.com, tx.example.com) for different sending purposes. Each subdomain can have its own SPF, DKIM, DMARC, and its own organisational domain for alignment purposes. DMARC's sp= tag controls subdomain policy independently from the main policy, and many problems live in this gap. A unified scan should detect subdomain sending sources discovered via DMARC reports and evaluate them against the sp= or implicit parent policy.

Forwarding. When a recipient forwards your mail to another address (mailing lists, corporate forwarders), SPF breaks because the forwarding server is not in your SPF record. DKIM usually survives because the forwarding server typically preserves the original signature. That's why DMARC alignment on DKIM is the resilient fallback — and why a scanner that evaluates SPF-only alignment paints a misleading picture of your forwarding robustness.

ARC (RFC 8617). Authenticated Received Chain lets intermediate forwarders preserve authentication results across hops. Newer scanners report ARC signing status on inbound test messages, which helps diagnose mailing-list and security-gateway forwarding paths.

Geographic resolver variance. A domain that resolves cleanly from a US-based scanner might resolve to stale or differing values from Asia-Pacific resolvers, typically because of geo-split authoritative servers or CDN oddities. A unified scanner that queries multiple geographies catches this class of problem; a single-location scanner misses it every time.

IDN and internationalisation. Punycode domains, non-ASCII mailbox names, and internationalised email addresses all have subtle interactions with SPF evaluation, DKIM canonicalisation, and DMARC alignment. A scanner that handles IDN correctly is ahead of most of the market.

The Cost of Not Unifying

The cost of using four separate tools instead of one unified scan is rarely measured, but it's real. Assume a security engineer spends 20 minutes per domain per week on authentication checks across four tools. Assume they manage 50 domains. That's 1,000 minutes — nearly 17 hours — of weekly engineer time spent on work a unified scan finishes in 50 minutes (50 domains × 1 minute). Over a year, that's roughly 800 engineering hours recovered. At a loaded cost of $100 per engineering hour, a unified scanner justifies itself in time savings alone, before you consider the silent failures it catches.

The quieter cost is the one you can't measure: the findings you missed because your tools didn't see them. A misaligned DKIM signature from a vendor you forgot about, a DS record that didn't update during a key rollover, a 404 on your MTA-STS policy — each one a potential breach or a deliverability collapse waiting to happen.

Compliance Framing: What Auditors Will Actually Check

NIS2, DORA, PCI DSS 4.0, and ISO 27001:2022 all push toward evidence-grade DNS and email security controls. The wording differs between regimes but the practical audit questions converge:

Can you demonstrate DNSSEC is deployed and validated end-to-end?
Can you demonstrate DMARC is in enforcement (p=quarantine or p=reject)?
Can you demonstrate DKIM keys meet modern cryptographic standards?
Can you produce historical evidence of posture over the audit period?
Can you show operational response to drift or incident in your DNS and email security configuration?

A unified scan with historical retention produces exactly the evidence these audits require. A pile of screenshots from four separate tools does not.

Scan Your Domain Now

If you've been running four tools for four records, try running one instead. Head to IntoDNS.ai, enter any domain, and get the unified SPF/DKIM/DMARC/DNSSEC/MTA-STS/BIMI report in under a minute. It's the same evidence-grade output enterprise auditors are starting to ask for, and it's free.