GuideBy the PhishSheriff team · November 2024 · 9 min read

Email Domain Trust: Common Gaps and How to Prioritise Them

The configuration gaps that most often weaken trust in an organisation’s email domains, from SPF errors and subdomain exposure to lookalike domains, and a practical order in which to fix them.

Key points

What a domain trust assessment should look at
The SPF errors that appear again and again
How lookalike domains are prepared and when to act
Why p=reject on the main domain is not the end of the work

On this page

What to look at

A useful assessment of email-domain trust looks at what DNS and mail flow actually do, not at policy documents. Four areas matter: authentication posture (SPF validity, DKIM coverage, DMARC policy and alignment), DNS hygiene (record drift, expiring assets, dangling references and subdomain-takeover conditions), the health of the sending estate (how much real mail is authenticated) and threat pressure (spoofing attempts and lookalike-domain activity).

PhishSheriff’s Domain Trust Score organises these areas into one starting point for investigation. Like any score, it is most useful when you can see the factors behind it; it is not a certification that a domain is safe.

Size of the sending estate

The more services an organisation sends email from, the more likely it is that at least one legitimate source is unauthenticated. Large organisations can have dozens of sending platforms across marketing, HR, finance and support.

The deciding factor is rarely the sector. It is whether someone owns email authentication as an ongoing operational task rather than a one-time project.

SPF: the same errors everywhere

SPF problems tend to come from a handful of repeatable errors. The most consequential is exceeding the 10-DNS-lookup limit: nested vendor includes push the record over the limit and produce permerror results, which receivers handle inconsistently and owners often do not notice because most mail still arrives. Others include multiple SPF records on one domain (which invalidates them), +all or ?all terminators that authorise far too much, authorising shared vendor IP ranges that other tenants can use, and mechanisms pointing at infrastructure that no longer exists.

Most SPF errors are drift rather than design. Records that were correct when written decay as vendors change infrastructure, contracts end and platforms move, and nothing in a default email setup alerts anyone. Monitoring lookup counts, changes to included records and mechanisms that no longer match observed sending catches these problems early.

Lookalike domains

Lookalike domains use character substitution, hyphenation (“yourbank-secure”) and alternative top-level domains. Registrations often cluster around public events such as product launches, results announcements and acquisitions, when a themed message feels plausible.

There is often a gap between a lookalike’s registration and its first use, which shows up when mail records and authentication are configured on it. Monitoring new registrations gives defenders a chance to block the domain, warn staff and request a takedown before it is used. Discovering it only after a customer or employee reports the campaign leaves no such window.

Subdomains: enforcement is not finished at p=reject

Reaching p=reject on the organisational domain is a milestone, not the end. Subdomains can remain exposed through a weaker subdomain policy, forgotten sending subdomains without their own record, or dangling DNS on decommissioned subdomains that creates takeover conditions inside the trusted parent brand.

Subdomain spoofing works because people extend the parent brand’s trust to anything beneath it. Close the gap by treating subdomains as inventory: discover every subdomain with DNS records, apply explicit policy to everything that sends, use sp=reject (and np=reject under DMARCbis) as a backstop, and watch for takeover conditions.

A practical order of work

Order the work so that each step makes the next one safer. First, fix broken authentication: SPF permerrors and missing DKIM on high-volume senders are usually quick to correct. Second, move DMARC towards enforcement using the discovery-and-ramp approach in our DMARC playbook. Third, close subdomain gaps. Fourth, monitor lookalike domains so that impersonation is caught between registration and use.

Once the basics are in place, shift from projects to operations: watch the DMARC failure stream (after enforcement, much of it is impersonation), alert on DNS drift, and monitor for impersonation of the executives most often named in fraud attempts. Email trust is an operational property, not a project milestone.