Anyone can put your domain in the From line of an email. Nothing in the basic plumbing of SMTP stops a scammer typing accounts@yourcompany.com into the sender field and posting a fake invoice to your customers. DMARC is the standard that closes that gap. It tells the receiving mail server what to do when a message claims to be from your domain but cannot prove it, and it sends you reports on every attempt, real and forged alike.
What DMARC actually does
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is published as a single TXT record at _dmarc.yourdomain.com, and a minimal version looks like this:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
That record does two jobs. It states a policy, telling inbox providers what to do with mail that fails authentication and claims to be from your domain. It also names an address where those providers should send reports. The policy is the enforcement side. The reporting is how you find out who is sending as you, legitimately or not, before you turn enforcement on.
The problem DMARC solves is old and simple. The From address you see in your mail client is just a header field, and a sending server can write whatever it likes there. SPF and DKIM were the first attempts to add proof of origin, but on their own neither checks the visible From domain. A message can pass SPF and DKIM for a completely different domain and still display your brand in the sender line. DMARC ties the checks back to the address your recipients actually read.
Why passing SPF or DKIM is not enough
This is the part most people miss. SPF and DKIM can both go green and the mail can still be a forgery, because they authenticate domains the reader never sees.
SPF checks the envelope sender, the hidden MAIL FROM address used during the SMTP conversation, not the From header. A bulk sender can set the envelope to bounces@somesender.net, pass SPF for that domain, and still print accounts@yourcompany.com in the visible From line. DKIM signs with whatever domain appears in the signature's d= tag, which again need not match the From.
DMARC adds the missing rule: alignment. For a message to pass DMARC, at least one of SPF or DKIM must not only pass but pass for a domain that matches the From domain. SPF alignment compares the envelope sender domain to the From domain. DKIM alignment compares the signing d= domain to the From domain. You can require an exact match (strict) or allow a parent and subdomain to count as the same organisation (relaxed, the default). Without alignment, DMARC would be no stronger than SPF and DKIM were before it.
Getting each underlying check configured correctly matters here. If you have not pinned down your SPF record and your DKIM signing, alignment will fail in ways that are hard to read in the reports.
The three policy stages
DMARC has exactly one knob that decides enforcement: the p= tag. It has three settings, and they are meant to be used in order, not picked at random.
p=none is monitor only. The receiver applies its normal filtering and delivers as usual, but it sends you reports on what passed and what failed. Nothing is blocked. This is the safe starting point because it cannot break legitimate mail, and it is also the trap most domains fall into, because they stop here.
p=quarantine tells receivers to treat failing mail as suspicious, which in practice means routing it to the spam or junk folder. Real mail that you forgot to authenticate will still reach the recipient, just in the wrong place, so quarantine is a useful pressure test before the final step.
p=reject tells receivers to refuse failing mail outright at the SMTP layer. The forged message never arrives, in any folder. This is the goal. A domain at p=reject with good alignment cannot be convincingly spoofed to the major inbox providers.
| Policy | What receivers do with failing mail | Protection | Risk to real mail |
|---|---|---|---|
p=none | Deliver as normal, send reports only | None, monitoring only | None |
p=quarantine | Route to spam or junk | Partial | Real mail lands in junk if unauthenticated |
p=reject | Refuse at SMTP, message bounces | Full | Real mail bounces if unauthenticated |
Aggregate and forensic reports
DMARC has two report channels, and they are not equally useful.
Aggregate reports go to the address in your rua= tag. Once a day, each participating receiver sends an XML summary: every source IP that sent mail claiming your domain, how many messages, and whether SPF, DKIM and alignment passed or failed. This is the real value of DMARC. It is the only way to see your full sending footprint, including the marketing tool someone set up two years ago, the helpdesk that signs with the wrong domain, and the actual attackers spraying your brand from a botnet.
Forensic reports, set with ruf=, are per-message copies of individual failures, including header detail. They sound more useful than they are. Almost no large receiver sends them any more, because of the privacy implications of forwarding message content, so a strategy built on forensic reports will see almost nothing. Treat ruf= as a niche extra, not the foundation.
The catch is that aggregate reports arrive as raw XML from dozens of providers, in volumes that are unreadable by hand. One mid-sized domain can generate hundreds of files a week. You need them parsed, deduplicated and charted before they mean anything, which is what our DMARC analytics is built to do.
Publishing is easy, reaching p=reject safely is hard
Adding a p=none record takes five minutes. The hard part is everything after that.
To move to p=reject without losing real mail, you have to find every legitimate service that sends as your domain and bring each one into alignment. That list is almost always longer than people expect: the main mailbox provider, a CRM, a billing platform, a transactional email service, a support desk, an events tool, an internal application that fires from a server in a cupboard. Each needs SPF or DKIM configured so that it aligns. Miss one and, at p=reject, its mail starts bouncing.
This is why the work is staged. You read the aggregate reports at p=none until every legitimate source is authenticated and aligned, then move to p=quarantine and watch for anything you missed, then to p=reject. Rushing the sequence is how a company blocks its own invoices. Our enforcement walkthrough covers the staging in detail.
p=reject before identifying its real senders will start refusing its own legitimate mail on day one. Always pass through monitoring and quarantine, reading the reports at each step.What hosted DMARC means with DMARC Engine
Hosted DMARC means you do not manage the record, the reporting endpoint or the staging by hand. We take on the operational side so the move to enforcement is a controlled process rather than a guessing game.
In practice, DMARC Engine does the following across every domain you add:
- Publishes and versions the record. We host the DMARC record and track every change, so you have a history of what was published and when, not a mystery TXT entry someone edited in 2023.
- Stages the policy. We manage the progression from
p=nonetoquarantinetorejectwith our visibility into your reports, so each step is taken only when your senders are ready for it. - Ingests and parses RUA at scale. Aggregate reports from every receiver are collected, parsed and combined across all your domains into one view, instead of XML files you never open.
- Alerts on regressions. If a previously aligned source starts failing, or a new unknown sender appears claiming your domain, you hear about it rather than discovering it in a quarter-end review.
The point of hosting is continuity. Authentication is not a one-off project. A new tool gets added, a key gets rotated, a vendor changes their sending infrastructure, and any of those can quietly break alignment. Hosted DMARC keeps watching after the initial setup, which is the part that usually goes unmanaged.
Subdomain policy and unused subdomains
Your DMARC policy at the organisational domain does not automatically protect every subdomain in the way you might assume, and attackers know it. A common trick is to spoof no-reply@mail.yourcompany.com or some invented subdomain, betting that you protected the apex but left the children open.
The sp= tag sets the policy for subdomains independently of the main p= value. If you omit sp=, subdomains inherit the main policy, which is fine if the main policy is already strict. The risk is unused subdomains that send no mail at all. There is no legitimate traffic to protect, so there is no reason not to refuse everything. A record like this protects the apex while slamming the door on subdomains you never send from:
v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourdomain.com
yourcompany.com is at reject but sp= is loose or your subdomains carry their own weak records, a scammer can still send convincing mail from a subdomain. Default unused subdomains to reject.Common mistakes
Staying at p=none forever
By far the most common failure. Most domains that publish DMARC never leave monitoring, so they collect reports nobody reads and gain no actual protection. A record at p=none stops zero spoofing. It is a starting line, not a finish.
No rua address
Publishing p=none with no rua= tag is the worst of both worlds: no enforcement and no visibility either. Without aggregate reports you are blind to your own senders, which means you can never safely advance the policy. The reporting address is not optional if you intend to reach enforcement.
Misusing pct
The pct= tag tells receivers to apply the policy to only a percentage of failing mail, for example pct=50. It was designed as a gentle ramp toward enforcement. In practice it is widely misunderstood, behaves inconsistently across receivers, and leaves you in a half-enforced state that is harder to reason about than a clean step from quarantine to reject. If you have done the monitoring properly, you rarely need it. Stage by reading reports, not by guessing at percentages.
Who needs DMARC enforcement now
This stopped being optional. Google and Yahoo's bulk-sender rules took effect on 1 February 2024: any domain sending roughly 5,000 or more messages a day to Gmail must have SPF, DKIM and an aligned DMARC record (p=none at minimum), one-click unsubscribe for marketing mail, valid forward and reverse DNS, and a spam complaint rate kept under 0.3%. Microsoft began applying similar requirements to high-volume senders into consumer Outlook.com, Hotmail and Live in 2025, routing non-compliant mail to Junk first with rejection to follow.
Compliance frameworks have caught up too. PCI DSS 4.0 requirement 5.4.1 made anti-phishing controls mandatory from 31 March 2025, and DMARC is the recognised mechanism. Anti-spoofing questions now appear routinely in cyber-insurance forms and vendor security reviews. The combination means a domain still parked at p=none is increasingly a liability, both for deliverability and for audit.
Getting started
The honest sequence is short to describe and careful to execute. Publish a monitoring record. Read the aggregate reports until you can name every legitimate sender. Bring each one into alignment with SPF or DKIM. Move to quarantine, watch, then move to reject and set sp=reject for the subdomains you never use. The difficulty is not the syntax, it is doing this without breaking real mail along the way, and keeping it correct as your sending changes.
Start by seeing where you stand. Run a free scan to check your current DMARC, SPF and DKIM in seconds, then decide whether to handle the path to enforcement yourself or have us host and stage it for you. Pricing is straightforward: enforcement is a one-time £200 introductory fee, ongoing monitoring is £19 per month, both listed at our pricing. Whichever route you take, the destination is the same, a domain that cannot be forged and a clear record of everyone sending in your name.