Email was designed without a way to prove who sent a message. DMARC is how your domain gets that proof — and how you find out who is already sending mail in your name.
The problem: anyone can send email as your domain
The protocol that moves email around the internet, SMTP, does not verify the sender's address. A message actually carries two "from" addresses: the envelope sender, used by mail servers to route bounces, and the header From — the address your recipients see in their mail client. Nothing in SMTP itself stops a stranger from putting invoicing@example.com in that visible From field and sending the message from a server on the other side of the world.
This is exact-domain spoofing, and it is what makes invoice fraud and CEO impersonation emails so convincing: the message genuinely displays your domain. Recipients cannot be blamed for trusting it — the address looks perfectly real, because it is your real address, used without permission.
SPF and DKIM in plain terms
Two DNS-based mechanisms exist to let receiving servers check where mail really came from:
- SPF (Sender Policy Framework) is a published list of the servers allowed to send mail for your domain. A receiving server looks up the list and checks whether the connecting server is on it.
- DKIM (DomainKeys Identified Mail) is a cryptographic signature attached to each message. The receiving server fetches your public key from DNS and verifies that the message was signed by someone holding your private key — and was not altered in transit.
Both are necessary, and our practical SPF and DKIM setup guide walks through configuring them. But on their own they have a blind spot: neither one is required to match the From address your recipients actually see. SPF checks the envelope sender's domain; DKIM validates whatever domain signed the message. A spoofed email can pass both checks — using the attacker's own domain — while still displaying yours in the From field.
The fix for that blind spot is called alignment: requiring that the domain which passed SPF or DKIM matches the domain in the visible From header. Alignment is exactly what DMARC adds.
What DMARC does
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record published at _dmarc.example.com. A minimal record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comIt does three things:
- Ties authentication to the visible From. A message only passes DMARC if it passes SPF or DKIM with alignment — the passing domain must match the From domain recipients see.
- Tells receivers what to do on failure. The
p=policy instructs receiving servers to do nothing (none), send failures to spam (quarantine) or refuse them outright (reject). - Sends you reports. The
rua=address receives aggregate reports from mail providers describing every source that sent mail claiming to be your domain.
The rollout journey: none, quarantine, reject
Nobody should publish p=reject on day one. The safe journey has three stages:
- p=none — observe. Nothing changes for mail delivery. You collect aggregate reports and build a picture of every system sending as your domain: your mail provider, but also the newsletter platform, the CRM, the invoicing tool and that one server nobody remembered.
- p=quarantine — enforce softly. Once every legitimate sender passes SPF or DKIM with alignment, failing mail starts going to spam folders. The
pct=tag lets you apply the policy to a percentage of traffic first, easing in gradually. - p=reject — enforce fully. Failing mail is refused before it ever reaches an inbox. This is the destination: spoofed mail using your exact domain simply stops being delivered by participating providers.
Moving through the stages typically takes weeks, not hours — the time is spent finding legitimate senders you did not know about and fixing their authentication before you tighten the policy.
What aggregate (RUA) reports reveal
Aggregate reports are the underrated half of DMARC. Participating mail providers send a daily XML file to your rua= address summarising the mail they received with your domain in the From field: which IP addresses sent it, how much, and whether it passed or failed SPF, DKIM and alignment.
Read over a few weeks, the reports answer a question most organisations cannot answer today: who sends email as our domain? The usual discoveries include a marketing platform someone signed up for years ago, a support tool sending from its own servers, a misconfigured internal system — and, frequently, unknown third parties attempting to spoof the domain. None of this is visible any other way.
The catch is that raw reports are machine-readable XML, arriving daily from every provider, and are tedious to interpret by hand. This is a job for tooling, not for a Friday afternoon.
Common pitfalls
- Jumping straight to reject. If a legitimate sender is not yet authenticated, its mail disappears. Start at
p=noneand let the reports prove you are ready. - Forgetting third-party senders. Newsletter tools, helpdesks and billing systems all send as your domain. Each needs SPF or DKIM configured with your domain, or it will fail once you enforce.
- Publishing no rua address. A DMARC record without reporting gives you enforcement but no visibility — you will never see what the policy is blocking.
- Ignoring subdomains. By default your policy also applies to subdomains, but the
sp=tag can override it — and a permissive subdomain policy leaves a door open. - Treating DMARC as a one-off project. Records get edited, senders get added, and a policy accidentally downgraded from reject to none silently removes your protection. DMARC needs monitoring, not just deployment.
Where MailControl fits
MailControl monitors SPF, DKIM, DMARC, MX, BIMI, MTA-STS and TLS-RPT for each of your domains and ingests your DMARC aggregate reports, so instead of raw XML you see exactly who sends mail as your domain — with unauthorised senders flagged. If your protection is ever weakened, such as a DMARC policy being downgraded, MailControl alerts you. There is also a DNS setup guide with copy-ready records to get the modern trio — DMARC, MTA-STS and TLS-RPT — in place. For the bigger picture, see the email trust and deliverability use case.
Does DMARC stop phishing?
DMARC stops exact-domain spoofing: with a reject policy, mail that puts your real domain in the From field but fails authentication is refused by participating providers. It does not stop lookalike domains — a phisher who registers a domain one character away from yours sends mail that authenticates correctly for that lookalike domain, which is a brand-protection problem rather than an email-authentication one.
What does p=none actually do?
Nothing to mail delivery. A p=none policy is monitoring mode: receiving servers deliver mail exactly as they did before, but send aggregate reports describing which sources sent mail as your domain and whether it passed authentication. It is the right starting point because it gives full visibility with zero risk of losing legitimate mail.
How long should a domain stay on p=none?
Until aggregate reports show that every legitimate sender passes SPF or DKIM with alignment — typically a few weeks to a couple of months, depending on how many third-party services send as the domain. Moving to quarantine or reject before then means legitimate mail lands in spam or disappears.
Do I need DMARC if I use Microsoft 365 or Google Workspace?
Yes. A hosted email provider authenticates the mail it sends for you, but DMARC is a property of your domain, not your mailbox provider. Without a DMARC record, receiving servers get no instruction to reject spoofed mail using your domain, and you receive no reports about who is sending as you. Major mailbox providers also increasingly require DMARC from senders, so a missing record can hurt your own deliverability.