DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is the policy and reporting layer that turns SPF and DKIM into a working defence against domain spoofing. This article explains what DMARC is, how it works, why UK businesses cannot afford to be without it in 2026, and how it relates to the rest of the authentication stack.
DMARC is a DNS TXT record published at _dmarc.yourdomain that tells receiving mail servers three things:
From: header (relaxed or strict alignment).DMARC does not itself authenticate anything. It sits on top of SPF and DKIM, telling receivers how to interpret their results in a way that actually protects the visible From: header that users see — which neither SPF nor DKIM does on its own.
SPF validates the envelope sender. DKIM validates the signing domain. Neither protects the From: header a recipient's mail client displays. That gap meant an attacker could send a message with From: [email protected] while using a completely different envelope sender domain (with valid SPF) and a completely different DKIM signing domain (with valid DKIM) — and every authentication check would pass while the user saw a forged sender.
DMARC closes that gap with alignment: the domain that passes SPF or DKIM must match the From: header domain. An attacker cannot satisfy both the display and the alignment without actually controlling the domain — which is precisely the whole point.
DMARC also introduces policy (what receivers should do when alignment fails) and reporting (who is sending as your domain). The reporting piece is often undervalued but is operationally the most useful: DMARC aggregate reports reveal every forgotten SaaS, legitimate or otherwise, sending mail under your name.
From: header is [email protected].spf=pass or spf=fail.dkim=pass or dkim=fail._dmarc.firm.co.uk. If a DMARC record exists, it reads the policy, alignment mode, and reporting addresses.firm.co.uk? Does the DKIM d= match firm.co.uk? At least one must align and produce a pass for DMARC to pass.p=: none (deliver anyway), quarantine (send to spam), or reject (refuse).rua= tag summarising all messages received claiming to be from firm.co.uk.All of this happens automatically. The domain owner's only role is publishing a DMARC record, collecting the aggregate reports, and gradually tightening the policy as report data confirms legitimate senders are passing.
Alignment is the DMARC concept that closes the From:-header gap.
The envelope sender domain (MAIL FROM) must match the From: header domain. Two modes:
aspf=r, the default). The organisational domains must match. bounce.firm.co.uk aligns with firm.co.uk.aspf=s). Exact match required. bounce.firm.co.uk does not align with firm.co.uk in strict mode.The DKIM signing domain (d= in the DKIM-Signature header) must match the From: header domain. Same two modes: adkim=r or adkim=s.
DMARC passes if at least one of these is true:
From: header domain, ORFrom: header domain.Both are not required — a single aligned pass is sufficient. This redundancy is deliberate: it allows forwarding (which breaks SPF but usually preserves DKIM) to pass DMARC via the DKIM path.
| Policy | What receivers do on failure | When to use |
|---|---|---|
p=none | No enforcement. Messages deliver as usual. Reports still generated. | Initial deployment — observe before enforcing. |
p=quarantine | Failing messages go to spam folder. | Intermediate step after confirming legitimate senders pass. |
p=reject | Failing messages are rejected at SMTP level. | Full enforcement — maximum protection. |
Most UK business deployments progress through these in order over weeks to months, using DMARC aggregate reports at each stage to confirm legitimate mail is passing before tightening.
The pct= tag adds granularity: p=reject; pct=25 means 25% of failing messages are rejected and 75% fall through to the subdomain policy or are delivered. Useful during the p=reject rollout to limit blast radius.
Daily XML reports sent by most large receivers (Google, Microsoft, Yahoo, Proofpoint, Fastmail) summarising every message they observed claiming to come from your domain. Each report entry contains:
The reports arrive as XML attachments wrapped in email. Do not try to read them by eye — use a DMARC processing service or an open-source parser like parsedmarc. A UK IT team managing more than one or two domains will save days of effort by paying a small monthly fee for a dedicated DMARC dashboard.
Per-message failure reports with full headers. Most large providers do not send these due to privacy concerns; aggregate reports are sufficient for virtually all UK deployments.
The tag is ruf=. Rarely populated in modern practice. Do not rely on it.
An initial monitoring record published while rolling out a new deployment:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"After two weeks of monitoring and confirming all legitimate senders pass, tighten to:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1"After further monitoring, ramp pct= to 100 and progress to reject:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]; fo=1"The final record has strict alignment and rejects every failing message — the posture of a domain taking authentication seriously.
| Source | Requirement | Applies to |
|---|---|---|
| Cabinet Office GOV.UK mail policy | DMARC p=reject | Central government domains |
| NCSC Email Security guidance | Minimum DMARC p=quarantine | Public sector and suppliers |
| NHS Digital DTAC | Authenticated email | NHS suppliers |
| Google/Yahoo bulk sender rules (2024) | DMARC record required | Bulk senders over 5,000/day |
| Microsoft sender requirements (2025) | Equivalent DMARC requirements | Outlook.com/Hotmail |
| PCI DSS 4.0 | Email authentication controls | Card-accepting businesses |
For most UK businesses in 2026, publishing a DMARC record — and progressing it to at least p=quarantine — is no longer optional. The only question is how quickly and at what policy level.
DMARC emerged in 2011 from a consortium of large mailbox providers and senders (Google, Yahoo, Microsoft, PayPal, Bank of America, Fidelity, American Greetings and others) who needed a unified way to act on SPF and DKIM results. The initial specification was published jointly at dmarc.org in January 2012, then formalised as RFC 7489 in March 2015.
The adoption curve was steep. By 2015, every major mailbox provider supported DMARC. PayPal used it to dramatically reduce phishing. Yahoo notoriously published p=reject in April 2014, which broke many mailing lists and accelerated the development of ARC as the forwarding-compatibility solution.
UK public sector adoption followed quickly. GOV.UK mandated DMARC p=reject on central government domains in 2016, and NCSC launched Mail Check as a monitoring service for accredited public-sector domains. By 2024, the Google-Yahoo bulk sender rules effectively made DMARC a business requirement for any UK business sending meaningful marketing or transactional volume.
Today DMARC is published on roughly 75% of commercial UK domains (by a 2025 NCSC survey), with about 40% at p=quarantine or p=reject. The trajectory is upward — the 2024 rules shifted the baseline, and every year more UK businesses move from monitoring to enforcement.
The interaction of DMARC with forwarders (mailing lists, gateways, university relays) is where most deployment pain originates. When a message is forwarded, SPF fails (the sending IP changes) and DKIM may fail (if the forwarder modifies content). Under p=reject without compensating mechanisms, every forwarded message gets rejected.
The modern solutions are ARC (RFC 8617) which preserves the original authentication across forwarding hops, and mailing-list From-rewriting which brings the visible From: to the list's domain so its DKIM aligns. Gmail, Microsoft 365 and most modern UK receivers honour ARC from trusted forwarders. Mailman 3 and similar modern list software rewrite headers.
For a UK business rolling out DMARC, the forwarder question becomes: can we publish p=reject without blocking legitimate forwarded mail? The answer is yes for most senders, provided:
p=none and go straight to reject." Technically yes, organisationally suicidal. Almost every UK business that tries this blocks some legitimate mail for weeks.v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected] — maximum enforcement with strict alignment and aggregate reporting via Mail Hardener. All Business Email, Private Email and Public Administration Email customers get SPF and DKIM configured automatically; publishing your DMARC record is the final step you take.
Q: Do I need a DMARC record if I have SPF and DKIM?
A: Yes. Without DMARC, receivers cannot know you want From:-header protection. Google and Yahoo require a DMARC record (any policy) as of 2024.
Q: What is the safest first DMARC record to publish?
A: v=DMARC1; p=none; rua=mailto:your-report-address. Zero enforcement, full reporting. You learn everything about your mail flow without risk of blocking anything.
Q: How long does it take to get to p=reject safely?
A: For a small domain with few senders, 4-6 weeks. For a large organisation with many SaaS tools, 2-6 months. The time is spent at p=none identifying senders, fixing their SPF/DKIM, then gradually ramping.
Q: What happens if I publish DMARC without also publishing SPF or DKIM?
A: Every message fails authentication. Under p=reject your mail is rejected everywhere. Always publish SPF and DKIM first.
Q: Can DMARC affect my deliverability even at p=none?
A: Marginally positively. Having a DMARC record tells receivers you care about authentication, which is a mild positive signal. The enforcement benefit kicks in at p=quarantine and above.
Q: Are DMARC reports sensitive information?
A: Yes — they reveal your sender infrastructure in detail. Treat RUA addresses as you would a monitoring alert address: accessible to IT but not published publicly. Many UK DMARC services generate a dedicated reporting address per customer that does not reveal the organisation's domain structure.
Q: How often should I review DMARC aggregate reports?
A: Daily during initial rollout; weekly at steady state. Any new source IP appearing in reports is either a new legitimate sender you should add or a spoofing attempt you should investigate.
Q: Can DMARC be bypassed by a determined attacker?
A: Not for messages that spoof your exact From: domain. It can be bypassed by attackers who register lookalike domains (firm-co-uk.com) — defence against lookalikes is a separate discipline (registry monitoring, defensive registration).
Q: Does DMARC make any difference for a small UK domain sending only a few messages per week?
A: Yes — modern receivers weight authentication heavily regardless of volume. A small UK sole trader with proper DMARC sees noticeably better deliverability than one without.
Q: Is DMARC going to be replaced by something newer?
A: DMARCbis, an IETF draft, is clarifying a few edge cases and deprecating rarely-used tags, but keeping the protocol fundamentally the same. No replacement is on the horizon.
Q: What happens if my domain's DMARC record is temporarily unavailable (DNS outage)?
A: Most receivers treat DNS lookup failures as "no DMARC record" and fall back to default behaviour (typically accepting with SPF/DKIM pass). Brief DNS outages do not cause mail to be rejected — though extended outages on the receiving side can cause inconsistent behaviour.
Q: Does DMARC apply to mail I receive, or only mail I send?
A: Only mail sent claiming to come from your domain. DMARC is a sender-side policy telling receivers how to handle your mail. For inbound filtering of mail claiming to come from other domains, your mail server reads those domains' DMARC records and enforces their policies.
Q: Can I have different DMARC policies for different subdomains?
A: Yes. The sp= tag on the parent DMARC record sets a default policy for subdomains. Individual subdomains can publish their own _dmarc records which override the parent. This is useful for separating marketing (less strict) from transactional (strict).
Q: Is publishing DMARC visible to competitors or attackers?
A: DMARC records are public DNS. Attackers can read them — but they can also read every SPF and DKIM record and know exactly what authentication you have. The transparency is intentional and does not help attackers; it helps receivers make correct decisions about your mail.
Q: How do UK regulators verify that we have DMARC enforcement in place?
A: Most regulators that care (NCSC Mail Check, ICO during breach investigation, PCI auditors) simply query DNS. A DMARC record is public and immediately verifiable. Some frameworks also require evidence of ongoing monitoring — aggregate report processing screenshots, policy change logs, quarterly reviews.
Q: What is the single most useful DMARC tag after p= and rua=?
A: pct=. It lets you enforce policy on a percentage of failing mail — starting at 10% or 25% and ramping to 100% — without committing to full enforcement on day one. Many UK DMARC rollouts use p=quarantine; pct=25 as a practical intermediate state.