# SPF, DKIM and DMARC Explained: How to Stop Attackers Spoofing Your Domain By CYBRT Advisory Team 9 December 2025 5 min read On this page 1. SPF: who is allowed to send 2. DKIM: proof the message was not altered 3. DMARC: the policy that ties it together 4. A rollout plan that does not break email 5. Domains you do not use for email 6. Why this is no longer optional 7. What these records will not do If anyone can send email that looks like it came from your domain, your customers and staff will eventually believe one of those messages. Three DNS records fix most of the problem, as long as you roll them out in the right order. Email was designed in an era when nobody expected senders to lie. The protocol will happily deliver a message claiming to be from your finance director, sent from a server you have never heard of. Attackers use this for invoice fraud, credential phishing and payment redirection, and it works because the message arrives with your name on it. SPF, DKIM and DMARC are the standards that let receiving mail servers check whether a message really came from you. None of them is new and none is expensive. Yet many organisations have only one of the three in place, or have all three in a state that protects nothing. Here is how each works, and how to deploy them without breaking legitimate mail. ## SPF: who is allowed to send Sender Policy Framework is a DNS TXT record that lists the servers permitted to send mail for your domain. A receiving server looks up the record and checks whether the connecting server is on the list. A few details matter: - **The ending.** -all tells receivers to fail anything not listed. ~all is a softer "probably fail". Start with ~all while you discover senders, then tighten it. - **The ten lookup limit.** SPF allows at most ten DNS lookups when it is evaluated. Every include counts, and nested includes count too. Exceed the limit and the record fails for everyone, which is a common way to break your own mail. - **What SPF checks.** SPF validates the envelope sender, the hidden return path address, not the From address your users see. On its own, it does not stop someone forging the visible From line. That is the gap DMARC closes. ## DKIM: proof the message was not altered DomainKeys Identified Mail adds a cryptographic signature to each outgoing message. Your mail platform signs with a private key, and you publish the matching public key in DNS under a selector name. The receiver fetches the key and verifies the signature, which proves the message was sent by someone holding your key and was not modified on the way. Use 2048-bit keys where your platform supports them, and rotate keys periodically. Every service that sends on your behalf, including your marketing platform, ticketing system and HR tools, should sign with your domain rather than its own. Most of them support this but leave it switched off until you configure it. ## DMARC: the policy that ties it together Domain-based Message Authentication, Reporting and Conformance does two jobs. First, it requires alignment: the domain in the visible From address must match the domain that passed SPF or DKIM. That is what finally stops attackers spoofing the address people actually read. Second, it tells receivers what to do with messages that fail, and asks them to send you reports. The p tag is the policy. none means monitor only, quarantine sends failures to spam, and reject blocks them outright. Only reject fully protects your domain. A DMARC record stuck at p=none for years gives you reports but no protection, and it is one of the most common findings in our assessments. ## A rollout plan that does not break email The risk with email authentication is never the attacker. It is the forgotten system that sends invoices or password resets and suddenly starts landing in spam. Go in stages. 1. **Inventory every sender.** List every platform that sends mail as your domain: your main mail service, CRM, marketing tool, helpdesk, payroll, finance system, website forms and any on-premises applications. Ask each department; someone always knows about one more. 2. **Publish SPF and enable DKIM** for each legitimate sender. Keep SPF within the lookup limit by removing services you no longer use. 3. **Publish DMARC at p=none** with an address that receives aggregate reports. Use a DMARC reporting tool to read them; the raw XML is not meant for humans. 4. **Watch for two to four weeks.** The reports show every source sending as your domain and whether it passes. Fix the legitimate ones that fail. Anything left over is either a forgotten system or someone spoofing you. 5. **Move to p=quarantine**, optionally using the pct tag to apply it to a percentage of mail first. Keep reading reports. 6. **Move to p=reject .** At this point a forged message using your exact domain should be blocked by major mailbox providers. ## Domains you do not use for email Parked and unused domains are easy targets, because nobody is watching them. Lock them down with an SPF record that allows no senders and a DMARC reject policy: Do the same thinking for subdomains. DMARC's sp tag sets a policy for subdomains that do not publish their own record. ## Why this is no longer optional Since 2024, Google and Yahoo have required bulk senders to authenticate with SPF and DKIM and to publish a DMARC record, and other mailbox providers have moved in the same direction. If your organisation sends newsletters, statements or notifications at volume, weak authentication now affects deliverability as well as security. It also matters for compliance. Email protection appears in the NCA Essential Cybersecurity Controls, and assessors increasingly check the DNS records directly because they are public and easy to verify. ## What these records will not do DMARC protects your exact domain. It does nothing about lookalike domains such as an extra letter or a different extension, and it does not stop a genuinely compromised mailbox from sending convincing mail. You still need gateway filtering, monitoring for newly registered lookalike domains, multi-factor authentication on mailboxes, and staff who know how to report a suspicious message. Think of authentication as closing the most obvious door, not the whole building. Not sure where your domain stands today? Question eleven of our [free maturity assessment](https://cybrt.sa/maturity/) covers exactly this, alongside nineteen other controls. How CYBRT can help ## Technology Consulting & Deployment End-to-end implementation of security technology that protects your infrastructure, applications and data. ## Keep reading Threats 16 Sept 2026 3 min read ### Oh, I use MFA! Passkeys were supposed to end phishing. How device code phishing gets past MFA, and the identity controls that stop it. Threats 26 Aug 2026 3 min read ### DeepFake: Is it really you? Deepfake video calls are now a working fraud method. How the scams work and the verification steps that protect your organisation. Resilience 18 Oct 2026 7 min read ### Ransomware Response Plan for Saudi Organizations: The First 72 Hours A practical ransomware response plan for Saudi organisations: what to do in the first hour, day and 72 hours, including NCA reporting and PDPL notice. ## Ready to protect your business? Book your free security consultation today. --- Canonical page: https://cybrt.sa/spf-dkim-dmarc-explained/ Guide for AI agents: https://cybrt.sa/llms.txt