← All articles

SPF, DKIM and DMARC: stop your domain being used for phishing

What SPF, DKIM and DMARC do, how they work together, and a safe path from monitoring to an enforcing DMARC policy.

Email security · 29 October 2026 · 2 min read

By Mason Trevaskis, Founder

If anyone can send email that appears to come from your domain, attackers can impersonate you to your customers, suppliers and staff. Three DNS-based standards, SPF, DKIM and DMARC, let receiving mail servers check whether a message claiming to be from your domain is genuine and tell them what to do if it isn't. Setting them up is not difficult, but the order matters.

SPF: which servers may send

Sender Policy Framework is a TXT record listing the servers and services allowed to send mail for a domain. Receivers check the connecting server against the list for the envelope sender domain.

  • Include every legitimate sender: your mail provider, marketing platform, CRM, billing and ticketing systems.
  • Stay under the limit of 10 DNS lookups, or SPF evaluation fails.
  • Publish only one SPF record per domain.
  • End with ~all or -all. Avoid +all, which allows anyone.

DKIM: was the message signed

DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. The public key is published in DNS under a selector. Receivers verify the signature to confirm the message wasn't altered and was signed by a key the domain controls. Enable DKIM in each sending service and publish the records they give you. Use 2048-bit keys where supported and rotate keys periodically.

DMARC: tie it together and set policy

SPF and DKIM on their own don't check the address people actually see in the From header. DMARC does. It passes when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. DMARC also lets you publish a policy and receive reports.

  • p=none: monitor only. Receivers deliver as normal and send you reports.
  • p=quarantine: failing messages are treated as suspicious, often sent to spam.
  • p=reject: failing messages are refused.

A safe rollout path

  1. Inventory every system that sends email as your domain.
  2. Publish SPF covering them and enable DKIM in each.
  3. Publish DMARC at p=none with an aggregate report address.
  4. Review reports for two to four weeks and fix legitimate senders that fail.
  5. Move to p=quarantine, optionally using pct to apply it to a portion of mail first.
  6. When reports are clean, move to p=reject.
  7. Keep monitoring reports; new tools get added and break alignment.

Don't forget parked domains

Domains that never send mail can still be spoofed. For each one, publish an SPF record of v=spf1 -all, a DMARC record with p=reject, and consider a null MX record. This tells receivers that no legitimate mail comes from the domain.

Quick self-check

  • One SPF record, under 10 lookups, no +all.
  • DKIM enabled for every sending service.
  • DMARC published with a reporting address.
  • A plan and date to reach quarantine and then reject.
  • Parked and unused domains locked down.
  • Someone assigned to read DMARC reports.

What these controls don't do

DMARC stops exact-domain spoofing. It doesn't stop lookalike domains such as examp1e.com, compromised mailboxes, or display-name tricks. Pair email authentication with lookalike domain monitoring, MFA on mailboxes, and staff awareness about payment-change requests.

About the author

Mason Trevaskis is the founder of StrikeWard, a practitioner-led security guidance company based in Australia. This article is general guidance, not legal advice, and does not guarantee any security outcome.

Verify your domain and see SPF, DKIM and DMARC status with clear fixes.

Check your domain in CyberPosture