Email Security Recon: SPF, DKIM, and DMARC Exposure in CTEM

TL;DR

• Email authentication is DNS-hosted attack surface. SPF, DKIM, and DMARC live in publicly resolvable records that change constantly — new vendors, new senders, new subdomains — and most organizations audit them once a year at best.
• The failure modes are boring and dangerous: SPF chains that blow past the 10-lookup limit, DMARC at p=none with no sp=, DKIM selectors still published for vendors you fired two years ago, MX records pointing at decommissioned hosts.
• Catching them requires continuous recon: enumerate every domain and subdomain, pull the mail records, watch for drift, and prioritize the findings a real attacker could turn into a delivered email.
• Trusteed CTEM treats mail and DNS posture as first-class attack surface alongside web, API, and network exposure — so a DMARC downgrade becomes a finding with an owner, not a surprise during due diligence.
• This guide covers the mechanics, the telemetry that matters, and a practical remediation sequence.

What is email security recon?

Email security recon is the continuous enumeration and evaluation of an organization's mail-related external attack surface: the domains it can send from, the infrastructure that signs and sends that mail, and the DNS records that tell receivers how to judge it.

Practically, it means collecting and reasoning about:

• Domains and subdomains that exist, especially the ones nobody remembers — regional sites, campaign domains, acquired brands, marketing microsites.
• Authentication records: v=spf1 TXT records, _dmarc policy records, DKIM public keys under selector._domainkey, plus the delegation CNAMEs many SaaS senders require.
• Transport security and reporting records: MTA-STS, TLS-RPT, DNSSEC, CAA, and BIMI.
• Sending infrastructure: MX hosts, mail., smtp., autodiscover. and ESP-issued hostnames, plus every third party that sends on your behalf.
• Policy semantics, not just presence: alignment mode (relaxed vs strict), the sp= subdomain policy, pct= sampling, reporting URIs, and whether an SPF chain is even valid.

The last point is where most programs stall. "We have DMARC" is not a security posture. p=none with no sp= and an SPF record in permerror is a spoofable domain with a compliance checkbox attached.

Why it matters now

Phishing and business email compromise remain the highest-yield initial access path in most incidents, and they do not require a vulnerability. They require a domain that receivers will trust. Every organization has one, and most have dozens they forgot about.

Four things have pushed this from a hygiene task into a continuous exposure problem:

• Sender sprawl. Marketing platforms, CRM, ticketing, HR, e-signature, and one-off SaaS tools all inject include: statements into SPF. Every new tool is a DNS change, and every offboarded tool leaves a stale include behind.
• Subdomain inheritance. A root policy of p=none propagates to subdomains unless sp= overrides it. Attackers spoof billing.yourdomain.com precisely because it is unmanaged and looks legitimate.
• Cloud and M&A churn. Acquisitions bring domains with existing sending history; migrations abandon MX records and DKIM selectors. Both create exposure that only appears if you look continuously.
• Audit and insurer pressure. Framework controls and security questionnaires increasingly ask for evidence of DMARC enforcement and mail transport security — evidence you have to generate, not assert.

The result: email authentication is one of the few exposure areas where a misconfigured TXT record translates directly into business loss, and where detection is passive, unauthenticated, and cheap to run at scale.

How attacks / risks work

Direct spoofing

If SPF fails or is absent and DMARC sits at p=none, an attacker can put your domain in the envelope and header From: and a nondiscerning receiver will deliver it. Even at p=quarantine, a fraction of messages is still delivered — and the quarantine notification itself becomes the social engineering payload.

Subdomain and alignment abuse

DMARC alignment is evaluated against the organizational domain under relaxed mode. Two gaps follow: a subdomain not covered by a strict sp= can be used as the sending domain, and DKIM keys published on a delegated subdomain can sign mail that aligns. Attacker-crafted mail lands with your brand and passes authentication.

SPF lookup exhaustion

RFC 7208 caps SPF evaluation at 10 DNS lookups. Long include chains routinely exceed it. The resulting permerror means receivers fall back to unpredictable behavior and DMARC can only be satisfied through DKIM alignment. Nobody notices until a signature breaks and legitimate mail starts failing.

DKIM key and selector problems

1024-bit keys, selectors never rotated, and — most commonly — public keys still published for senders that no longer exist. A leaked key that remains live is a signing capability you no longer control.

Dangling mail records

