SPF, DKIM, and DMARC Explained: Stopping Email Spoofing

Q: How to deploy without breaking your mail?

The failure mode here is real and common: a rushed reject policy bounces legitimate mail from a newsletter tool, a support desk, or an invoicing service you did not know sent mail as you. Roll out in order and let the reports guide you. 1. Publish SPF. List every service that legitimately sends for your domain, using i

Email was designed in an era of trust, which is why forging the sender of a message is trivially easy by default. Anyone can put your domain in the From line. The three standards in this guide, SPF, DKIM, and DMARC, are how a domain owner fights back, letting receiving servers verify that a message claiming to come from you actually did. Deploy all three correctly and you make it very hard for an attacker to spoof your domain, and you gain visibility into who is trying.

Each standard does one job, and they only deliver their full value together. This guide explains what each checks, how they combine, and how to roll them out without knocking your own mail offline.

The problem: two different From addresses

To understand these standards you have to know that an email carries two sender addresses, and they can differ.

The envelope sender (also called the return-path or MAIL FROM) is used during delivery, between mail servers. Users never see it.

The header From is the address shown in the mail client. It is what a person reads and trusts.

Spoofing exploits the gap. An attacker can pass some checks on the envelope sender while putting your domain in the header From that the victim sees. Keeping those two in agreement is exactly the problem DMARC was created to solve, which is why SPF and DKIM alone are not enough.

SPF: who is allowed to send

Sender Policy Framework, defined in RFC 7208, lets you publish the list of servers authorized to send mail for your domain. You put it in a DNS TXT record. A simple one looks like this:

v=spf1 include:_spf.example-provider.com ip4:203.0.113.5 -all

That says: mail for this domain may come from the provider referenced by the include, and from the listed IP, and everything else fails (-all). When a receiver gets a message, it looks up the SPF record for the envelope sender domain and checks whether the connecting server's IP is authorized.

SPF has two well-known limits. It authorizes the envelope sender, not the visible From, so on its own it does not protect what the user sees. And it breaks on forwarding, because a forwarding server relays your mail from an IP you never listed. These limits are precisely why DKIM and DMARC exist alongside it.

DKIM: sign the message

DomainKeys Identified Mail, defined in RFC 6376, adds a cryptographic signature to each outgoing message. Your mail server signs selected headers and the body with a private key, and attaches the signature in a DKIM-Signature header. You publish the matching public key in DNS.

A receiver reads the signature, fetches your public key from DNS, and verifies it. If it validates, two things are established: the message genuinely came from a system holding your domain's private key, and the signed content was not altered in transit. Because the signature travels with the message, DKIM survives forwarding in a way SPF does not, since it does not depend on the sending IP. For the underlying mechanism, see How Digital Signatures Work.

DKIM's own gap mirrors SPF's: a valid DKIM signature proves a message was signed by some domain, but it does not by itself require that domain to match the From address the user sees. Again, that is DMARC's job.

Why neither SPF nor DKIM is enough alone

SPF authorizes the envelope sender. DKIM authenticates a signing domain. Neither one, on its own, requires either of those to match the From address the recipient actually reads. An attacker can satisfy a check on a domain they control while spoofing your domain in the visible header. DMARC is the standard that forces the match and closes this exact gap.

DMARC: tie it to what the user sees

Domain-based Message Authentication, Reporting, and Conformance, defined in RFC 7489, sits on top of SPF and DKIM and adds the two things they lack: alignment and instructions.

Alignment is the core idea. DMARC passes only if the domain that passed SPF or DKIM matches the domain in the visible From address. So it is no longer enough for a message to pass SPF or DKIM on some domain; that domain has to line up with the From the user sees. This is what actually stops header spoofing of your domain.

A DMARC record is another DNS TXT entry:

v=DMARC1; p=none; rua=mailto:[email protected]

The p tag is the policy, the instruction to receivers on what to do when a message claiming your domain fails DMARC:

Policy	Receiver behaviour	When to use
`none`	Deliver as normal, just report	Monitoring, the starting point
`quarantine`	Send to spam or junk	After legitimate mail passes cleanly
`reject`	Block the message outright	The end state, full protection

The rua tag is where aggregate reports are sent. Receivers email you daily summaries of what passed and failed under your domain, including the sending IPs. These reports are the single most useful part of a rollout, because they show you every service sending as you, including the ones you forgot about.

Two more DMARC tags are worth setting deliberately. The sp tag sets the policy for subdomains, which by default inherit the main policy, so a domain locked to reject still needs its subdomains covered or an attacker will spoof mail.example.com instead of example.com. The pct tag applies your policy to a percentage of mail rather than all of it, which lets you ramp enforcement gradually, for example quarantining a quarter of failures first to watch the effect before taking it to the full set. Used together they turn a policy change from a cliff into a slope.

How the three fit together

Here is the whole picture in one pass. A receiver gets a message claiming to be from you. It checks SPF against the envelope sender and verifies any DKIM signature. Then DMARC asks: did SPF or DKIM pass, and does the passing domain align with the visible From. If yes, the message is authenticated as genuinely yours. If no, the receiver applies your DMARC policy, monitor, quarantine, or reject, and logs it in a report back to you.

