DMARC Policy: Essential Guide

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email protocol that sits on top of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) and tells the receiving MTA what to do when mail using your domain in the From header fails both. The record lives in your own DNS, at _dmarc under the domain, so you set the rule and Gmail, Outlook, Yahoo and the rest read it.

Download FREE Step By Step DMARC Implementation Guide

What is DMARC ?

DMARC is an authentication protocol layered on SPF and DKIM. Neither of those older checks looks at the header From address that a human reads, and neither gives the domain owner any feedback. DMARC fixes both: alignment against the visible From domain, and rua/ruf reporting back to the owner.

The reporting is the part people skip and later wish they hadn’t. Without it you find out someone is sending invoices as your domain when a customer forwards one to accounts. With a p=none record and a rua address, you get daily XML from the large receivers listing every IP that used your domain, how many messages, and whether SPF and DKIM passed. Receivers get an instruction for failures; you get data. Exact-domain spam and phishing then become easy to filter, for your staff, your customers and everyone else.

If you want to remove the threat of direct domain spoofing, and stop spear phishing attacks that use your real domain, you must implement DMARC.

Why should you implement DMARC?

The reputational argument is the one that usually gets budget: at quarantine or reject an unauthenticated server can’t land mail as your domain anywhere DMARC is enforced, and since Gmail and Yahoo started requiring bulk senders to publish a record, even p=none has some deliverability value.

The visibility argument is the one that changes minds once the rua data arrives, because the first week of aggregate reports tends to list senders nobody had on the inventory, like a survey tool, the payroll vendor, or an old Zendesk instance still mailing from the apex domain without DKIM.

There is also a wider benefit for the email ecosystem, since receivers that all handle failures the same way drop spoofed mail consistently rather than leaving it to whatever spam filter it reaches.

How it works ?

SPF and DKIM do the cryptographic and IP checks. DMARC asks one extra question: did at least one of them pass for a domain that matches the From header? Then it applies your policy. The flow on a receiving server goes roughly like this:

1. The domain owner publishes a TXT record at _dmarc.example.com, something like “v=DMARC1; p=none; rua=mailto:dmarc@example.com”.
2. A message arrives. The receiver takes the domain from the From header and looks up that record.
3. It runs SPF against the envelope sender and verifies any DKIM signatures, then checks alignment, relaxed or strict depending on the aspf and adkim tags.
4. On failure it applies none, quarantine or reject, and once a day sends DMARC Aggregate Reports to the rua address.

The DMARC protocol matters because email is where invoices, bank detail changes and password resets travel, and SMTP never checked the From header in the first place. Nothing in plain SMTP stops a stranger from mailing your vendors as your CFO.

SPF & DKIM: the prerequisites

SPF

SPF is a TXT record listing the hosts allowed to send for a domain: an include for your mail provider, maybe an ip4 entry for an on-prem relay, then -all or ~all. Only whoever controls the zone can edit it, which is why receivers trust it. The receiver checks the connecting IP against the SPF record of the envelope sender domain (the Return-Path, or MAIL FROM in SMTP terms). Two catches. It never looks at the visible From, and a plain forward breaks it because the forwarding server’s IP is not on your list. SPF also has a cap on DNS lookups, and it gets hit once marketing keeps adding SaaS includes, so list only what actually sends.

DKIM

DKIM is signature-based. It came from merging the DomainKeys and Identified Internet Mail specifications. The sending MTA hashes chosen headers plus the body, signs that with a private key, and adds a DKIM-Signature header carrying d= (signing domain) and s= (selector). The receiver pulls the public key from selector._domainkey.d-domain and checks it. If it verifies, the signed parts were not altered in transit. Forwarding usually leaves DKIM intact; mailing lists that add a footer or tag the subject usually break it.

Any server along the way can check the signature, and so can the mail app on delivery. What a failed or missing signature means is left to the receiver. RFC 6376, the DKIM standard, says mail that cannot be verified should be treated the same as all unverified mail, whether or not it looks signed. DKIM on its own never asks anyone to reject a message. A DMARC policy is how the domain owner says what should happen to mail that fails.

