A Domain Is a Promise: Auditing SPF, DKIM and DMARC Before Enforcement

An invoice arrives with familiar branding, a plausible reference and bank details that have changed since last month. The display name is your finance director's. The sending domain is your own. Exact-domain spoofing is not the only route into invoice fraud, but it is the one that most directly exploits the trust customers and suppliers place in your name. DMARC — Domain-based Message Authentication, Reporting and Conformance — is the DNS-based policy that tells receiving mail systems what to do when a message claims to come from your domain without proof.

The difficulty is that DMARC is often switched on in name only. A record that publishes p=none is a monitoring instruction, not a control. Before an organisation moves to quarantine or reject, it needs to know which systems legitimately send mail as its domain, which of those will fail authentication, and how it will prove that a spoofed message is actually refused. That work is unglamorous, but it is the difference between a policy on paper and a policy that protects an invoice run.

Begin with the records, not the dashboard

Start at the public DNS. For every domain the organisation owns, check the TXT record at _dmarc, the SPF record at the apex, and the DKIM selectors used by each sending platform. A domain with no DMARC record is not neutral; it is an invitation. A domain with a record but no reporting address is a policy nobody is reading.

Several details matter more than the headline policy. There should be one SPF record, not several, and it should stay within the ten-DNS-lookup limit that most receivers enforce. Look for -all rather than ~all if the sender list is complete, but do not change it until the list is. Check whether the DMARC record sets a subdomain policy with sp= and whether enforcement is partial through pct=. Check that the reporting mailbox named in rua= exists and is monitored. Check whether DKIM keys are present, current and associated with the domains that actually appear in the From header.

The same review should cover domains that are parked, held defensively or used only for a campaign. These are frequently overlooked because nobody sends routine mail from them, yet they can carry the organisation's name in a fraudulent message.

List the systems that send as you

Enforcement breaks at the edges. A payroll platform, an accounting system, a CRM, a website contact form, a ticketing tool, an e-signature service, a mailing list or a networked scanner may all send mail with your domain in the From header. Some will use their own domain and need no change. Others will use yours and will fail DMARC alignment unless their SPF and DKIM configuration is correct.

Ask each supplier for its sending domains and DKIM instructions in writing. Then inspect the headers of real messages from each system. An Authentication-Results line will show whether SPF and DKIM passed and whether either aligned with the visible From domain. If a supplier cannot explain its authentication setup, that is a renewal conversation, not an IT detail.

Do not forget internal senders. A multifunction device that emails scanned documents, a monitoring tool that raises alerts, or a line-of-business application that sends statements can all become silent casualties of a sudden policy change.

Phase the policy so a broken sender does not stop the post

A three-stage rollout is usually sufficient for a UK SME. In the first stage, publish p=none with an aggregate reporting address and leave it in place for at least four weeks. Read the reports. They are XML files, so use a report analyser or a managed service rather than expecting a human to read them.

In the second stage, correct the failing sources and move to p=quarantine with a modest pct= value, such as 10 or 25 per cent. Increase it as the reports stay clean. In the third stage, move to p=reject. Consider sp=reject for subdomains only when those subdomains have been inventoried. Keep the reporting address active after enforcement, and record how to roll back if a legitimate sender fails.

The policy needs a named owner. DNS changes made by a web agency, a marketing contractor or a former employee are a common cause of drift. So is a supplier that changes its sending infrastructure without telling anyone.

Prove that a spoofed message is refused

The presence of a DMARC record is not evidence that spoofing is blocked. A test should send a message from an external host with your domain in the From header and confirm that the receiving mail gateway refuses it. This must be done with written authorisation, using domains and mailboxes you control, and with the receiving side expecting the test.

Test a legitimate sender at the same time. If both the spoof and the genuine payroll message are rejected, the policy is not ready. Inspect the Authentication-Results header on accepted mail and the bounce or rejection message on the spoof. A successful test produces evidence, not a green tick in a vendor console.

Two limits should be stated plainly to management. DMARC does not prevent display-name spoofing, where a fraudulent message uses a familiar name but a different address. Nor does it stop lookalike domains. It reduces exact-domain impersonation, which is why it sits alongside inbound filtering, supplier verification and a call-back rule for bank detail changes.

The questions a board should ask

Who owns the DNS zone, and who can change it? Who reads the aggregate reports? What is the escalation path when a legitimate sender starts failing? Do supplier contracts require email authentication? Is the DMARC posture included in cyber insurance evidence? When was the policy last reviewed?

These are governance questions, not specialist ones. The technical work can be delegated, but the assurance cannot. An organisation that can show a current policy, a monitored reporting mailbox and a tested rejection of a spoofed invoice message is in a stronger position than one that simply has a DMARC record and hopes.