What an SPF and DMARC presence check can—and cannot—tell you

This article was written with assistance from an AI writing program and reviewed against the behavior and boundaries of the linked checker.

It is easy to turn a DNS lookup into a claim that is much bigger than the evidence. Finding an SPF record does not prove that every legitimate sender is authorized. Finding DMARC does not prove that the policy is enforced. And finding both certainly does not guarantee inbox placement.

A presence check is still useful—as long as we keep the claim small.

The two lookups

SPF is normally published as a TXT record on the domain:

nslookup -type=TXT example.com

You are looking for a value beginning with v=spf1.

DMARC is published at a specific subdomain:

nslookup -type=TXT _dmarc.example.com

You are looking for a value beginning with v=DMARC1.

Those two lookups answer only one question: is a matching public record visible?

What SPF presence does not prove

An SPF record can exist and still have problems:

• a real sending service may be missing;
• the record may contain invalid syntax;
• too many nested lookups may cause a permanent error;
• overlapping records may create an invalid SPF configuration;
• the visible From domain may not align with the authenticated envelope domain.

That is why “SPF found” is a baseline, not a pass certificate.

What DMARC presence does not prove

A DMARC record can use p=none, which requests monitoring rather than enforcement. That can be exactly right during a rollout, but it should not be described as full spoofing protection.

A fuller review should examine:

• the policy (none, quarantine, or reject);
• SPF and DKIM alignment;
• percentage-based rollout settings;
• reporting destinations;
• subdomain policy;
• whether every legitimate mail stream authenticates successfully.

Why DKIM is not a single domain-wide yes/no lookup

DKIM records live under selectors chosen by each sending system, such as:

selector1._domainkey.example.com

There is no universal selector that a basic checker can query for every domain. A real DKIM review starts with the systems sending the messages or with message headers, then checks the corresponding selector records.

A safer interpretation

I use three plain-language outcomes:

1. Both found: a healthy starting point, with alignment and policy still unverified.
2. One missing: a visible gap that needs sender inventory before a DNS change.
3. Neither found: worth reviewing soon, but still not a reason to paste a generic record into production.

That last boundary matters. A rushed DNS edit can interrupt legitimate mail. Before changing SPF or DMARC, identify the services that send on the domain’s behalf and use a staged rollout.

Try the narrow check

I built a small, no-signup checker around this deliberately limited promise. It reads public DNS, reports whether SPF and DMARC are present, and states what it does not verify.

Run the free SPF and DMARC presence check

The useful question is not “did the tool produce a green result?” It is “what does this result actually justify us saying?”