A DMARC policy has three settings: monitor (p=none), quarantine and reject. You choose how hard to be on mail that fails. Our blog goes further into how DMARC works.

How it protects organization from Phishing?

1. Receivers get a yes or no on whether a message really came from your domain. Before DMARC that call was left to spam filters, so real mail got junked and some forged mail got through.
2. Failure handling is the same at every receiver that honours the record, so a spoof blocked at Gmail is also blocked at Outlook.
3. At quarantine or reject, nobody outside your SPF list and DKIM keys can send as your domain. That is what keeps fake payment-change letters off your letterhead.
4. The reports tell you who is sending as you, including the shadow IT nobody mentioned.
5. You hold the dial and can tighten it when the data says you are ready.

For most companies, getting their sending domains to enforcement is the first real defence against phishing that impersonates them. To make this easier we offer DMARC+, with a dashboard that turns the XML into something readable and tracks your progress.

DMARC Deployment Steps

Going straight to reject is how payroll emails disappear on a Friday. Ramp up in a set order instead. A conservative cycle:

1. Monitor all
2. Quarantine 1%
3. Quarantine 5%
4. Quarantine 10%
5. Quarantine 25%
6. Quarantine 50%
7. Quarantine all
8. Reject 1%
9. Reject 5%
10. Reject 10%
11. Reject 25%
12. Reject 50%
13. Reject all

Monitoring is where the real work is. Every legitimate source that fails needs fixing, either by adding it to SPF, turning on DKIM signing with your domain as d=, or both. Then change p=none to p=quarantine in the TXT record and watch the spam folder and the daily reports. Move to reject only when every legitimate stream passes aligned.

The optional pct tag lets you stage each step. Default is 100%. Put “pct=20” in the record and the policy hits one-fifth of failing mail; the rest get the next policy down. It earns its keep at quarantine and reject. Start low, raise it every few days.

Keep reading reports and drop the percentage once the data allows. You are done when forged mail from your domain is rejected everywhere. A domain parked at p=none for years gets reports and no protection, and that is a very common place to stall.

How can I tell if DMARC is making a difference?

A day or two after you publish even a bare monitoring record, reports start to arrive. Say you run example.com and your record has a rua tag: every participating receiver sends you statistics on all mail that claimed your domain. You see how many forged messages there were, where they came from, and whether “quarantine” or “reject” would have stopped them. Each report is an XML file with:

• Every IP address that sent mail using your domain
• A count of messages from each of those IP addresses
• What was done with those messages under the DMARC policy shown
• SPF results for these messages
• DKIM results for these messages

Reading that XML by hand works for about a week on a small domain. After that you want a parser, whether that’s a DMARC service’s portal or an open-source tool like parsedmarc feeding Elasticsearch, so the sources group by sending organisation and the odd IP in a foreign hosting range stands out.

Limitations of DMARC

Against direct domain spoofing DMARC works well. When an unauthorised sender uses your domain (a criminal, or even an unauthorised user of a department of the company that owns/operates the domain), DMARC catches it and, if configured, has receivers block or discard the mail.

Its scope is the exact domain the record sits on, so website.com at p=reject does nothing for website.net unless .NET gets its own record too. Parked domains that never send mail should still get “v=DMARC1; p=reject” and an SPF record of -all, which costs nothing and is missing surprisingly often.

Cousin domain attacks are outside what it can do, because mail from websit3.com instead of website.com comes from a domain the attacker controls, with SPF and DKIM that pass on their own terms. Display name abuse is similar: the sending address is a free webmail account while the name in the “From” field reads as your CEO, and many mobile mail apps show only that name. Lookalike domain monitoring, takedowns and user training are what deal with that part of the problem.

Download Implementation of DMARC

Our step by step guide covers the record syntax, report handling and the move to reject.

Conclusion

When a domain has sat at p=none for months, look for the one sender nobody owns: an old on-prem app relaying through a server that was never added to SPF, or a vendor that would need a contract change to sign with DKIM. That sender is usually the whole delay. For help planning the rollout across your email infrastructure, contact us.

To learn more about DMARC, read our other articles on the topic.