Expired SaaS tenants, decommissioned MX hosts, and vendor CNAMEs pointing at released infrastructure. Depending on what the record resolves to, these are subdomain takeover candidates and, in the worst case, paths to intercepting mail addressed to your users.

Trusted-sender compromise

An ESP, agency, or marketing platform breach means the attacker sends from your authenticated domain with your valid DKIM signature. No amount of SPF hardening helps; only anomaly detection on sending patterns and alignment reporting catches it.

Beyond authentication

Display-name spoofing, lookalike and homoglyph domains, thread hijacking from compromised mailboxes, and reply-to manipulation all bypass authentication entirely. Email auth removes the easy path; it is not an anti-phishing control on its own.

Detection and visibility

Good email security telemetry has three layers.

1. Per-domain posture records. For every domain in inventory: the full SPF record, its lookup count and validity, include-chain health, and which includes resolve to dead or unowned infrastructure; DKIM selectors found, key sizes, and how long each has been published; DMARC policy, sp=, pct=, alignment mode, and reporting URIs; MTA-STS mode, TLS-RPT presence, DNSSEC, and CAA.

2. Change detection. DNS is not static. A new include: is a new sender. A move from p=reject to p=none is a control failure. An MX change or a new vendor CNAME is an inventory event. These should generate findings on a scan cadence, not surface in an annual review.

3. Alignment and sender telemetry. DMARC aggregate (rua) reporting is the closest thing to ground truth about who actually sends as you. Route reports to a monitored destination, parse them, and treat sources that pass SPF but fail DKIM alignment — or generate volume you cannot attribute — as your highest-value signal. TLS-RPT fills in the transport-side picture.

What separates a real program from a checklist is prioritization. "DMARC record missing" on forty parked domains is not the same risk as p=none on the domain your invoices come from. Score findings on spoofability, brand sensitivity, lookalike registration activity, and whether the domain appears in customer-facing mail.

Track these over time: percentage of sending domains at p=reject, number of unauthorized sending sources, mean time to detect authentication record changes, and count of domains with unresolved dangling mail records.

Reduce risk — a practical sequence

1. Build the inventory first. Enumerate every domain and subdomain you own or operate on behalf of a brand, then resolve the mail-related records on each. You cannot secure domains you do not know exist.
2. Turn on DMARC reporting before enforcement. Deploy v=DMARC1; p=none; rua=mailto:... with a genuinely monitored destination, then parse the reports to find every legitimate and illegitimate sender.
3. Set sp= explicitly. Do not rely on subdomain inheritance. Decide the subdomain policy deliberately and document it.
4. Fix SPF before you enforce it. Audit include chains, remove dead senders, keep lookups under the 10-limit, and never use +all or ?all. Consider flattening only with monitoring, since flattened records go stale.
5. Move DKIM keys under your control. Prefer delegated subdomain signing so vendors cannot rotate keys on your organizational domain without your knowledge. Use 2048-bit keys, rotate on a schedule, and delete selectors for former vendors.
6. Ramp to enforcement in stages. Step up through p=quarantine with pct= while watching reporting for legitimate mail that fails, then move to p=reject.
7. Add MTA-STS and TLS-RPT. Enforce transport security so SMTP downgrade and STARTTLS stripping are both detectable and rejected.
8. Sweep for dangling records continuously. Retire MX records, CNAMEs, and subdomains tied to decommissioned services, and confirm no mail-bearing hostname resolves to infrastructure you no longer control.
9. Monitor lookalike registrations. Track newly registered domains resembling your brand and route confirmed impersonation to takedown or blocklisting.
10. Alert on authentication DNS changes. Treat a modified SPF or DMARC record with the same seriousness as a changed firewall rule — because it is one.
11. Correlate mail exposure with the rest of the attack surface. A spoofable domain, an exposed admin portal, and a leaked API key are one campaign, not three tickets.
12. Measure and report. Track enforcement coverage, unauthorized senders, and time-to-remediate by domain — and report the trend, not the snapshot.

How Trusteed CTEM helps

