Skip to main content
Analyse

Free tool

What receiving mail servers see when you send

SPF, DKIM and DMARC are the three public records that decide whether your email is trusted, quarantined or silently discarded — and whether anyone else can send as you.

Why this matters commercially

Incomplete authentication has two costs. Legitimate messages — invoices, quotations, password resets — are more likely to be filtered. And an unprotected domain can be used by anyone to send email that appears to come from you, which is the mechanism behind most invoice fraud.

Enter a domain name. Only public DNS records are read.

The three records

What each one is actually for

They are frequently discussed as one thing. They answer three different questions, and they only work together.

SPF

Which servers may send

A published list of the servers permitted to send email using your domain. A receiving server checks the connecting address against it. Its weakness is that it breaks when messages are forwarded, which is one reason it is not sufficient alone.

DKIM

That the message is intact

A cryptographic signature added on sending and verified against a public key in your DNS. It survives forwarding, and it proves the message has not been altered in transit — which SPF cannot do.

DMARC

What to do about failures

The policy that ties the other two together. It states whether failing messages should be delivered, quarantined or rejected, and where to send reports. Without it, each receiver decides for itself.

Coverage

What this check reads

Public DNS records only. Nothing is sent, no mail server is connected to, and no message is generated.

SPF

  • Whether a record is published
  • How many records exist, since more than one is always an error
  • The policy applied to unlisted senders
  • First-level DNS-querying mechanisms against the limit of ten

DMARC

  • Whether a record is published
  • The policy: monitoring, quarantine or reject
  • Whether a reporting address is declared
  • The subdomain policy where one is stated

Supporting

  • DKIM selectors matching a list of common provider defaults
  • MTA-STS policy declaration
  • BIMI record presence

Example finding

How this appears in a report

The same information, placed in commercial context and prioritised against everything else found.

This is an illustration of the report format rather than a result from a real assessment.

High

DMARC Protection Appears Incomplete

What we found
A DMARC record is published with a policy of none and no reporting address. SPF is present and correctly formed. No DKIM selector matching a common provider default was found, which does not confirm its absence.
Why it matters
A policy of none instructs receiving servers to take no action on messages that fail authentication, so the domain has monitoring in name but no protection in practice. Anyone can send email appearing to come from this domain and expect it to be delivered. With no reporting address published, there is also no visibility of who is currently doing so.
General direction
Establish a reporting address first and use the resulting data to identify every legitimate service sending on the domain's behalf. Only once that list is complete and aligned should the policy move towards enforcement. Attempting the sequence in the other order is the usual cause of legitimate mail being rejected.
How IXSEO can help
Email Deliverability Review, with specialist input from Elite Security Europe.

Limits

What a DNS check cannot tell you

It reads what is published. It cannot see what actually sends. An SPF record can be immaculately formed and still omit the marketing platform your team started using last quarter, which will not become apparent until the policy is enforced and those messages start failing.

It also cannot assess reputation. Authentication decides whether a message is trusted to be from you; reputation decides whether being from you is a good thing. A domain with perfect records and a history of complaints will still be filtered, and no DNS record will change that.

The genuinely useful version of this work starts with DMARC reports. Those reveal every source sending on the domain — including the ones nobody remembered — and turn a guess into an inventory. That is the point at which enforcement becomes safe rather than hopeful.

Enforcing a policy before you know what sends on your behalf does not protect the domain. It just moves the failure to your own invoices.

Infrastructure expertise from Elite Security Europe

Common questions

Why does this not tell me what record to publish?
Because publishing a record supplied by a tool that has never seen your sending infrastructure is how legitimate email starts being rejected. An SPF record that omits a service you use — a payroll provider, a booking system, a CRM — will cause those messages to fail authentication the moment DMARC is enforced. The records are interdependent and specific to your setup, which is why the detailed configuration belongs in a reviewed engagement rather than in a public tool.
No DKIM selectors were found. Is DKIM missing?
Not necessarily, and this is worth understanding properly. DKIM selectors cannot be enumerated from DNS — you can only look up a selector you already know the name of. This check tries a list of selectors commonly used by major providers. A match confirms DKIM is present; no match confirms nothing at all, because a custom selector name is perfectly normal and undiscoverable.
Our DMARC policy is 'none'. Is that wrong?
It is the correct place to start and the wrong place to stop. A policy of none means failing messages are still delivered, so the domain gains monitoring but no protection. The purpose of that stage is to collect reports, find every legitimate service sending on your behalf, and bring them into alignment. Moving to quarantine or reject before that work is done is what causes the horror stories. Sitting at none indefinitely is the more common failure, and leaves the domain freely usable by anyone.
What is the SPF lookup limit?
SPF permits at most ten DNS-querying mechanisms when a record is fully expanded, including everything pulled in by nested includes. Exceed it and the record returns a permanent error, which most receiving servers treat as an authentication failure. It is a common problem for organisations using several cloud services, and it produces intermittent, hard-to-diagnose delivery issues because the failure depends on how far a given receiver expands the record.
Does this check whether our email is actually being delivered?
No. It reads the published records only. Deliverability also depends on sending reputation, list quality, content, complaint rates and the reputation of the addresses you send from — none of which is visible in DNS. Good authentication is a precondition for good deliverability, not a substitute for it.

Infrastructure expertise from Elite Security Europe

Elite Security Europe contributes specialist review of email authentication, DNS configuration, infrastructure posture and passive security exposure.

Related

IntelligenceEmail DeliverabilityThe full module: how authentication posture is assessed and what a review covers.IntelligenceDNS & InfrastructureNameservers, certificate governance and the wider public configuration of a domain.EcosystemElite Security EuropeWhere the infrastructure and deliverability expertise behind this work comes from.

Moving to enforcement safely

A deliverability review establishes what actually sends on your domain, brings those services into alignment, and sequences the policy change so nothing legitimate is lost.

Request a reviewRun the full snapshot

Public reports describe the position rather than prescribing exact record values. Configuration is agreed against your actual sending infrastructure.