SPF, DKIM and DMARC: What They Reveal and What They Don't

SPF, DKIM and DMARC are often grouped together under the label email authentication.

That shorthand is useful, but it can also create the wrong mental model.

The three mechanisms do not authenticate the same thing.

They answer different questions:

• SPF asks whether the SMTP client is authorized to use a particular domain in the SPF identity being checked.
• DKIM asks whether selected message content verifies against a cryptographic signature associated with a signing domain.
• DMARC asks whether an authenticated SPF or DKIM domain is aligned with the domain visible to the recipient in the message's From: field, and lets domain owners publish handling and reporting preferences.

For OSINT, these mechanisms are interesting because much of their configuration is visible through DNS and message headers.

But public configuration is not the same thing as proof of ownership, organizational maturity, deliverability, or the legitimacy of a specific email.

The right question is not:

Does this domain have SPF, DKIM and DMARC?

It is:

What identity does each mechanism authenticate, what does the published configuration reveal, and how strongly can we interpret that evidence?

The three identities are not the same

A received email can contain several relevant domains.

Consider a simplified message:

From: Alice <alice@example.com>
Return-Path: bounce@mailer.vendor.example
DKIM-Signature: ... d=vendor.example; s=mail2026; ...

The recipient sees:

alice@example.com

but SPF may authenticate:

mailer.vendor.example

and DKIM may authenticate:

vendor.example.

Those results can all be technically valid.

That still does not mean they are aligned with the visible author domain example.com.

DMARC exists largely to connect these otherwise separate domain-level authentication results to the Author Domain in the RFC5322 From: field.

That distinction is the key to reading email-authentication evidence correctly.

---

SPF: authorization of a sending host for a domain

Sender Policy Framework is defined by RFC 7208.

A domain publishes an SPF policy in DNS using a TXT record beginning with:

v=spf1

A receiver evaluates the connecting SMTP client's IP address against the policy for the SPF identity being checked.

In ordinary mail flows that identity commonly comes from the SMTP MAIL FROM domain. SPF also defines behavior around the SMTP HELO identity.

The important point is:

SPF does not directly authenticate the human-visible From: header.

That is one reason SPF alone is insufficient for protecting the domain users actually see.

A simple SPF record

Example:

v=spf1 ip4:192.0.2.0/24 include:_spf.example-provider.test -all

This policy contains several signals:

• an IPv4 network is directly authorized;
• another SPF policy is referenced through include;
• -all expresses a fail result for senders that do not match earlier mechanisms.

An analyst can learn something useful from this.

For example, an include may suggest use of a particular mail-delivery provider.

But phrase the conclusion carefully:

The domain's SPF policy delegates some sender authorization to provider X.

That is stronger than guessing from a random DNS record and weaker than claiming:

Provider X operates all email for the organization.

The SPF record describes authorization, not necessarily ownership or exclusive use.

Common SPF mechanisms

SPF supports mechanisms including:

• ip4
• ip6
• a
• mx
• include
• exists
• all

and also modifiers such as:

• redirect=
• exp=

Each mechanism has defined processing semantics.

For OSINT, the most immediately interpretable are usually:

ip4 and ip6

These explicitly authorize address ranges.

They can reveal infrastructure that a domain owner has chosen to authorize for sending.

Do not assume the address belongs to the organization itself.

It may belong to:

• a SaaS mail provider;
• a cloud platform;
• a marketing service;
• a transactional-email provider;
• a shared relay.

include

include:other.example

causes SPF processing to evaluate another domain's SPF policy as part of the current one.

An include is therefore evidence of a mail authorization relationship.

It is not proof of corporate ownership.

mx

An mx mechanism uses the domain's MX infrastructure during evaluation.

This can couple inbound and outbound infrastructure, but the presence of mx still does not prove that every MX server normally sends mail.

all

all matches every address.

Its qualifier determines the result.

Common forms include:

-all
~all
?all
+all

These broadly correspond to:

• fail;
• softfail;
• neutral;
• pass.

A record ending in:

+all

effectively authorizes any sending IP for that SPF identity and deserves close attention.

But even then, report what the policy does rather than inventing motive.

SPF has a DNS-processing limit

SPF is not an unlimited recursive graph.

RFC 7208 limits the number of terms that cause DNS queries during evaluation.

This matters operationally because deeply nested include, a, mx, ptr, exists, or redirect logic can produce a permanent error rather than a usable SPF result.

For an analyst, this means:

A record that looks syntactically rich is not necessarily operationally effective.

If you are assessing configuration quality, you must evaluate the policy as a resolver would, not merely count mechanisms.