Standard	What it checks	Protects the visible From	Survives forwarding
SPF	Sending IP vs authorized list	No, on its own	No
DKIM	Cryptographic signature	No, on its own	Yes
DMARC	Alignment + policy + reporting	Yes	Uses whichever of SPF/DKIM aligns

The takeaway is that DMARC does not replace SPF and DKIM; it depends on them. It needs at least one of them to pass and align. That is why all three go together.

How to deploy without breaking your mail

The failure mode here is real and common: a rushed reject policy bounces legitimate mail from a newsletter tool, a support desk, or an invoicing service you did not know sent mail as you. Roll out in order and let the reports guide you.

Publish SPF. List every service that legitimately sends for your domain, using include mechanisms for providers. Start with ~all (soft fail) if you are unsure, then move to -all once the list is complete.
Enable DKIM. Turn on signing at your mail provider and publish the public keys they give you. Confirm outgoing mail is signed and verifies.
Publish DMARC at p=none. This changes nothing about delivery. It just starts the aggregate reports flowing to your rua address.
Read the reports for a few weeks. Identify every legitimate sender, and fix any that fail SPF or DKIM alignment. This is where you discover the forgotten services.
Move to p=quarantine. Once legitimate mail passes cleanly, tell receivers to junk the failures. Watch the reports for fallout.
Move to p=reject. When quarantine has been stable, tighten to full rejection. Now spoofed mail using your domain is blocked outright.

Monitor before you enforce

Never jump straight to p=reject. Start at p=none, read the aggregate reports until you can account for every legitimate sender, then tighten in stages. The reports are the whole point of starting soft. They turn a risky change into a measured one and stop you from bouncing your own invoices.

These records blunt domain spoofing, but attackers respond by moving to lookalike domains and other tricks covered in What Is Phishing and AI Phishing Attacks. Our Exploit Intelligence dashboard tracks live vulnerabilities across mail servers and email security gateways, so you can see which flaws in the systems handling your mail are actually being exploited.

A walkthrough of one message being judged

Follow a single message from an attacker who is trying to spoof your domain, and watch where each standard catches it. The attacker connects to a recipient's mail server and announces an envelope sender on a domain they control, while placing your domain in the visible From header that the victim will read. The message carries no valid DKIM signature for your domain, because the attacker does not hold your private key.

The receiving server runs SPF against the envelope sender domain. That domain belongs to the attacker, so SPF may well pass, since the attacker can publish a permissive SPF record for their own domain. SPF has done its job correctly and it has told us nothing about the header the victim sees, which is the gap. Next the server checks DKIM. There is no signature that validates against your domain's public key, so DKIM does not produce a pass aligned to your domain. Now DMARC asks its question: did SPF or DKIM pass on a domain that aligns with the visible From. SPF passed, but on the attacker's domain, which does not match your domain in the From line. DKIM did not pass on your domain either. Alignment fails, so DMARC fails, and the receiver applies your published policy.

If your policy is at reject, the spoofed message is blocked outright and never reaches the victim. If it is at quarantine, the message lands in spam. If it is still at none, the message is delivered, and a report of the failure is sent to your aggregate address so you can see the attempt. The same walkthrough shows why SPF and DKIM alone leave a hole: both can pass on a domain the attacker controls while your domain sits unprotected in the header. DMARC is the step that forces the passing domain to line up with what the recipient actually reads.

Reading an aggregate report

The aggregate reports that arrive at your rua address are XML summaries, one per reporting receiver per day, and they are the instrument that makes a safe rollout possible. Each report groups mail by sending source and records, for each group, the sending IP, how many messages it sent, and whether they passed SPF and DKIM with alignment. Learning to read them is the core skill of a DMARC deployment.

The picture you are building is an inventory of every source sending mail that claims your domain. Some sources you will recognize immediately: your own mail provider, your newsletter platform, your invoicing or support system. Each of these should show passing, aligned results once configured correctly. Sources that fail alignment fall into two groups. The first is legitimate services you forgot about or misconfigured, and the fix is to bring them into your SPF record or enable DKIM signing for them. The second is unauthorized senders, which may be spammers or spoofers using your domain, and these are exactly the mail your eventual reject policy will block.

What the reports do and do not contain

Aggregate reports summarize authentication results by source and volume. They do not contain message subjects, bodies, or recipient lists, so they are a privacy-respecting operational feed rather than a copy of your mail. A separate and optional forensic report type can carry sample failing messages, and many operators skip it for privacy reasons. Treat the aggregate feed as your primary rollout instrument and read it until every legitimate source passes cleanly.

Detection and monitoring signals

Beyond the initial rollout, the reports and your mail logs give ongoing signals worth watching.

