Your visible From address is what DMARC protects: here’s why that matters
DMARC is often described as another DNS switch, but its useful job is narrower. It asks whether the domain in the message’s visible From field, called the Author Domain in the current specification, is connected to a domain that passed SPF or DKIM. A receiver can then consider the domain owner’s published handling preference when that connection is absent. RFC 9989 defines that model and supersedes the earlier DMARC specification.
That pivot matters because SPF and DKIM can authenticate domains that a recipient never sees. A delivery platform may use its own envelope domain for SPF and its own signing domain for DKIM while showing your business domain in From. Those checks can be technically valid yet fail to authorise use of your visible domain. DMARC supplies the comparison, called identifier alignment.
The practical reframe is to treat DMARC as a relationship test for each message, not a badge attached to a whole domain. One newsletter may pass while a website receipt fails, even though both display the same From domain. Your unit of investigation is therefore the sending route and its identities.
If your business has ever had a customer ask “did you send this?”, or if a phishing mail has appeared to come from your own domain, you already know the symptom: the visible From address is what recipients trust. DMARC focuses on exactly that address, which is why it is the most practical anti-spoofing control for a UK business email set-up. The benefit of understanding it is simple: you can spot which of your own services would break under a rejecting policy before you turn enforcement on, instead of discovering it through lost mail.
A pass needs both authentication and alignment
A message passes DMARC when at least one supported authentication path both passes and aligns with the Author Domain. For SPF, DMARC uses the SPF-validated MAIL FROM identity. For DKIM, it uses the signing domain from the d= tag of a valid signature. The current DMARC specification describes both authenticated identifiers and the pass rule.
Relaxed alignment means the authenticated domain and Author Domain share the same organisational domain. Strict alignment means they are identical. If From is accounts.example.co.uk, a valid DKIM signature for mail.example.co.uk can align in relaxed mode but not strict mode. A valid signature for platform.example.net does not align in either mode.
You do not need both paths for a DMARC pass. One aligned DKIM pass can carry the result when SPF fails after forwarding; one aligned SPF pass can carry it when a signature is absent. Keeping both healthy provides resilience, but two unaligned passes still produce a DMARC failure.
Policy expresses a preference, not a delivery command
A DMARC TXT record is normally published at _dmarc.example.com. Its p= value can express none, quarantine or reject for messages that fail DMARC. Receivers may use that preference as part of their own handling. RFC 9989 explains that receivers can choose different actions and are not required to follow the request.
p=none is monitoring mode when aggregate reporting is configured. It does not repair authentication and it does not tell receivers that every message is trustworthy. Quarantine and reject increase protection against exact-domain spoofing, but they can also expose forgotten legitimate routes that never aligned.
A policy change is therefore a risk decision informed by route evidence. It is not a deliverability cure. A passing message may still be filtered because DMARC makes no claim about content, permission, a person’s identity or whether a message deserves an inbox place.
Exact-domain protection leaves other impersonation routes open
DMARC directly addresses unauthorised use of the Author Domain. It does not stop a criminal registering a lookalike domain, abusing a human-readable display name or sending from a compromised legitimate account. The specification lists display-name attacks, visually similar domains and content analysis outside its direct scope.
This limit explains why a DMARC pass should never be rendered to staff as “safe”. It means the domain use was validated through an aligned path. It does not validate the local part before the @ sign, confirm the person who pressed Send or inspect links and attachments. Mail filtering, account security, user reporting and payment verification still matter.
The trade-off is useful clarity. DMARC cannot solve every phishing technique, but it can make your exact domain harder to spoof and can separate unauthorised domain use from mail that your own systems need to authenticate properly. Measure it against that job.
That honesty matters for your peace of mind. DMARC makes your exact domain harder to impersonate, but it is not a general security tool: which is why you still need mail filtering, staff training and account security. Comparing SPF and DKIM side by side shows how each check covers a different gap, and moving from p=none towards reject is the point where protection becomes real.
Gather your real sending routes first so you never break a legitimate sender
Begin with a sender inventory. Include staff mail, support desks, newsletters, payroll, invoices, booking tools, shops, monitoring alerts, scanners and website forms. Give each route an owner and a business purpose. Do not rely on a supplier list, because one supplier account can operate several routes with different domains.
- Send a controlled message. Use the real workflow and a recipient mailbox you control.
- Open the original message evidence. Record the visible From domain, Return-Path or envelope domain, every DKIM
d=ands=value, SPF, DKIM and DMARC results, receiver and UTC time. - Query the live DMARC name. Save the complete TXT answer and TTL. Record the DNS provider and change owner.
- Compare routes. Mark each as aligned by SPF, aligned by DKIM, aligned by both, failed or not yet observed.
Google likewise tells senders to authenticate each sending domain and verify service-provider handling rather than assume a provider has done it. Google’s sender guidance describes its current authentication requirements.
This discovery phase is where most DMARC problems start and where most delivery failures are avoided. Every tool that sends invoices, forms, booking confirmations or monitoring alerts as your domain is a route that must either authenticate or be accounted for. Working through a controlled DMARC rollout in this order means the policy you publish requests the behaviour you can actually support, rather than asking receivers to reject mail that some forgotten system still sends.
Aggregate reports provide a map with deliberate gaps
The optional rua= tag requests aggregate reports at one or more mailto URIs. Participating receivers can report source IPs, message counts, evaluated policy and authentication results. Domain owners can use that evidence to find unauthorised use and gaps in their own sending. RFC 9989 explains the reporting purpose and notes that receivers are not obliged to send reports.
Reports are not a complete application inventory. A receiver may not report, low-volume routes may not appear during your sample, and an IP address may belong to shared infrastructure. Treat a row as a lead to reconcile with contracts, platform settings and controlled messages. Never delete authorisation solely because an IP looks unfamiliar.
Reporting also creates a data-handling decision. Use a dedicated restricted mailbox or a trusted processor with agreed retention. Confirm external reporting authorisation before directing reports outside the policy domain. Record who can access the data and how an incident involving it would be handled.
To turn aggregate XML into route evidence, use the practical DMARC report guide alongside the mechanism described here.
Read one message as a decision tree
Take the Author Domain first. Then inspect SPF. Did SPF pass for the MAIL FROM identity, and does that domain align with From under the published mode? If yes, DMARC can pass through SPF. If not, inspect each valid DKIM signature. Did any signature pass, and does its d= domain align? If yes, DMARC can pass through DKIM.
If neither path passes and aligns, the message fails DMARC. Now classify the cause rather than editing everything: authentication may be absent, authentication may fail, or a passing identity may be unaligned. Those causes have different owners. An SPF include may be relevant to a failing envelope path, while a provider’s custom DKIM setting may be the right fix for an unaligned signature.
Write the observed values in adjacent columns. The comparison should be visible to a non-specialist reviewer. Avoid a single “authenticated: yes” field because it hides the distinction DMARC exists to make.
Keep a DMARC case useful and properly contained
A DMARC case usually needs only a narrow set of facts: the From domain, the envelope domain, any DKIM signing domains, receiver results, dates and the DNS answer in force at the time. Put those facts in the case record, with a reference to the sender-inventory row. Keep the original header in the mail administrator’s restricted evidence area. Customer names, message subjects and complete addresses rarely help with the domain comparison, so remove them from the copy used for routine discussion.
Aggregate reports need their own controls. Source addresses and message counts can reveal suppliers, campaign timing and business volume even though the reports omit message bodies. Limit the reporting mailbox and parsed dashboard to the people who maintain DMARC, agree a retention period, and record any outside processor that receives the files. Do not attach an unredacted report or header to a public supplier forum. A support engineer normally needs the policy domain, relevant authentication fields, timestamps and a small sample of the failing pattern.
Keep secrets out of the evidence altogether. DMARC diagnosis never requires a DKIM private key, mailbox password, DNS recovery code or API token. If the only available header belongs to a customer or member of staff, ask the mailbox or data owner to approve access and redaction before it moves. Stop the investigation if nobody can provide a lawful, controlled route to the evidence.
Prove the DMARC result on the message route itself
A public lookup can show that _dmarc returns a record, but it cannot show which identity a message used. Trigger the same newsletter, receipt or staff-mail action that is under review and send it to a mailbox you administer. In the receiver’s original-message view, record the visible From domain, Return-Path, each DKIM d= value and the SPF, DKIM and DMARC verdicts. Add the UTC time so the evidence can be matched to the DNS version and report period.
Call the route verified only when the received result shows dmarc=pass through the intended aligned domain. A provider-domain SPF pass is not enough if the expected route was aligned DKIM, and a dashboard tick is not a substitute for the received header. After the affected route works, send one known-good control such as an ordinary mailbox message. That catches a root-record replacement which repaired one sender by displacing another.
Keep the public DNS answer, received header and inventory row together. Respect the published TTL, but check the authoritative record and a public resolver rather than waiting blindly. If the new message exposes a different signing domain, an absent signature or a second route, record that finding as a separate fault with its own owner.
Know when the DMARC investigation has reached its limit
Stop editing when you cannot tie the proposed change to an identity observed in a received message. The same applies if two receivers show conflicting domains, the applicable _dmarc name is uncertain, or publishing would replace a record whose owner is unknown. If a live stream starts failing after an edit, use the approved rollback where it is safe and pause only the affected route rather than changing more records.
Give the DMARC owner and the owner of that sender a compact handover: the old and new DNS answers, TTLs, UTC times, route name and redacted headers. Bring in the security or data owner if report access is disputed. Do not respond by relaxing policy across the organisation, authorising an unexplained source, sharing a private key or repeatedly sending failed production mail.
The boundary is simple. No observed aligned identity, no DNS change. Leave working routes untouched until the missing evidence or authority arrives, and write down which decision remains open so the next administrator does not restart from guesswork.
Sources and further reading
- RFC 9989: Domain-based message authentication, reporting and conformance
- Google email sender guidelines