[ Spoofing & identity abuse ]

Reputation hijacking and legitimate-domain abuse

Assess how legitimate infrastructure can lend authentication credibility without proving business authorization.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Assess how legitimate infrastructure can lend authentication credibility without proving business authorization.
  • Match authorized networks and tenant identity controls to actual sender ownership.
On this page
  1. Define the authority being reused
  2. Build a precise threat model
  3. Compare three written authorization cases
  4. Fix the accountable boundary

A reputable domain or shared sending service can become part of an abusive message path. The useful question is not whether the infrastructure is generally trustworthy. It is whether this particular message was authorized to use the authenticated identity. Authentication and business authorization answer different questions.

Define the authority being reused

A compromised mailbox may send through its ordinary authenticated route. An overly broad network authorization can admit an unintended source. A relay may sign a message after accepting it under an insufficiently specific admission rule. These mechanisms have different owners and remedies. Do not collapse them into one unexplained claim of reputation hijacking.

The original BreakSPF research examines permissive SPF configurations and shared infrastructure. Its threat model makes source-network access a central condition. That is a deployment boundary, not evidence that an attacker can forge any DKIM signature. BreakSPF paper, Section III. Treat the paper's measurements as historical research, not a present inventory of vulnerable services.

Build a precise threat model

Write the protected domain, authenticated identifier, allowed source set, attacker capability and receiver decision separately. In the bounded scenario here, brand.test authorizes 192.0.2.0/24 for SPF. The approved application uses 192.0.2.10, while a hypothetical unintended tenant can originate from 192.0.2.99. Both addresses lie in the published range. Whether such tenant access exists in a real service requires separate evidence.

SPF checks source authorization for its evaluated identity. It does not identify the human behind a shared IP. If the passing SPF identity also aligns with the author domain, that path can satisfy DMARC without DKIM. RFC 7208 and RFC 9989. Successful evaluation can therefore reveal that too much authority was granted, rather than a receiver ignoring the pass rule.

Compare three written authorization cases

Assume visible From alerts@brand.test, nonempty MAIL FROM bounce@brand.test, no DKIM signature, and an otherwise eligible DMARC evaluation. Compare hypothetical SPF records v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.

  • Approved source 192.0.2.10: included by both network prefixes; SPF passes and aligns with brand.test, so the illustrative message passes DMARC in either case.
  • Unintended source 192.0.2.99: included by the /24 but not the /32; SPF passes only under the broad record. With no DKIM signature, the stipulated DMARC result is pass under /24 and fail under /32.
  • Outside source 198.51.100.10: included by neither prefix; -all yields SPF fail in either case. With no DKIM signature, the stipulated DMARC result is fail in both.

These are written prefix-membership and alignment deductions, not a running SPF parser, DNS observation or reproduction of BreakSPF. Source control is assumed, not demonstrated. No external message or live service was tested. The paper’s cross-protocol technique is outside this teaching example.

A single passing aligned mechanism can satisfy a message’s DMARC pass condition. That does not make SPF-only deployment adequate: RFC9989 section7.4 requires valid DKIM for domains publishing p=reject, and section8 addresses full participation. These are separate deployment duties, not an extra per-message pass gate.

Fix the accountable boundary

Before narrowing a real SPF record, inventory every legitimate sender and follow provider-supported configuration. A dedicated source is useful only if it is actually exclusive and maintained. Confirm that the sending service binds customers to their permitted identities; verify DKIM configuration and remove obsolete authority through change control.

Monitor route-specific failures after the change, preserve a recovery plan and document unknown senders. Do not replace a broad record with a guessed IP list from this example. The lesson is to reconcile authorization with actual service ownership, not to copy demonstration DNS into production.

[ Takeaway ]

Match authorized networks and tenant identity controls to actual sender ownership.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Bound the allowed source

Network entries and tenant identity restrictions must match the intended sender.

Next steps

  1. Inventory approved routes.
  2. Test supported changes before enforcement.
  3. Confirm whether source capacity is exclusive.

CISO / SecOps

Distinguish model from exposure

The written cases illustrate a condition, not your organization’s exposure.

Next steps

  1. Require evidence of source control.
  2. Track residual shared-service risk.
  3. Distinguish historical research from current exposure.

Founder / Non-technical

Ask which authority was reused

A legitimate service name is not enough to approve a transaction.

Next steps

  1. Assign a service owner.
  2. Keep sensitive business verification separate.
  3. Review retired service authority.

[ FAQs ]

Frequently asked questions

Does reputation hijacking always mean account compromise?

No. Shared infrastructure or an overbroad authorization can create a different path.

Can shared IP ownership identify the customer?

No. Establish the service and tenant context rather than treating an IP as a person.

Does the example break DKIM?

No DKIM forgery is attempted. The example concerns SPF network authorization and a passing aligned path.

Why can DMARC pass with no DKIM pass?

A passing aligned SPF path can satisfy the pass condition.

Does the /32 example prove a production fix?

No. It demonstrates a narrower input set. A real change needs provider-supported sender inventory and testing.

Was BreakSPF reproduced here?

No. The written cases illustrate network authorization with stipulated source control; no exploit, parser or receiver was executed.

Can I use the demonstration addresses in DNS?

No. They are reserved documentation addresses and not your service configuration.

What should be investigated first?

The actual authority granted, the identities accepted by the sender and the trusted receiver evidence.

[ Sources ]

Sources

  1. BreakSPF original research NDSS

    Sections III.A Attack model · Figure 3 · VIII Discussion

  2. RFC 7208 SPF

    Sections §2.4 · §5.6

  3. RFC 9989 DMARC

    Sections §4.4 · §5.3.5 · §5.4 · §7.4 · §8

[ Glossary ]

Glossary

Shared infrastructure
A service or network resource used by multiple customers.
Authorization boundary
The rule separating permitted use of an identity from other use.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base