Do not let your domain lend its name to fraud

A standing control, not a new alert

This is evergreen guidance, not news of a new incident. Criminals can put a familiar-looking address in an email's visible From field. That does not mean they control the organisation's mailbox or domain, but it can lend credibility to an invoice scam, credential theft or another attempt to deceive a recipient.

The NCSC recommends three related controls. Sender Policy Framework, or SPF, publishes which systems may send for a domain. DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to sent mail. Domain-based Message Authentication, Reporting and Conformance, or DMARC, lets a domain owner state how receivers should treat messages that do not pass aligned SPF or DKIM checks, and request reports about mail claiming to use the domain.

Alignment is the important bit

A message can pass an SPF or DKIM check without satisfying DMARC. DMARC compares an authenticated domain with the domain visible to the recipient in the From field. At least one supported authentication result must pass and align with that visible domain. This relationship is what makes the policy useful against direct spoofing of the organisation's identity.

The policy can ask receivers to take no particular action, place failing mail in quarantine or reject it. RFC 7489 describes DMARC as a policy and reporting mechanism, not a guarantee of delivery or proof that a message is trustworthy. It also documents interoperability limits, particularly for legitimate mail that is forwarded or modified by an intermediary. Display-name impersonation and deceptive lookalike domains remain outside the protection offered by a policy on your own domain.

That is why enforcement should follow discovery. A business may send through its main mail platform, website forms, invoicing software, recruitment systems, support desks and marketing suppliers. Moving straight to rejection before identifying those senders can block genuine messages. Remaining indefinitely at a monitoring-only policy, however, asks for reports without asking receivers to contain failures.

What businesses should do

Start with the domain portfolio, not just the main mailbox. The NCSC says organisations should protect all their domains, including those using common cloud mail providers. Record which domains send mail, which should never send it, who owns each registration and DNS zone, and every internal or supplier service authorised to send. Remove obsolete routes rather than preserving them in policy by habit.

Configure SPF and DKIM with the relevant mail providers, then publish DMARC initially at a level that allows evidence to be gathered safely. Send aggregate reports to a monitored service or mailbox and review which systems pass, fail and align. Reports can expose forgotten legitimate senders as well as unauthorised use, but they contain operational data and need controlled access, retention and ownership.

Correct legitimate failures with the service owner. Test ordinary mail, automated messages and supplier routes before increasing enforcement. Move in measured stages towards quarantine or rejection, watching delivery and reports after each change. Treat DNS edits as production changes: peer-review them, record the reason, and keep a recovery route if a provider configuration proves wrong.

For domains that should not send mail, publish an appropriately restrictive position rather than leaving their intent ambiguous. Continue filtering inbound mail and training staff to verify unusual requests through a separate channel. Anti-spoofing reduces one useful route for fraud; it does not detect every malicious message or prevent an attacker using a compromised account or a similar-looking domain.

• Inventory every domain and legitimate sending service.
• Configure SPF and DKIM so authentication aligns with the visible From domain.
• Collect and review DMARC aggregate reports under a named owner.
• Test genuine mail flows before tightening the enforcement policy.
• Keep inbound filtering and independent verification for sensitive requests.

The Beekeeper view

DMARC is most useful as an ownership exercise. It forces a business to discover who is allowed to speak in its name, then gives receiving systems a published basis for handling mail that falls outside that decision.

A monitoring record that nobody reads is telemetry without a control. A rejection policy deployed without understanding genuine senders is an outage with good intentions. Inventory first, watch the evidence, fix alignment and enforce in steps.