Hear this article read aloud.
A customer forwards you an invoice they received from your company. It has your name, your logo and your email address in the From line, and you never sent it. Or the opposite happens: your real invoices start landing in your customers’ spam folders, and nobody can tell you why.
Both problems come back to the same three short records in your domain’s DNS settings. Most business owners have never looked at them, and many were set up years ago by whoever configured email at the time. Here is what they do, in plain terms, and how to get them right without breaking the mail you actually send.
Three records, three jobs
Email was designed long before anyone worried about impersonation, so anyone can type any address into the From line. These three records are how the rest of the internet checks whether a message really came from you.
- SPF is a list of the servers allowed to send email for your domain. A receiving mail server checks whether the message came from one of them.
- DKIM adds a digital signature to each message. The receiving server checks the signature against a public key published in your DNS, which proves the message was sent by someone holding your key and was not changed on the way.
- DMARC ties the two together. It tells receiving servers what to do when a message claiming to be from you fails those checks, and where to send reports about what they saw.
SPF and DKIM do the checking. DMARC is the instruction sheet that says what the checks are for.
What the policies mean
A DMARC record carries a policy, written as p= followed by one of three values:
- p=none is monitor only. Mail is delivered as usual, and you get reports.
- p=quarantine asks receiving servers to send messages that fail into spam.
- p=reject asks them to refuse failing messages outright.
Since 2024, Google and Yahoo have required bulk senders to publish a DMARC record. Even if you do not send in volume, having at least a monitoring policy is now table stakes.
One trap is worth calling out on its own. A policy of p=none with no reporting address is monitoring mode with the monitoring switched off. The record is there, it looks fine at a glance, and it tells you nothing. We see it often.
The safe path to a strict policy
The goal for most businesses is p=reject, so nobody can send convincing mail in your name. The way to get there without losing real email is slow and deliberate:
- Start at p=none with reporting turned on. Add a reporting address to the record so receiving servers tell you what they see.
- Read the reports and list every legitimate sender. Most businesses send from more places than they realize: the main email provider, a newsletter tool, a CRM, the website’s form notifications, invoicing or accounting software, a scheduling tool.
- Authorize and align each one. Each sender needs to be included in SPF, set up to sign with DKIM for your domain, or both, and the domains it uses have to match yours.
- Move to p=quarantine. Watch the reports for anything legitimate that starts failing.
- Move to p=reject once the reports have been clean for a while.
Reports, and where they should go
Reports arrive daily from each large mailbox provider, including Google, Microsoft and Yahoo. They are machine-readable files, not friendly summaries. Pointed at a personal inbox, they quickly become noise, and the useful signal gets lost in it.
A reporting service is the better home for them. Several services collect and summarize DMARC reports, including Cloudflare’s DMARC Management for domains on Cloudflare, and they turn a pile of attachments into a readable list of who is sending as you and whether it passed.
Check alignment before you tighten
This is the step that catches people out. Passing SPF is not enough on its own: DMARC also wants the domain that passed to match the domain in your From line. That match is called alignment.
Campaign and newsletter tools often send using their own domain for the bounce address. SPF passes for their domain, not yours, so it does not align, and the message leans entirely on DKIM. If DKIM is set up for your domain, the message still passes DMARC. If it is not, everything delivers fine under p=none and starts landing in spam the day you move to quarantine.
So before you tighten the policy, send a real message from each tool to an address you control and open the full headers. Look for the authentication results and check that DKIM passes for your own domain, not the tool’s. Do this for every sender on your list, not just the main one.
Change mail records carefully
DNS records for email control whether your mail arrives and whether mail sent to you reaches your inbox. A small typo in the wrong record can stop either. Treat changes to them like any other change with real consequences:
- Know which domains are in scope before you start, including any extra domains you own.
- Save a copy of every record before you edit it, so you can put it back exactly.
- Change one thing at a time and confirm mail still flows in both directions.
One more case is easy to forget. A domain that never sends email, such as a parked domain or one that only redirects to your main website, should publish p=reject anyway. Nothing legitimate will ever fail, and it stops anyone from using that domain to impersonate you.
For a broader look at the basics, our plain-English cybersecurity checklist covers the other everyday protections worth having in place.
Where we come in
Email authentication is part of our cybersecurity and data protection work, where we review your records, find every sender and move your domains to a strict policy without losing real mail.