Multiple SPF policies are not "more secure"

A domain should not publish multiple SPF policies for the same identity and expect them to be combined.

Finding more than one applicable v=spf1 policy is therefore a configuration problem, not evidence of stronger protection.

This is an example of an important OSINT rule:

More records do not necessarily mean more capability.

SPF and forwarding

SPF evaluates the SMTP client that delivers the message to the receiver.

That creates an architectural limitation.

A message can be legitimately forwarded by an intermediary whose IP address is not authorized by the original sender's SPF policy.

The content may be unchanged, but SPF can still fail because the final SMTP hop changed.

This is why an SPF failure does not automatically mean:

forged message.

It means the SPF authorization check did not produce a pass for the identity and path being evaluated.

Context matters.

---

DKIM: a cryptographic domain signature

DomainKeys Identified Mail is defined by RFC 6376 and updated by later specifications including RFC 8301 and RFC 8463.

DKIM works differently from SPF.

Instead of authorizing the connecting IP, a sender adds a DKIM-Signature header containing a cryptographic signature over selected message headers and body content.

A simplified signature might include:

DKIM-Signature:
  v=1;
  a=rsa-sha256;
  d=example.com;
  s=mail2026;
  ...

Two fields are particularly useful for analysis:

• d= — the DKIM signing domain;
• s= — the selector.

The receiver combines them to find the public key in DNS at a name conceptually shaped like:

mail2026._domainkey.example.com

What a DKIM pass means

When DKIM verifies successfully, the receiver has cryptographic evidence that:

• the message was signed using a private key corresponding to the published key for the signing domain;
• the signed headers and signed portion of the body survived in a form accepted by the specified canonicalization and signature rules.

This is meaningful evidence.

But avoid overclaiming.

A DKIM pass does not by itself prove:

• the person named in From: authored the message;
• the signing domain is the same as the visible author domain;
• the organization's account was not compromised;
• the message is benign;
• every header was protected by the signature;
• the entire body was necessarily covered if a body-length limit was used.

DKIM authenticates a domain-level signing relationship and message integrity within the scope of the signature.

It does not authenticate human intent.

The signing domain may be a provider

A company sending through a third-party service may produce a signature such as:

d=mailer.vendor.example

while the user-visible message says:

From: alerts@example.com

The DKIM signature can verify perfectly.

But the authenticated signing domain is still:

mailer.vendor.example.

Without DMARC alignment, you should not silently treat the DKIM result as authentication of example.com.

DKIM selectors are important OSINT clues

Selectors allow a signing domain to maintain multiple public keys.

They support:

• key rotation;
• separate mail systems;
• delegated services;
• administrative separation.

A selector can therefore reveal useful infrastructure patterns over time.

For example:

google
selector1
selector2
s1
s2
mail2025
mail2026

may suggest different providers or key-management practices.

But selector names are chosen by the domain owner.

They are not globally standardized.

RFC 6376 explicitly allows owners to use arbitrary selector namespaces and notes that some domains may avoid predictable selector names.

That creates an important limitation:

You generally cannot discover all DKIM keys for a domain from DNS alone.

The most reliable selector is often the one observed in an actual DKIM-Signature header.

Blindly guessing hundreds of selector names is neither necessary nor methodologically strong OSINT.

A DKIM record can outlive its significance

Historical or stale selectors can remain published after normal use has changed.

A public DKIM key therefore proves:

A key record is published at this selector now.

It does not necessarily prove:

This selector is currently used to sign production mail.

Observed messages provide stronger corroboration.

DKIM can survive some transformations, but not all

DKIM uses canonicalization rules to tolerate certain representation changes.

Even so, intermediaries can alter messages in ways that break signatures.

Mailing lists and forwarding systems may:

• modify subject lines;
• append footers;
• rewrite headers;
• transform message bodies.

A DKIM failure can therefore have multiple explanations.

Do not jump directly from:

DKIM failed

to:

the sender forged the message.

---

DMARC: alignment with the visible author domain

DMARC is the mechanism that connects SPF and DKIM authentication to the domain the recipient actually sees.

As of May 2026, the current core DMARC specification is RFC 9989, which obsoletes RFC 7489 and RFC 9091.

DMARC aggregate reporting is specified separately in RFC 9990, and failure reporting in RFC 9991.

This matters because many older guides still describe DMARC exclusively through RFC 7489.

For current analysis, RFC 9989 is the authoritative core reference.

The Author Domain

DMARC evaluates the domain in the RFC5322 From: field — called the Author Domain in the current specification.

Example:

From: Alice <alice@example.com>

