In short
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers how to treat email using your domain that fails aligned SPF and DKIM checks, and where to send reports. RFC 9989 replaced RFC 7489 in May 2026, and gov.uk guidance requires DMARC on UK public sector email domains.
Want help with DMARC?
We can plan it with you or do it for you. Tell us where you are up to.
DMARC meaning in plain words
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email authentication standard that lets the owner of a domain such as example.co.uk do three things, all from one TXT record in DNS:
- Authenticate: ask receiving mail servers to check that mail using your domain in the visible From address really passed SPF or DKIM for your domain
- Report: ask those servers to send you regular reports on all the mail they saw using your domain, legitimate or not
- Conform: state what should happen to mail that fails: nothing yet (p=none), treat it as suspicious (p=quarantine) or refuse it (p=reject)
In the words of the current specification, RFC 9989 (opens in a new tab), DMARC gives domain owners "a method … to publish a DNS TXT record describing the email authentication policies for the Author Domain and to request specific handling for messages using that domain that fail validation checks". The Author Domain is the domain in the From address your recipients see, which is the one criminals forge.
So when people ask "what's DMARC?", the short answer is: the DNS record that ties SPF and DKIM to the From address, says what to do when they fail, and gets you the reports to prove your own mail is set up properly. Our DMARC record explained guide breaks down every part of the record.
How does DMARC work? Step by step
Every time a DMARC-aware mail server receives a message, it runs the same checks. RFC 9989 section 4.9 (opens in a new tab) puts it simply: the receiving server looks up whether a DMARC record exists for the From domain and, if one does, "will use the results of SPF and DKIM validation checks to determine the DMARC validation status".
| Step | What the receiving server does | Example |
|---|---|---|
| 1. Read the From domain | Takes the domain from the visible From address (the Author Domain) | From: accounts@example.co.uk gives example.co.uk |
| 2. Check SPF | Checks the envelope (Mail From or Return-Path) domain against that domain's SPF record | Mail From bounce@example.co.uk, sending IP listed in its SPF record: pass |
| 3. Check DKIM | Validates each DKIM signature and notes its signing domain (the d= tag) | d=example.co.uk, signature valid: pass |
| 4. Check alignment | Asks whether a passing SPF or DKIM domain matches the From domain (relaxed: same organisational domain; strict: identical) | mail.example.co.uk aligns with example.co.uk in relaxed mode |
| 5. Look up the policy | Queries the TXT record at _dmarc.(From domain), or at the organisational domain if there is none | _dmarc.example.co.uk: v=DMARC1; p=quarantine; rua=... |
| 6. Decide and apply | DMARC passes if at least one aligned SPF or DKIM pass exists; otherwise the server weighs the p policy (none, quarantine or reject) | Unaligned, unsigned mail from an unknown server: likely spam folder |
| 7. Report | Records the result and, if the record has a rua tag, includes it in an aggregate report to you | A daily XML report listing the sending IP, counts and results |
Two details matter in practice. First, DMARC needs only one aligned pass, SPF or DKIM, though RFC 9989 recommends using both. Second, the policy is a request: RFC 9989 says a receiver "can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so", and uses DMARC as one input to its wider filtering. The SPF, DKIM and DMARC explained guide covers how the three fit together.
Not sure which option applies to you? Ask us
Tell us about your organisation and we will point you to the right option.
What DMARC protects against, and what other controls cover
DMARC is built to stop exact-domain spoofing: someone sending email that uses your real domain in the From address. That covers fake invoices "from" your accounts team, password-reset lures "from" your IT desk and phishing sent to your customers in your name. RFC 9989 section 2.2 (opens in a new tab) describes the goal as preventing "the unauthorized use of the Author Domain … a technique known as spoofing".
The same section is clear about its scope: DMARC "does not address the use of visually similar domain names or abuse of the RFC5322.From human-readable display name". The other controls that cover those cases sit alongside it:
| Threat | Covered by DMARC? | What also helps |
|---|---|---|
| Mail forged with your exact domain in the From address | Yes, once your policy is at quarantine or reject | Your DMARC reports show who is attempting it |
| Unused or parked domains used for spoofing | Yes, if those domains publish a DMARC record at p=reject (with sp and np) | A strict record on every domain you own |
| Lookalike domains (for example examp1e.co.uk) | No | Email security (opens in a new tab) filtering and lookalike domain monitoring |
| Display-name tricks (a familiar name over a stranger's address) | No | Inbound email filtering and security awareness training (opens in a new tab) |
| Compromised genuine mailboxes | No: that mail authenticates correctly | Multi-factor authentication and account monitoring |
DMARC also improves your own visibility. The aggregate reports are, as RFC 9989 puts it, a way "to flag and fix gaps in their own authentication practices", which is often how organisations discover a forgotten marketing tool or an old server still sending as them.
Why DMARC matters for email delivery
DMARC is now a condition of reaching the biggest consumer inboxes in volume. Google, Yahoo and Microsoft all ask high-volume senders for a DMARC record with mail that passes it. None of them requires p=reject: p=none is the minimum, but your mail must pass DMARC, which means every service sending as you must be aligned.
| Mailbox provider | Who the DMARC rule applies to | Minimum DMARC requirement |
|---|---|---|
| Gmail (opens in a new tab) | Senders of more than 5,000 messages a day to personal Gmail accounts | A DMARC record (p=none is acceptable), with the From domain aligned to SPF or DKIM |
| Yahoo (opens in a new tab) | Bulk senders (no published threshold) | A valid DMARC policy of at least p=none, and DMARC must pass |
| Outlook.com (opens in a new tab) | Domains sending more than 5,000 messages a day to Outlook.com, Hotmail and Live.com | SPF and DKIM pass, and DMARC of at least p=none aligned with SPF or DKIM |
Google and Yahoo also require SPF or DKIM from every sender, whatever the volume, and Google recommends DMARC reports so you can monitor mail sent from your domain. The full rules, including one-click unsubscribe and spam-rate limits, are on our DMARC sender requirements page.
Prefer a hand with this?
We can help you plan it and set it up, alongside your own team.
The DMARC standard today: RFC 9989 replaces RFC 7489
For more than a decade the reference for DMARC was RFC 7489, an Informational RFC published outside the IETF's standards process. In May 2026 the RFC Editor published its replacement as three Standards Track documents, and the RFC 7489 page (opens in a new tab) now reads "This RFC is now obsolete, see RFC 9989, RFC 9990, RFC 9991."
| Document | What it covers | Status |
|---|---|---|
| RFC 9989 (opens in a new tab) | DMARC itself: the record, policies, alignment and how receivers find your policy | Proposed Standard, May 2026 |
| RFC 9990 (opens in a new tab) | Aggregate (rua) reports: the XML format, daily or more frequent | Proposed Standard, May 2026 |
| RFC 9991 (opens in a new tab) | Failure (ruf) reports about individual messages | Proposed Standard, May 2026 |
| RFC 7489 | The original 2015 DMARC specification | Informational, now obsolete |
What changes for a domain owner is small but worth knowing:
- pct is gone. The percentage tag is now listed as historic, because RFC 9989 appendix A.6 (opens in a new tab) found it "was usually not accurately applied, unless the value specified was either 0 or 100"
- t (test mode) is new. t=y asks receivers to apply one level below your stated policy while you test, so p=reject with t=y is handled as quarantine
- np is new. It sets a policy for subdomains that do not exist, so made-up subdomains can be blocked too
- rf and ri are gone. The failure report format and report interval tags are historic too
- Organisational domains are found by a DNS Tree Walk rather than a public suffix list
Existing records stay valid, and our DMARC checker flags pct and other historic tags so you can tidy them up. Do it with care: Receivers that have not yet adopted RFC 9989 ignore t and apply your stated policy in full, so only publish quarantine or reject once the reports show your senders passing. If your record has pct below 100, removing it applies the full policy everywhere, so step p down a level first rather than just deleting pct.
Getting started with DMARC
Most organisations follow the same four stages. Each one has a guide or tool on this site.
| Stage | What you do | Where to start |
|---|---|---|
| Check | See whether your domains already publish DMARC, which policy they set and where reports go | DMARC checker |
| Create | Publish a record at p=none with a rua address so reports start arriving | DMARC record generator and how to set up DMARC |
| Monitor | Read the reports, name every sender and fix its SPF and DKIM alignment | DMARC monitoring and DMARC reports |
| Enforce | Move to quarantine and, where it suits the domain, reject | DMARC policy |
The NCSC's recommended implementation plan (opens in a new tab) follows the same path, from choosing an anti-spoofing management tool through marking spoofed mail as spam and rejecting it to continuous improvement. It also advises that "all of your domains, including parked domains, should have DMARC records in place" (NCSC (opens in a new tab)).
How we help with DMARC
Understanding DMARC is the easy part; getting every domain to enforcement without blocking your own mail is where most of the work sits. We can help with each stage:
- Assess your domains: we review DMARC, SPF and DKIM on every domain you own, parked ones included, and list the services sending as you
- Set up reporting: we can point your rua tag at a monitoring platform so the reports are collected and readable
- Choose and supply the platform: we supply EasyDMARC, Valimail and the Check Point Email Security DMARC Management add-on and help you choose between them
- Plan your route to enforcement: we help you plan each policy change, domain by domain, at a pace that suits you
Licences can be billed monthly, with terms confirmed at quote. Contact us for free advice on your domains.
More DMARC basics
Frequently asked questions
What does DMARC stand for?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Authentication is the SPF and DKIM check tied to your From domain, reporting is the feedback mailbox providers send you, and conformance is the policy (none, quarantine or reject) you ask them to apply to mail that fails.
Is DMARC mandatory in the UK?
For the public sector, yes. gov.uk's Securing government email (opens in a new tab) guidance applies to all public sector email domains and says they must have DMARC, DKIM and SPF records in place and set up DMARC reporting, reviewing the data regularly. For businesses and charities the practical driver is the mailbox providers: Gmail, Yahoo and Outlook.com require DMARC from high-volume senders. See DMARC compliance.
Does DMARC stop all phishing?
No. DMARC stops criminals using your exact domain in the From address once your policy is at quarantine or reject. RFC 9989 says it does not address lookalike domains or display-name abuse, and it cannot help when a genuine mailbox has been compromised. Inbound email filtering, multi-factor authentication and staff awareness cover those.
Is DMARC an email security product?
No. DMARC is an open IETF standard that any domain owner can publish in DNS, free of charge. Products such as EasyDMARC, Valimail and the Check Point Email Security DMARC Management add-on help you collect and read the reports, host your records and move to enforcement. DMARC protects your domain's name in other people's inboxes; inbound email security protects your own inbox.
Does DMARC work without SPF and DKIM?
No. DMARC has nothing to check without them: a message passes DMARC only when SPF or DKIM passes for a domain aligned with the From address. RFC 9989 recommends deploying both, and says domains that publish p=reject must apply valid DKIM signatures rather than rely on SPF alone.
Is DMARC free?
Publishing a DMARC record costs nothing; it is one TXT record at your DNS host. The work is in reading the reports, which arrive as XML from every mailbox provider. A monitoring platform turns them into named senders and pass rates. Ask us for a quote for EasyDMARC, Valimail or Check Point.
Still have a question about DMARC?
Ask us and a member of our team will get back to you.