Email is still the primary channel for business communication, but the protocol underneath it — SMTP — was designed decades ago with no built-in way to verify who actually sent a message. As a result, anyone on the internet can send an email that claims to come from your domain. DMARC (Domain-based Message Authentication, Reporting and Conformance) closes that gap by letting you publish a policy that tells receiving mail servers exactly how to handle messages that fail authentication. This guide explains how email spoofing works, what DMARC does about it, and how to deploy it safely.
What is DMARC
DMARC is an open email authentication standard defined in RFC 7489. It is not a technology that validates mail by itself — it is a policy layer that sits on top of SPF and DKIM and is published as a simple TXT record in your DNS at _dmarc.yourdomain.com. The record does three things:
- Specifies which authentication method (SPF, DKIM, or both) must pass.
- Requires alignment: the domain authenticated by SPF or DKIM must match the domain in the message’s From header — the address your customers actually see.
- Tells receiving servers what to do with failures (deliver, quarantine, or reject) and where to send reports about them.
This last point matters because SPF on its own authenticates the invisible envelope sender, not the From address. A spammer can pass SPF for a throwaway domain while displaying your brand in the From field — DMARC ties authentication to the address people actually look at.
How Email Spoofing Works
There are two common forms of email impersonation, and they need different defenses:
- Display-name spoofing: The attacker registers any address on a free mail service and sets the display name to something like “Accounts Payable — Your Company.” The message genuinely comes from a different domain. DMARC cannot block this, because the attacker is not using your domain; user awareness training and mail filtering are the main defenses.
- Domain spoofing: The attacker forges your domain in the From header, so the message appears to come directly from
you@yourcompany.com. Because SMTP performs no sender verification, this is trivially easy with open-source tooling. This is what SPF, DKIM, and DMARC stop.
Domain spoofing fuels fake invoices to your customers, phishing against your own employees (a common entry point for business email compromise), and payroll-redirection scams against your vendors. It also damages deliverability: mailbox providers that see forged mail from your domain learn to distrust it, and your legitimate messages may start landing in spam.
SPF vs DKIM vs DMARC
Understanding the division of labor makes DMARC much easier to troubleshoot:
| Standard | What It Checks | Limitation |
|---|---|---|
| SPF | Whether the sending server’s IP is authorized in DNS | Validates the envelope sender, not the From address; breaks when mail is forwarded |
| DKIM | Whether the message carries a valid cryptographic signature | Signing domain may differ from From domain; needs key management |
| DMARC | Whether SPF or DKIM passed and aligned with the From domain | Requires SPF/DKIM to be in place first |
In short: SPF proves the server is on the guest list, DKIM proves the message wasn’t tampered with, and DMARC enforces that at least one of them matches the domain on the envelope.
How to Implement DMARC Step by Step
DMARC rollout is a project, not a checkbox. Done wrong, it can silently break legitimate email. Follow these steps in order:
- Inventory every sender. List every service that sends email for your domain: your mailbox provider (Google Workspace, Microsoft 365), marketing platforms, CRM, invoicing tools, support desk, transactional mail like order confirmations, and any scripts or servers that send directly. Missing one sender means its mail fails later.
- Publish SPF for every domain and subdomain you send from. Each domain gets exactly one TXT record, for example:
v=spf1 include:_spf.google.com ~all
- Enable DKIM signing on every sending service and add the provider’s DKIM records (published under a selector such as
selector._domainkey.example.com) to your DNS. - Publish a monitoring-only DMARC record.
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Review reports for at least two weeks. Identify legitimate sources that are failing authentication and fix their SPF or DKIM configuration before tightening anything.
- Tighten gradually. Move from
p=nonetop=quarantine, and only after more clean reporting, top=reject. - Keep monitoring. Every new vendor or sending tool you adopt can break your posture, so reports should be reviewed on an ongoing basis.
DMARC Policies
The p= tag in your DMARC record tells receivers what to do with mail that fails both SPF and DKIM alignment:
p=none— Monitor only. Failing mail is delivered normally. Use this during rollout to learn what is sending as your domain without breaking anything.p=quarantine— Treat failures as suspicious. Receivers typically deliver them to the spam folder.p=reject— Drop failing mail outright. This is the strongest protection and the end goal, but only safe once you are confident everything legitimate authenticates correctly.
Two more tags are worth knowing: pct= lets you apply the policy to only a percentage of failing mail (useful for gradual rollout), and sp= sets a separate policy for subdomains. You can also set adkim and aspf to s (strict) if you want alignment to require an exact domain match rather than the default relaxed mode.
Common DMARC Mistakes
- Publishing DMARC before SPF and DKIM are in place — a reject policy with no authentication is a guaranteed way to have your own mail blocked.
- Forgetting third-party senders. The marketing tool or invoicing app you forgot will fail once the policy tightens.
- Multiple SPF records. Only one TXT record starting with
v=spf1is allowed per domain; two records make SPF invalid. - Exceeding the SPF lookup limit. SPF supports a maximum of 10 DNS lookups; stacked
include:statements commonly exceed it. - Alignment failures from your ESP. If your email provider signs with its own domain instead of yours, DKIM passes but DMARC still fails. This is fixed in the provider’s domain-authentication settings.
- Skipping reports. A DMARC policy without
rua=leaves you blind to what is happening with your domain. - Ignoring parked domains. Defensive and inactive domains are spoofing magnets — publish a reject policy on them too.
Monitoring and Reporting
The rua= tag requests aggregate reports: daily XML summaries sent by receiving providers describing every message that claimed to come from your domain, which IP sent it, and whether SPF and DKIM passed. The ruf= tag requests forensic copies of failed messages, though many providers decline to send these for privacy reasons.
Raw aggregate reports are unreadable XML, so most organizations use a free or paid DMARC analyzer to parse them. What to look for:
- Legitimate services failing authentication — fix these before tightening policy.
- Sending sources you don’t recognize — this can be shadow IT or active spoofing.
- Sudden spikes of failed mail from new IP ranges — often an impersonation campaign.
rua reports to a mailbox you control, and review how your chosen analyzer handles that data.Quick Reference: Minimum DMARC Rollout
SPF published → DKIM enabled on all senders → p=none with rua= → two weeks of clean reports → p=quarantine → more clean reports → p=reject.
Conclusion
DMARC is free, DNS-based, and the single most effective control against exact-domain spoofing. It protects customers from fake invoices, employees from impersonation attacks, and your domain from reputation damage. The key is patience: build the SPF and DKIM foundation, monitor in p=none mode, and tighten only when your reports prove it is safe.