The Author Domain is:

example.com

DMARC then asks whether SPF and/or DKIM produced authenticated identifiers that align with that domain.

DMARC pass requires authentication plus alignment

A DMARC pass is not simply:

SPF passed.

or:

DKIM passed.

At least one qualifying mechanism must both authenticate and align with the Author Domain.

Conceptually:

SPF pass + SPF alignment

or:

DKIM pass + DKIM alignment

is sufficient for DMARC to pass.

That makes DMARC much closer to the identity recipients see than SPF or DKIM considered alone.

SPF alignment

SPF alignment compares the relevant authenticated SPF domain with the Author Domain.

A third-party SPF pass can therefore be insufficient.

For example:

From: alice@example.com
Return-Path: bounce@vendor.example

SPF might pass for:

vendor.example

while DMARC SPF alignment fails because that domain does not align with:

example.com.

DKIM alignment

DKIM alignment compares the d= signing domain of a passing signature with the Author Domain.

Example:

From: alice@example.com
DKIM-Signature: ... d=example.com ...

can align.

But:

From: alice@example.com
DKIM-Signature: ... d=vendor.example ...

does not align with example.com merely because the signature verifies.

This is one of the most important distinctions in email-authentication analysis.

Relaxed and strict alignment

DMARC supports relaxed and strict alignment modes.

In simplified terms:

• strict alignment requires a closer domain match;
• relaxed alignment permits aligned organizational-domain relationships defined by the DMARC rules.

A published DMARC record may communicate alignment preferences using tags such as:

adkim=
aspf=

Do not infer that strict alignment is automatically "better" in every environment.

Alignment choices interact with real mail architecture and interoperability.

---

Reading a DMARC policy record

A DMARC policy is published in DNS beneath the _dmarc namespace.

For:

example.com

the obvious starting point is:

_dmarc.example.com

A simple record may resemble:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Important signals include the policy request and reporting destinations.

p=none

Monitoring mode.

The domain owner is requesting reporting and assessment without requesting quarantine or rejection based on DMARC failure.

What you can say:

The published policy requests monitoring behavior rather than quarantine or rejection for DMARC failures.

What you cannot say:

The organization does not care about spoofing.

A p=none policy can be intentional during deployment, monitoring, or because of interoperability constraints.

p=quarantine

The domain owner requests treatment associated with quarantine for messages that fail DMARC, subject to receiver policy.

This is stronger than monitoring in the sense that the published preference asks for enforcement-like handling.

But receivers still apply their own local handling decisions.

p=reject

The domain owner requests rejection treatment for messages that fail DMARC, again within the protocol's receiver-side processing model.

Do not use:

none < quarantine < reject

as a simplistic organizational maturity score.

The current RFC 9989 adds substantial interoperability guidance and explicitly cautions against assuming p=reject is always appropriate for general-purpose email domains.

Policy strength and operational correctness are not the same thing.

---

A 2026 DMARC detail: older pct guidance is stale

Older DMARC material frequently describes a tag such as:

pct=25

RFC 9989 removed the pct tag from the current specification after operational experience showed inconsistent application.

The current specification also moved and revised parts of the reporting model.

For an analyst, this is a useful freshness check:

If a guide treats RFC 7489 and pct as the current DMARC model, it is describing an older version of the protocol.

A domain can still contain legacy or unusual configuration, but current interpretation should start from RFC 9989.

---

DMARC reporting reveals operational intent, not necessarily operational use

A record may include reporting destinations.

Aggregate reporting now has its own specification, RFC 9990.

Failure reporting is described separately in RFC 9991.

A visible reporting address can suggest that the domain owner has configured a channel for authentication feedback.

It does not prove:

• reports are successfully delivered;
• the mailbox is monitored;
• reports are analyzed;
• remediation occurs;
• every sender has been inventoried.

Do not confuse configuration capability with operational process.

---

What SPF, DKIM and DMARC reveal together

When examined carefully, the three mechanisms can reveal a surprisingly useful picture of public mail architecture.

Sending providers

SPF include domains and authorized IP ranges can suggest:

• hosted mail platforms;
• marketing platforms;
• CRM systems;
• transactional-mail providers;
• helpdesk systems.

DKIM signing domains and selectors can provide additional corroboration.

A recurring pattern across both SPF and DKIM is stronger evidence than either alone.

Delegation patterns

An organization may use:

• its own visible author domain;
• a vendor's bounce domain;
• vendor-managed DKIM;
• custom DKIM aligned to the organization's domain.

Those patterns tell you about technical delegation.

