Module · Enterprise

Domain security,
the boring stuff attackers exploit first.

Email authentication, DNS posture and certificate hygiene: the fundamentals every security questionnaire asks about, checked continuously rather than once a year. SPF, DKIM, DMARC, TLS-RPT, MTA-STS and certificate expiry across every domain you own.

Email spoofability is a deterministic finding, the same inputs always produce the same answer.

At a glance

Domain Security at a glance

Coverage

What we observe

SPF, DKIM and DMARC policy, DNSSEC, certificate expiry and chain problems, subdomain takeover candidates.

Scoring

How it's scored

Each observation maps to a published, versioned rubric. A DMARC policy left at p=none is scored the same way for every company.

Action

What happens next

Most domain findings are one-line DNS changes. Fix it, and the next scan clears the finding automatically.

What we observe

  • SPF, DKIM and DMARC policy and enforcement level
  • MTA-STS and TLS-RPT presence and validity
  • MX records and mail-provider fingerprinting
  • DNS hygiene across every domain you own
  • Certificate expiry and chain problems

What arrives on a finding

  • A deterministic answer on whether the domain can be spoofed
  • The published record that produced the finding
  • The exact record change required to fix it
  • The compliance control the gap breaks
  • Automatic clearance on the next scan once fixed
Worked example

Anatomy of a finding

FindingDMARC policy published but left at p=none
EvidenceThe published DMARC record, quoted in full
Why it mattersA monitoring-only policy instructs receivers to do nothing, so mail can still be spoofed as your domain
Who it affectsAnyone who receives mail appearing to come from you, customers, staff, suppliers
RemediationMove to quarantine, then reject, once reporting confirms legitimate senders align
Domain security dashboard showing DNS and DMARC enforcement status

Continuous observation of SPF, DKIM, DMARC and certificate hygiene

Why it is weighted heavily

Domain and mail configuration is the most checkable control there is

Most security controls are hard to verify from outside. Domain and mail configuration is the exception: the records are published deliberately, they are unambiguous, and either the domain can be spoofed or it cannot. There is no judgement involved and no room for a generous interpretation.

That makes it unusually valuable as a signal. A company with a DMARC policy left at monitoring-only has published, in DNS, that anybody can send mail as them. It is not an inference from an aggregate score: it is a fact, quoted from their own record, that anyone can check.

It is also the control most often left unfinished. The records exist, which means questionnaires get ticked, while the policy that would actually block anything was never enabled. Passing an audit and being spoofable are entirely compatible states.

What is assessed

Five records, plus the domains you forgot you own

SPF is checked for existence, for permissiveness, and for whether it exceeds the DNS lookup limit: a record that has accumulated third parties over the years can silently stop being evaluated at all, which fails open rather than closed.

DKIM is checked for valid published keys, and DMARC for its enforcement level: none, quarantine or reject. The distinction between a published DMARC record and an enforcing one is where most of the real risk sits, and it is the distinction most commonly missed by anybody scoring from a checklist.

MTA-STS and TLS-RPT cover transport security between mail servers and reporting on failures. Beyond mail, the module checks DNS hygiene across every domain attributed to the organisation: including the ones acquired, rebranded away from, or registered defensively and never configured. Those forgotten domains are frequently the weakest, because nobody has looked at them since registration.

Remediation

Usually one DNS change, and the finding clears itself

Most domain findings resolve with a single record change. The module states the exact record required rather than describing the general principle, which is the difference between a finding that gets fixed this week and one that gets discussed for a quarter.

The exception is moving DMARC to enforcement, and it is worth being honest about why. Enforcement breaks any undocumented system sending as the domain: a CRM, an invoicing platform, a marketing tool nobody told IT about. The sequence is to publish at none with reporting, identify every legitimate sender from the reports, then move to quarantine and then reject. Weeks, not months, and the constraint is ownership rather than difficulty.

Findings clear automatically on the next scan once the record is correct. Nothing has to be marked resolved by hand, which matters because manually cleared findings are how a findings list stops reflecting reality.

Questions

Common questions

Why is email authentication weighted so heavily?

Because it is unambiguous and it is the control most often left unfinished. The records exist, so questionnaires pass, while the domain remains spoofable.

We have a DMARC record. Does that mean we are protected?

Only if the policy is quarantine or reject. A record published at p=none instructs receiving servers to do nothing, so mail can still be spoofed. This is the single most common misunderstanding in this area.

Will fixing it clear the finding automatically?

Yes. Most domain findings are a single DNS change, and the next scan clears the finding without anyone marking it resolved by hand.

What is an SPF lookup limit failure?

SPF permits a limited number of DNS lookups. A record that has accumulated third-party senders over the years can exceed it, at which point evaluation fails and the record stops protecting anything, silently, and in the fail-open direction.

Do you check domains we no longer use?

Yes, if they are attributable to the organisation. Defensively registered, rebranded-away-from and acquired domains are routinely the weakest, because nobody has looked at them since registration.

Does good DMARC stop lookalike domains?

No. A domain with a substituted character is a different domain and can publish its own perfect records. Mail authentication and impersonation monitoring cover different halves of the problem.

Related

Where this connects

Email security and DMARC →

The full walkthrough: what each record does and how to reach enforcement.

Domain takedown →

Lookalike domains that sidestep authentication entirely.

How scoring works →

How domain findings are weighted into the overall rating.

Rate your own domain security first

See what attackers and insurers see. Free for your own organisation.