Protecting your email domain: SPF, DKIM and DMARC

Start with a complete list of senders

Who may send email using your company's domain? Answer this together with finance, sales and IT. Alongside ordinary mailboxes, the list may include invoicing software, a newsletter service, a contact form, a ticketing system and scanners. Ask which services people actually use, rather than relying only on the list of purchased licences.

For each sending service, record its purpose, visible sender address, provider and business contact. Also establish who can change DNS records and where changes are documented. This inventory becomes the project brief and the reference for adding or retiring services later.

Include your other business domains. A registered domain that should never send email also needs appropriate protection against sender impersonation. The NCSC recommends considering all of an organisation's domains. [5]

What SPF, DKIM and DMARC each check

SPF checks whether the sending server is authorised for the technical sending domain in the SMTP envelope. That domain may differ from the sender domain recipients see. Permitted servers are specified through DNS.

DKIM links a signing domain to a message. The recipient verifies the cryptographic signature using a public DNS key. It covers selected message components; it neither encrypts the email nor confirms a particular person's identity.

DMARC passes when SPF or DKIM succeeds and the authenticated domain aligns with the visible From domain. Strict alignment requires identical domains; relaxed alignment permits the same organisational domain. An unrelated SPF or DKIM pass is insufficient. [1] [2] [3]

Choose the policy deliberately

p=none requests no special treatment for DMARC failures. p=quarantine requests suspicious-message handling; p=reject requests rejection. The receiving email service determines the actual treatment. None of these settings guarantees delivery of legitimate messages.

Agree an observation period with IT and arrange for the requested reports to be reviewed. Make the period long enough to include monthly invoices and infrequent mailings. A quiet week alone would reveal little about those processes. Ask for unexplained sending services to be investigated before authorising or disabling them. [4]

The evidence your IT provider should deliver

Our suggested acceptance checklist connects configuration with everyday business. Request a short evidence record for each sending service. A screenshot showing three green ticks does not establish whether your invoicing system or contact form sends correctly.

• A maintained inventory of sending services, domains and business contacts.
• A real test message from each service, with the recipient's SPF, DKIM and DMARC results recorded.
• The domains actually checked and evidence of alignment, beyond a simple pass label.
• Separate tests for required forwarding arrangements and mailing lists, with any problems documented.
• A justified target policy, a change date and a specific rollback plan for delivery problems.
• An owner for reports, unresolved questions and repeat checks after provider changes.

Which attacks remain possible

A lookalike domain can pass its own SPF, DKIM and DMARC checks. A familiar display name does not establish identity either. Email authentication does not make a message's contents trustworthy.

DMARC also does not prevent a genuine mailbox being compromised. An attacker can then send through an authorised service. Check unusual payment instructions or bank-detail changes through an independent contact route you already know. [6] [7]

Include maintenance in the brief

Assign responsibility before the project closes. New marketing software, a new website provider or a replacement accounting system should trigger a review of the sending inventory. Record which service was added or removed, what was tested and which questions remain open. This keeps the configuration understandable when the people responsible change.

Related reading

• External attack surface: inventory your domains and services
• Preparing a security assessment for a small business
• DMARC in 2026: what businesses should review in the new standard
• Phishing: your domain, mailbox and payments need different controls