Email was designed without authentication - anyone can put your domain in the From field. SPF, DKIM and DMARC are the retrofit. Without them in enforcement, an attacker can send invoices, payment instructions and password resets that arrive genuinely from your domain, and recipients have no way to tell.
The three records
SPF - who is allowed to send
A DNS record listing the servers permitted to send mail for your domain. The receiving server checks whether the sending IP is on that list.
Two limitations matter. SPF has a hard 10 DNS lookup limit - exceed it and the record fails entirely, which happens easily once you add several SaaS senders. And SPF validates the envelope sender, not the visible From address, so on its own it does not stop what the user actually sees.
DKIM - proof the message was not altered
Outgoing mail is signed with a private key; the public key sits in DNS. The recipient verifies the signature, which proves the message came from an authorised sender and was not modified in transit. Unlike SPF, DKIM survives forwarding, which is why both are needed.
DMARC - the policy that ties them together
DMARC does two things nothing else does. It requires alignment - the domain that passed SPF or DKIM must match the visible From domain, closing the gap that lets a message pass SPF while displaying your brand. And it tells receivers what to do on failure:
p=none- take no action, just report. Monitoring only.p=quarantine- deliver to junk.p=reject- refuse the message outright.
A DMARC record left at p=none provides no protection whatsoever. It is a monitoring stage, not a destination - yet a large share of domains publish one and stop there, which produces a passing checklist item and zero defence.
Track the technical controls behind your framework requirements
GRC Copilot ties automated checks to the controls they evidence, so email authentication, hardening and access controls all report into the same posture.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Reaching enforcement without breaking your own mail
Going straight to p=reject is how organisations discover, painfully, that their invoicing platform and their marketing tool were never authorised. The staged path:
- Publish
p=nonewith anruareporting address. Aggregate reports start arriving within a day or two. - Inventory your senders from the reports. Almost everyone finds legitimate senders they had forgotten - CRM, ticketing, HR platform, payment provider, a decade-old marketing tool.
- Authorise each legitimate sender with SPF and DKIM, watching the SPF lookup count.
- Move to
p=quarantine, optionally with a percentage (pct=25) to ramp gradually. - Move to
p=rejectonce reports show only unauthorised sources failing. - Set
sp=rejectfor subdomains, and publish a null SPF plusp=rejecton domains you own but never send from. Parked and legacy domains are a favourite for attackers precisely because nobody protects them.
Six to twelve weeks is a realistic timeline for an organisation with a typical sender estate.
What this does not solve
DMARC stops exact-domain spoofing. It does nothing about:
- Lookalike domains - an attacker registering a near-identical spelling and authenticating it properly. Their DMARC passes; it just is not you.
- Display-name spoofing - the From name reads like your finance director while the address is a free webmail account.
- Compromised legitimate accounts - mail sent from a real mailbox passes every check, which is why most successful business email compromise looks perfectly authentic.
Those need different controls: monitoring for lookalike registrations, external-sender warning banners, and above all a payment verification process - out-of-band confirmation for any change to bank details, regardless of how convincing the request. Business email compromise consistently causes larger aggregate losses than ransomware, and it is defeated by a phone call to a known number far more reliably than by any email filter.
Frequently asked questions
Is p=none acceptable for compliance?
It satisfies "DMARC is configured" on a checklist and provides no protection. A knowledgeable assessor or customer will ask for the policy value, not just its existence.
Will enforcement break forwarding?
SPF breaks on forwarding; DKIM usually survives it. With both configured, forwarded mail typically still passes DMARC via DKIM - which is precisely why implementing only SPF causes problems.
What about domains we do not send from?
Protect them explicitly: a null SPF record and p=reject. Unused domains are attractive to attackers because they are almost never configured.
Do we need a DMARC reporting product?
Raw aggregate reports are XML and hard to read at volume. A reporting service materially shortens the path to enforcement, though it is not strictly required.
Key takeaways
- SPF lists senders, DKIM signs messages, DMARC enforces alignment and policy.
p=noneis a monitoring stage - protection begins at quarantine or reject.- Use the reports to find the legitimate senders you forgot before enforcing.
- Protect parked domains, and back it all with out-of-band payment verification.