Skip to main content
Analyse

Intelligence module

Whether receiving mail servers have any reason to trust your email

Three public records determine how your messages are treated before a human ever sees them. Most organisations have never checked whether theirs are complete, and find out when a customer says the quote never arrived.

Check your domainRun the full analysis

Infrastructure expertise from Elite Security Europe.

When your server sends a message, the receiving server has to decide within milliseconds whether it is genuinely from you. It has no relationship with you and no way to ask. What it has is a set of public records your domain publishes, and it forms its judgement almost entirely from those.

Three records matter. SPF states which servers may send on your behalf. DKIM provides a cryptographic signature proving a message was not altered. DMARC ties the two together and tells receiving servers what to do when a message fails.

Incomplete configurations rarely fail loudly. Messages are delivered, mostly, and the ones diverted to spam produce no notification. The cost accumulates quietly as quotes that were never read and notifications that never arrived.

Checks

What is examined

All of it read from public DNS. These are the same lookups any receiving mail server performs, made against records your domain already publishes.

  1. Mail routing

    Whether MX records exist, where mail is directed, and whether the routing is consistent with how the organisation appears to operate. A domain with no mail routing but an address published on the contact page is a discrepancy worth knowing about.

  2. SPF

    Whether a policy exists, whether more than one is published — which invalidates both — how strict the failure directive is, and whether the number of lookups it requires approaches the limit beyond which receiving servers stop evaluating.

  3. DKIM

    Whether signing keys can be found at selectors used by common providers. Selectors are chosen by the sender and are not enumerable, so a negative result is reported as undetermined rather than as absent.

  4. DMARC

    Whether a policy exists, what it instructs receiving servers to do with failures, whether reporting addresses are configured, and whether the policy is set to monitor only — which is a sensible starting point and a poor permanent state.

  5. Supporting records

    CAA records governing which authorities may issue certificates, MTA-STS and TLS reporting where published, and BIMI readiness. These are refinements rather than fundamentals and are reported as such.

  6. Consistency

    Whether the records agree with each other and with the observable mail infrastructure. A domain permitting a provider it no longer uses, while omitting one it does, is a common and consequential state.

Email authentication rarely fails loudly. It fails as a quote that was never read and a follow-up that never came.

Interpretation

What the score reflects

Reflects whether the domain publishes the public authentication records that receiving mail servers use to decide whether to trust its email.

It is a measure of configuration completeness rather than of delivery performance. Whether your email actually reaches inboxes also depends on sending reputation, content, recipient engagement and list quality, none of which are visible from public DNS.

What a good score establishes is that the foundations are in place. What a poor one establishes is that there is a preventable problem sitting underneath whatever else is happening to your email.

Commonly surfaced

  • DMARC published in monitor-only mode for years
  • Two SPF records, which invalidates both
  • An SPF policy close to or beyond the lookup limit
  • SPF permitting a provider no longer in use
  • No DMARC reporting address, so failures go unseen
  • A soft-fail directive where a hard fail was intended
  • No policy at all on a domain that sends invoices
  • A parked domain with no protective policy

Example finding

A representative finding

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

High

DMARC Protection Appears Incomplete

What we found
Your domain's email authentication appears incomplete. A DMARC record is published but instructs receiving servers to take no action on messages that fail, and no reporting address is configured.
Why it matters
Some legitimate emails may be rejected or delivered to spam, and messages sent by others claiming to be from your domain will be treated no differently from your own. Without a reporting address, neither situation produces any evidence you could act on.
General direction
Review your SPF, DKIM and DMARC configuration together before making changes. Establish what genuinely sends on your behalf first, add reporting so the effect of any change is visible, and only then tighten the policy.
How IXSEO can help
Email Deliverability Review

Why the public report stops short of exact records

This is a deliberate restraint rather than a commercial one.

A DMARC policy set to reject, published before establishing what sends on your behalf, will cause legitimate email to be discarded silently. Your invoicing platform, your CRM, your booking system and your accountant’s forwarding rule may all be sending as your domain, and none of them are visible in public DNS.

So the public report tells you what appears incomplete and what the consequence is. It does not print a record to paste into your DNS panel, because a service that did so without knowing your sending infrastructure would be handing you a plausible way to stop your own email.

Infrastructure expertise from Elite Security Europe

Frequently asked questions

Why does a search intelligence service check email?
Because organisations lose revenue to email deliverability far more often than they realise, and nobody is checking. The records involved live in the same public DNS we already query, so the check costs nothing extra. If your quotes are landing in spam folders, that is a more urgent commercial problem than a ranking position, and you would want to know.
Why will you not tell me the exact record to publish?
Because a DMARC record published without understanding what already sends on your behalf is one of the more reliable ways to stop legitimate email being delivered. The correct value depends on your sending infrastructure, which a public check cannot see. We identify what appears incomplete; getting it right requires knowing what your organisation actually sends.
How do you check DKIM if selectors are not published?
Only partially, and we say so. DKIM keys are published at selector names chosen by the sender, and there is no public directory of them. We test a set of selectors used by common providers. A negative result means we did not find one at those names, not that DKIM is absent, and the finding is worded accordingly.
We do not send marketing email. Does this still apply?
Yes, and arguably more. The records govern whether anyone can send email claiming to be from your domain — invoices, quotes, password resets, or an impersonation attempt against your customers. A domain that sends no email at all still benefits from a policy stating that nothing legitimate originates from it.
Can you fix this for us?
Through an email deliverability review, which involves establishing what actually sends on your behalf, correcting the records in the right order, and monitoring the reports before tightening the policy. That is a specialist engagement supported by Elite Security Europe rather than something to change on a Friday afternoon.

Related

ToolEmail Authentication CheckerA free public check of SPF, DMARC and mail routing.ModuleDNS & InfrastructureThe wider configuration these records sit within.EcosystemElite Security EuropeThe specialist expertise supporting this area of the assessment.

Check what your domain is publishing

Email Health is an optional module on the free snapshot, and the standalone checker covers the same public records in a few seconds.

Check your domainDiscuss a deliverability review