Email was designed in an era when computers trusted each other, so the original system lets anyone put any address in the from line. SPF, DKIM, and DMARC are the three fixes the industry bolted on, and together they let mailbox providers verify that an email claiming to come from your domain actually does.
You do not need to be a systems administrator to understand them. Each protocol maps to a familiar real-world idea, and setting them up is mostly a matter of publishing a few DNS records in the right order. This guide explains what each one does, how they work together, and how to roll them out without breaking your own mail.
Why this matters more than it used to
For years, authentication was a best practice you could postpone. That era ended when the major mailbox providers began requiring authentication from senders, with stricter rules for anyone sending in volume. Unauthenticated mail now faces rejection or the spam folder no matter how good the content is.
Authentication also protects your brand. If your domain publishes no policy, anyone can send mail pretending to be you, and your customers have no way to tell the difference. The same records that satisfy mailbox providers make you far harder to impersonate.
Do not wait until you cross some sending threshold to care. The requirements tighten as your volume grows, and the details shift over time, so the safe posture is to treat all three protocols as the baseline for any domain that sends email at all.
SPF: the approved-senders list
SPF answers one question: which mail servers are allowed to send email on behalf of your domain? Think of it as the visitor list a security desk keeps at a building's front entrance. If a courier shows up claiming to represent your company and their name is not on the list, the desk gets suspicious.
Technically, the list is a single TXT record in your DNS. It names the services that legitimately send for you, such as your email marketing platform, your company mailbox provider, and your billing system. When a message arrives, the receiving server checks the connecting server against that list.
SPF has a known weakness: it checks a hidden technical sender address rather than the from address people see, and it tends to break when a message is forwarded. That is not a reason to skip it. It is the reason the other two protocols exist.
DKIM: the tamper-evident seal
DKIM attaches a cryptographic signature to each message, like a wax seal on a letter. The seal proves two things at once: the letter really came from the holder of the seal, and nobody opened and altered it along the way.
Your sending service signs each outgoing message with a private key, and you publish the matching public key as a DNS record. Receivers use the public key to verify the signature. If the message was modified in transit, or the signature does not match your domain's key, verification fails.
Unlike SPF, a DKIM signature survives forwarding, because the seal travels with the letter instead of depending on who carried it. That makes DKIM the sturdier of the two checks, and mailbox providers treat it accordingly.
DMARC: the instruction card and the reports
SPF and DKIM each verify something, but neither tells receivers what to do when verification fails. DMARC is the instruction card you leave with the security desk: if someone claiming to be us fails the checks, here is what to do with them, and here is where to send the incident report.
The policy has three levels. "None" means deliver the mail anyway but report it to me. "Quarantine" means send failures to spam. "Reject" means refuse them outright. You choose the level, publish it as a DNS record, and participating receivers around the world follow it.
The reports are the underrated half of DMARC. Receivers send you regular summaries of who is sending mail as your domain and whether it passes the checks. That is how you discover the forgotten newsletter tool still sending as you, and how you catch impersonation attempts against your customers.
Alignment: the detail that ties it together
DMARC adds one requirement the other two protocols lack: the domain that passes SPF or DKIM must match the from address the recipient actually sees. This is called alignment, and it closes the loophole where a message passes checks for one domain while displaying another.
In practice, alignment means configuring your sending services to sign and send using your own domain rather than the provider's shared defaults. A message needs only one aligned pass, SPF or DKIM, to satisfy DMARC, which is exactly why running both gives you resilience when forwarding breaks one of them.
This is usually the step where setups quietly fall short. A service can pass SPF and DKIM under its own shared domain while your from address shows your brand, and DMARC will still count that as a failure. Whenever a platform offers domain verification or custom signing, take it.
Rolling it out in the right order
The safe path is incremental, and each step builds on the last. Jumping straight to a strict policy before verifying your senders is how legitimate mail gets lost.
- Inventory every service that sends email as your domain: marketing platform, company mailboxes, support desk, billing, and anything else.
- Publish SPF listing exactly those services, then confirm your regular mail still delivers.
- Enable DKIM signing in each service and publish the keys it gives you, so every legitimate stream carries a seal.
- Publish DMARC with a policy of "none" and a reporting address, which changes nothing about delivery but starts the flow of reports.
- Read the reports for a few weeks and fix any legitimate source that fails or is unaligned.
- Tighten the policy to quarantine, and later to reject, once the reports show only your real mail passing.
Living with it: monitoring the reports
Authentication is not a one-time setup. New tools get adopted, keys get rotated, and DNS records get edited by whoever touched the zone last. The DMARC reports are your early-warning system, so keep receiving them and glance at a summary regularly.
The raw reports arrive as compressed XML that nobody should read by hand, so run them through a report viewer that turns them into a readable summary. Bazooka Email signs the campaigns you send through it and its deliverability tools walk you through publishing the matching records, but the domain policy is yours. Only you can see the whole picture across every service that mails on your behalf, so make checking it a habit.
Put it into practice
Bazooka Email gives you the editor, automation and deliverability tools to act on everything above — free to start, no card required.