If people are receiving mail that appears to come from your domain and did not, your domain is being spoofed. Nothing was compromised. The sender simply wrote your address in the From field, which anyone can do.
You cannot stop them writing it. You can make receiving servers reject it, and that is what the three DNS records are for.
What each record actually does
SPF lists which servers may send for your domain. A receiver checks whether the sending server is on the list.
DKIM signs each message with a key, so the receiver can verify it was not altered and came from an authorised sender.
DMARC is the one that stops spoofing. It tells receivers what to do when SPF and DKIM fail, and asks them to report what they saw.
Without DMARC, a failing message is scored as suspicious and usually delivered anyway. That is why a domain with correct SPF and DKIM can still be spoofed effectively. Nothing instructed anyone to reject. Understanding SPF, DKIM and DMARC Records walks through the syntax.
Do not start at reject
The mistake that takes down your own mail.
A policy of p=reject published before you know every legitimate sender means anything you overlooked stops being delivered, your newsletter service, your invoicing system, the form on your website, a colleague sending from a different tool.
Those failures are silent from your side. The messages are rejected at the far end and nobody tells you.
Start at p=none, which changes nothing about delivery and asks for reports:
v=DMARC1; p=none; rua=mailto:[email protected]
Read the reports before tightening
Aggregate reports arrive daily as XML, one per receiving provider, listing which servers sent using your domain and whether they passed.
They are unreadable by hand at any volume. Use a service that parses them (several have free tiers) and give it a fortnight.
What you are looking for is a list of legitimate senders you did not know about. Almost every organisation finds at least one: a CRM, a helpdesk, a booking system, an old server still sending notifications.
Authorise each of those in SPF and DKIM. When the reports show only your known senders passing, and the failures are all spoofing, you are ready to tighten.
Then move in steps
p=quarantine with a percentage first, so failing mail goes to spam rather than being rejected, and only for a share of it:
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
Raise the percentage over a few weeks, then move to p=reject.
The whole process takes a month or two, and that is the point: each step is reversible and each one surfaces a sender you forgot.
Alignment is what usually fails
The detail that explains a message passing SPF and still failing DMARC.
DMARC requires the domain that passed SPF or DKIM to match the domain in the From address. A service sending on your behalf often passes SPF for its own domain, not yours, so SPF passes, alignment fails, and DMARC fails.
The fix is DKIM signing with your domain, which the service configures by giving you records to publish. Most reputable senders support it; one that does not is a sender you cannot align, and that is worth knowing before you reach reject.
Forwarding breaks SPF, by design
A forwarded message arrives at the destination from the forwarding server, which is not on your SPF list. SPF therefore fails legitimately.
DKIM usually survives forwarding, which is why having both matters: DMARC passes if either aligns.
This is also why forwarding a busy role address to an external provider is worth reconsidering. How to Set Up Shared and Role-Based Mailboxes walks through the alternatives.
Protect the domains you do not send from
Often overlooked, and it is the easiest win here.
A parked domain, an old brand, a domain you bought defensively: none of them send mail, and all of them can be spoofed.
Publish a policy saying so, on each:
v=DMARC1; p=reject;
With an SPF record of v=spf1 -all alongside it. There is no rollout needed, because there are no legitimate senders to break.
What this does not stop
Worth being clear, because it is often oversold.
It does not stop mail from a similar domain: a lookalike with a swapped letter is a different domain, and your records say nothing about it.
It does not stop a display name reading as your company while the actual address is elsewhere, which is what most phishing does because it works on phones where the address is hidden.
And it does not protect a compromised mailbox of your own, because that mail is genuinely authorised.
If it is already happening
Publish p=none today so you can see the scale, and start the process above.
Then tell the people receiving it, in one short message, that the mail is not from you and what to look for. That does more immediate good than any DNS change, because the records take days to have an effect and a warning takes minutes.
And check it is spoofing in place of a compromise: mail sent from your own server appears in the mail logs, and spoofed mail does not. For reading them, see Email Routing and Track Delivery in cPanel.
If the messages genuinely came from your server instead of being forged elsewhere, that is a different and more urgent situation. What to Do When an Email Account Is Compromised has the detail.
Read the reports rather than guessing at alignment
The aggregate reports are the only view of what is actually being sent as your domain, and they answer the question that matters before tightening anything.
dig _dmarc.example.com TXT +short dig example.com TXT +short | grep -i spf dig default._domainkey.example.com TXT +short | head -c 120
What you are looking for in the reports is legitimate mail that fails. A newsletter service, a form on the site, an invoicing system or a support desk each sends as your domain and each needs to be authorised explicitly.
Tightening the policy before that list is complete stops your own mail. The reports exist so the list can be built from evidence rather than from memory, and a month of them is worth more than any amount of reasoning about which systems send.
Watch it after tightening, not only before
A policy that was correct when set stops being correct as systems are added, and nothing announces the change.
dig example.com TXT +short | grep -c 'v=spf1' dig example.com TXT +short | grep -o 'include:[^ ]*' | wc -l
Two authentication records is a configuration error that voids the check entirely, and it happens when a new service adds its own rather than editing the existing one.
The include count matters too, since each one is resolved when mail is checked and there is a limit on how many lookups are permitted. A record that has grown past it fails for everybody, and it fails quietly. Review it whenever a new sending service is added rather than annually. The email deliverability tool covers the checks.