Do not automatically turn them into corporate relationships beyond what the evidence supports.

Configuration changes over time

Historical DNS data may reveal:

• providers added or removed from SPF;
• changes from softfail to fail;
• DMARC monitoring introduced;
• reporting addresses changed;
• DKIM selectors rotated.

This can help build a timeline of mail-infrastructure changes.

But DNS history is an observation dataset.

A missing historical record does not prove a configuration did not exist.

Operational complexity

A long SPF graph, many providers, multiple DKIM signing domains and extensive DMARC reporting configuration may suggest a complex email environment.

It does not tell you whether that complexity is managed well.

---

What they do not reveal

This section matters as much as the records themselves.

They do not prove that a specific email is legitimate

A domain can be correctly authenticated and still send:

• malicious content;
• compromised-account mail;
• unwanted marketing;
• socially engineered messages.

Authentication is one signal.

They do not authenticate display names

An attacker can send mail displaying:

From: "Example Bank Security" <attacker@different-domain.test>

SPF, DKIM and DMARC can all pass for the attacker's own domain.

The display name can still be deceptive.

RFC 9989 explicitly discusses display-name attacks as outside the core protection offered by domain alignment.

They do not stop lookalike domains

DMARC on:

example.com

does not stop someone registering:

examp1e.com

or another visually similar domain.

Email authentication protects use of domains within its authentication model.

It does not solve brand impersonation across all other domains.

They do not prove mailbox ownership

A passing message from:

alice@example.com

does not cryptographically prove that Alice personally sent it.

The account may be:

• shared;
• delegated;
• automated;
• compromised.

They do not prove deliverability

Authentication is important to modern mail handling.

But inbox placement can also depend on:

• reputation;
• complaint rates;
• content;
• recipient engagement;
• provider policy;
• sending history;
• volume;
• list hygiene.

A perfect-looking DNS configuration is not proof of inbox placement.

They do not prove that every authorized service is still used

SPF includes and DKIM keys can remain after systems change.

Public DNS can lag organizational reality.

---

Reading a real received message

DNS tells you what a domain publishes.

A received message tells you what actually happened for one delivery.

For message-level analysis, useful fields include:

• From:
• Return-Path:
• DKIM-Signature:
• Authentication-Results:
• Received-SPF: where present;
• the Received: chain, interpreted carefully.

RFC 8601 defines the Authentication-Results header used by mail systems to communicate authentication outcomes.

A simplified example might look like:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce@example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

This is much stronger evidence for a particular delivered message than simply querying the domain's DNS records.

But there is an important trust-boundary rule:

Do not trust arbitrary Authentication-Results headers merely because they exist.

Authentication-result headers are meaningful when they were added by a mail system within a trust boundary you can identify.

Attackers can place fake headers into messages before delivery.

Interpret them in the context of the actual receiving path.

---

A practical OSINT workflow

Use the following sequence when investigating a domain's public email-authentication posture.

Step 1 — Query the base DNS records

Capture:

• MX;
• TXT records relevant to SPF;
• _dmarc TXT;
• timestamp;
• resolver or tool used.

Do not yet draw a maturity conclusion.

Step 2 — Parse SPF

Identify:

• directly authorized IP ranges;
• include relationships;
• a and mx mechanisms;
• redirect=;
• terminal all behavior;
• possible DNS-lookup complexity.

Turn these into hypotheses about sending infrastructure.

Step 3 — Parse DMARC

Record:

• policy;
• subdomain/non-existent-domain policy where present;
• SPF/DKIM alignment modes;
• reporting destinations;
• unusual or obsolete tags.

Remember that the current specification is RFC 9989.

Step 4 — Obtain DKIM evidence from observed mail when possible

If you have a legitimate received sample, inspect:

• d=;
• s=;
• signing algorithm;
• authentication result;
• whether the DKIM domain aligns with the Author Domain.

Then query the corresponding public key.

Do not assume a DNS selector guessed from convention is currently active.

Step 5 — Compare mechanisms

Ask:

• Does SPF authenticate an aligned domain?
• Does DKIM authenticate an aligned domain?
• Which mechanism appears to carry DMARC?
• Are vendor domains involved?
• Is the visible author domain protected by alignment?
• Is there evidence of a monitoring or enforcement policy?

Step 6 — Separate configuration from message evidence

Write two different findings:

Domain configuration

example.com publishes SPF and a DMARC monitoring policy.

Observed message

The sampled message passed DKIM with d=example.com and DMARC alignment at receiver X.

Do not merge these into one vague statement.

Step 7 — Add time

Email infrastructure changes.

Record when each DNS observation and message observation was made.