A new sending source appearing in reports. An IP or provider you do not recognize starting to send as your domain is either a service someone in your organization enabled without telling you, or a spoofing attempt. Both deserve a look.
A rise in DMARC failures for your domain. A sustained increase in failing, unaligned mail claiming your domain often indicates an active spoofing campaign using your name, which is useful early warning even when your reject policy is already blocking it.
A legitimate source slipping from pass to fail. A provider that was passing and begins to fail alignment usually signals a configuration change on their side, a rotated DKIM key, or a new sending IP outside your SPF record. Catching it in reports prevents your own mail from being quarantined.
Subdomain activity. Mail claiming subdomains you do not actively use can indicate an attacker choosing a subdomain because they expect it to be less protected. This is why the subdomain policy tag matters.

Common mistakes

Jumping straight to reject. Publishing a reject policy before reading reports bounces legitimate mail from services you did not know were sending as you. Start at none, account for every legitimate source, then tighten in stages.

Leaving SPF at soft fail forever. Starting with a soft fail while you build the authorized list is sensible. Staying there indefinitely weakens the record, because a soft fail asks receivers to accept and mark rather than reject unauthorized mail. Move to a hard fail once the list is complete.

Forgetting subdomains. A domain locked to reject still leaves its subdomains exposed if the subdomain policy is not set, and an attacker will happily spoof a subdomain instead. Set the subdomain policy deliberately rather than relying on inheritance you have not confirmed.

Overstuffing the SPF record. SPF evaluation has a limit on the number of DNS lookups it will perform, and a record packed with many nested includes can exceed it, causing SPF to fail even for legitimate mail. Keep the record lean and consolidate providers where you can.

Treating DKIM keys as set-and-forget. Keys should be rotated periodically, and a rotation done carelessly can break signing until the new public key propagates in DNS. Plan rotations, publish the new key before switching, and watch reports through the change.

How email authentication evolved

The standards arrived in layers, each answering a gap the previous one left. SPF came first, giving domain owners a way to declare which servers were authorized to send for them. It worked against the crudest spoofing and it left two holes: it authorized the invisible envelope sender rather than the visible From, and it broke when mail was forwarded. DKIM followed with a cryptographic signature that traveled with the message, surviving forwarding and proving the content was unaltered, and it left its own gap: a valid signature proved some domain signed the message without requiring that domain to match the From address the user reads.

DMARC was designed specifically to close the alignment gap that SPF and DKIM shared, tying the passing domain to the visible From and adding an instruction to receivers plus a reporting channel back to the domain owner. Together the three form a layered system where each covers a weakness in the others. The reporting channel proved to be as valuable as the enforcement, because it gave operators the visibility to deploy safely and to see who was sending as them. The direction of travel since has been toward wider adoption of reject policies and richer tooling for reading reports, as more receivers enforce DMARC and more senders complete the journey from monitor to full enforcement.

Frequently asked questions

Do I need all three, or is one enough? You need all three working together. SPF and DKIM each authenticate something, and neither on its own requires the authenticated domain to match the From address the recipient sees. DMARC supplies that alignment requirement plus policy and reporting, and it depends on at least one of SPF or DKIM passing and aligning, so the three are a set.

Why does SPF break on forwarding? SPF checks the connecting server's IP against your list of authorized senders. When a message is forwarded, the forwarding server relays it from an IP you never listed, so SPF fails for that hop. DKIM survives forwarding because its signature travels with the message and does not depend on the sending IP, which is one reason the two standards complement each other.

What is DMARC alignment in plain terms? Alignment means the domain that passed SPF or DKIM has to match the domain in the visible From address. Without alignment, an attacker could pass a check on a domain they own while showing your domain to the victim. Requiring the match is what actually protects the address your recipients read.

Is it safe to start at a reject policy? It is risky. A reject policy takes effect immediately on every receiver that honors it, and any legitimate service you forgot to authorize will have its mail blocked. Start at none, read the aggregate reports until you can account for every legitimate sender, then move through quarantine to reject on the evidence.

What does the percentage tag do? It applies your policy to a fraction of failing mail rather than all of it, which lets you ramp enforcement gradually. Quarantining a portion of failures first shows you the effect on a smaller slice before you take the policy to the full volume, turning a sudden change into a measured one.

Will these standards stop all phishing? They stop exact spoofing of your domain, which is a significant category. They do not stop lookalike domains, display-name tricks, or compromised legitimate accounts, so attackers shift to those once your domain is locked down. Pair strong authentication with user awareness and the broader controls covered in the phishing guides.

How long should I stay in monitor mode? Long enough to see a full cycle of your legitimate mail and account for every sender in the reports, which is commonly a few weeks and depends on how many services send as you. The goal is confidence that no legitimate source is failing alignment before you begin quarantining, rather than a fixed calendar date. Organizations with many sending services and seasonal mail, such as quarterly invoicing or annual campaigns, may need to watch longer to catch sources that only send occasionally. A source that sends once a quarter will not appear in the reports until it does, so a rollout that ends too soon can quarantine legitimate mail the first time a rare sender fires.

The bottom line

SPF says which servers may send for you. DKIM signs your messages so forgery and tampering are detectable. DMARC forces those checks to line up with the address your recipients actually see, tells receivers what to do when they do not, and reports back who is sending as you. Deploy all three, roll DMARC out from monitor to reject on the evidence of the reports, and you take domain spoofing off the table for your organization. For the wider setup, see the Email Security Guide.