• Attack surface and asset inventory for mail-bearing domains. Trusteed CTEM discovers domains, subdomains, services, and technologies across your external surface — including records nobody remembers — so mail posture is evaluated against the real inventory rather than a spreadsheet.
• Mail and DNS posture scanning inside the scan plan. SPF, DKIM, and DMARC checks sit alongside network, web, API surface, and SSL/TLS scanning, with ongoing scan plans instead of a point-in-time audit.
• Correlation, not isolated findings. Email weaknesses are reasoned about in the same exposure graph as exposed services and vulnerable software, so prioritization reflects what an attacker could realistically chain.
• A validation and SOC gate. Findings are validated against exploitability and business context before reaching analyst queues, so hygiene noise on parked domains does not drown the handful of domains that genuinely matter.
• Continuous re-evaluation. Because scans repeat, drift in authentication records resurfaces as a finding — the kind of change teams currently miss for quarters at a time.
• Compliance and reporting views. Framework-oriented reporting turns mail posture into evidence for auditors and customer questionnaires instead of a manual data-gathering exercise.

Trusteed CTEM vs point tools

Capability	Typical point tool (CLI scanner, DNS checker, one-off audit)	Trusteed CTEM
Discovery	You supply the domain list	Discovers domains, subdomains, and services continuously
Cadence	Point-in-time or manual	Ongoing scan plans that resurface change
Email depth	Single-record lookup (SPF or DMARC or DKIM)	Mail/DNS posture evaluated alongside the wider external surface
Correlation	Isolated output	Findings linked across web, API, network, and mail exposure
Prioritization	Pass/fail or raw record dump	Validated against exploitability and business context
SOC noise	Every record becomes a ticket	Actions gated so queues hold actionable risk
Reporting	Raw output or spreadsheet	Framework-oriented views and customer-ready reporting
Operator workflow	Local runs, manual triage	Centralized at app.trusteed.io with vulnerability intelligence from trusteed.io

Point scanners are not the problem — they are the signal source. The gap is everything after the scan: inventory, correlation, validation, prioritization, and the workflow that turns a record into a closed finding.

FAQ

What is email security recon? It is the continuous enumeration and assessment of an organization's mail-related external attack surface — domains, sending infrastructure, and DNS records such as SPF, DKIM, DMARC, MTA-STS, and MX — to identify where an attacker could send mail that receivers would trust.

Is running email recon legal and safe? Yes, when scoped to domains you own or are authorized to assess. The work is essentially DNS lookups against publicly resolvable records. No mail is sent to third parties, no authentication is attempted, and nothing is exploited.

Does DMARC at p=reject stop phishing? No. It stops unauthenticated mail that claims to be from your domain. Display-name spoofing, lookalike domains, compromised mailboxes, and attackers sending from your own authenticated third-party senders are all unaffected. Enforcement is necessary, not sufficient.

Why do subdomains keep getting spoofed when our root DMARC looks fine? Because DMARC policy inherits to subdomains unless an sp= tag overrides it. If the root is p=none, subdomains are usually unprotected. Setting sp=reject explicitly and confirming alignment behavior on delegated DKIM subdomains closes the gap.

Our SPF record looks valid — why does mail fail authentication? Check the DNS lookup count. RFC 7208 caps evaluation at 10 lookups, and long include chains routinely exceed it, producing permerror. Receivers then fall back to unpredictable behavior and DMARC depends entirely on DKIM alignment.

How is CTEM different from running scanners like Nuclei, Trivy, or a DNS checker? Scanners produce signals: a template matched, a record resolved, a check failed. CTEM is the workflow around those signals — continuous discovery, asset inventory, validation against exploitability and business context, prioritization, and tracking through to remediation. Trusteed CTEM uses scanner-grade detection as an input and adds the inventory, correlation, and SOC gating layer point tools do not attempt.

How often should we re-scan mail posture? Continuously. Sender infrastructure changes monthly — new SaaS onboarding, vendor offboarding, marketing campaign domains — and DNS records can change without a change ticket. A quarterly cadence is a reasonable floor; a continuous scan plan is the actual answer.

What should I report to leadership? Percentage of sending domains at p=reject with sp=, count of unauthorized or unattributed sending sources from DMARC reporting, number of domains with dangling mail records, and mean time to remediate. Trends matter more than snapshots.

Related resources

• Trusteed CTEM platform — continuous threat exposure management for external and internal attack surface.
• Trusteed app — operator console for scan plans, findings, and validation workflow.
• Trusteed vulnerability intelligence blog — KEV and emergent-threat narratives, plus CTEM playbooks.
• NIST SP 800-177 Rev. 1 — Trustworthy Email
• CISA — DMARC and email authentication guidance
• RFC 7489 — DMARC
• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• OWASP — Phishing