When history is available, compare changes carefully rather than assuming the current record describes the past.

---

Worked example

Suppose a domain publishes:

example.com TXT
v=spf1 include:_spf.workspace-provider.test include:mail.crm-provider.test -all

and:

_dmarc.example.com TXT
v=DMARC1; p=none; rua=mailto:dmarc@example.com

A received sample includes:

From: Support <support@example.com>
Return-Path: bounce@mail.crm-provider.test
DKIM-Signature: ... d=example.com; s=crm2026; ...

and the trusted receiver reports:

spf=pass
dkim=pass
dmarc=pass

Defensible observations

You can reasonably say:

1. The SPF policy delegates sender authorization to at least two external policy domains.
2. The sampled message used a CRM-related envelope sender.
3. The sampled message contained a valid DKIM signature for example.com.
4. DKIM alignment can support the DMARC pass for the visible Author Domain.
5. The domain currently publishes a DMARC monitoring policy and an aggregate-report destination.

Less defensible conclusions

Do not jump to:

The CRM provider operates all email for the company.

or:

Every message from example.com is genuine.

or:

The domain has weak email security because p=none.

or:

The DMARC reports are actively monitored.

The difference is evidence discipline.

---

Common mistakes

Mistake 1 — Saying SPF protects the visible From address by itself

SPF authenticates an SPF identity associated with the SMTP transaction.

DMARC alignment is what connects SPF to the Author Domain.

Mistake 2 — Treating a DKIM pass as proof of the human sender

DKIM authenticates a signing domain and protected message content, not human intent.

Mistake 3 — Treating every SPF include as ownership

An include is an authorization relationship.

It may represent a vendor.

Mistake 4 — Guessing DKIM selectors and calling absence proof

Selectors are owner-defined and may not be predictable.

An unresponsive guessed selector says little.

Mistake 5 — Treating p=reject as a universal gold standard

DMARC policy must be interpreted in operational context.

Current RFC 9989 contains explicit interoperability cautions.

Mistake 6 — Using RFC 7489 as though it were still the current core standard

RFC 9989 replaced it in May 2026.

Mistake 7 — Ignoring forwarding

SPF may fail after legitimate forwarding because the SMTP client changed.

Mistake 8 — Ignoring the receiver trust boundary

Authentication-Results headers are only meaningful when you know which receiving system produced the result.

Mistake 9 — Equating authentication with safety

A technically authenticated email can still be malicious.

---

A compact interpretation matrix

---

Related OSINT.dev tools

DNS / MX / SPF / DMARC Inspector

This is the primary OSINT.dev tool for the public DNS side of the workflow.

Use it to inspect:

• MX infrastructure;
• SPF policy;
• DMARC policy;
• related DNS records.

Its output describes public configuration.

It does not replace message-level authentication evidence.

SecurityTrails

Historical DNS observations can provide additional context when investigating changes in:

• MX infrastructure;
• SPF authorization;
• provider relationships;
• other DNS configuration.

Treat historical datasets according to their collection date and coverage.

A historical provider observation is a clue, not proof of a complete operational timeline.

---

The core principle

SPF, DKIM and DMARC are strongest when treated as three related but distinct evidence layers.

Think of them this way:

SPF: Was this SMTP client authorized for this SPF domain?

DKIM: Did this signed message verify under this signing domain?

DMARC: Does at least one authenticated domain align with the visible Author Domain, and what policy has that domain published?

That model prevents most interpretation errors.

Email authentication is valuable OSINT because it exposes real technical relationships through public protocols.

But its evidentiary value depends on precision.

Do not ask whether a domain has "good email security" from three green checks.

Ask what each mechanism proves, which identity it applies to, how the mechanisms align, and what alternative explanations remain.

---

References

Current and primary protocol references:

• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
  https://www.rfc-editor.org/rfc/rfc7208.html

• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
  https://www.rfc-editor.org/rfc/rfc6376.html

• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM
  https://www.rfc-editor.org/rfc/rfc8301.html

• RFC 8463 — A New Cryptographic Signature Method for DKIM
  https://www.rfc-editor.org/rfc/rfc8463.html

• RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
  https://www.rfc-editor.org/rfc/rfc9989.html

• RFC 9990 — DMARC Aggregate Reporting
  https://www.rfc-editor.org/rfc/rfc9990.html

• RFC 9991 — DMARC Failure Reporting
  https://www.rfc-editor.org/rfc/rfc9991.html

• RFC 8601 — Message Header Field for Indicating Message Authentication Status
  https://www.rfc-editor.org/rfc/rfc8601.html