DMARC

The definition, separated from the acronym soup

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is published as a TXT record at the name _dmarc followed by your domain, and it does three jobs. It states a policy for mail that fails authentication. It defines whether the domain used to authenticate must match the domain a recipient actually sees in the From header. And it asks receivers to send reports about what they observed.

It is not a spam filter, not an encryption scheme and not an authentication protocol in its own right. SPF and DKIM do the authentication work. SPF says which servers may send for a domain, checked against the envelope sender. DKIM says the message was signed by a holder of a private key, checked against a public key in DNS. DMARC sits above both and answers the question a mailbox provider actually cares about: this message claims to be from your brand, and do the checks for your brand agree?

That distinction explains the most common misunderstanding in the inbox. A team adds DMARC, sees a policy in place, and assumes spoofing is solved. It is not solved until the policy is enforcing and the legitimate senders are authenticated, and those two conditions arrive in that order over weeks or months, not in one DNS edit.

Alignment: the test that decides everything

Alignment compares two domains. For SPF, it compares the domain in the envelope sender, the one used in the SMTP conversation, with the domain in the visible From header. For DKIM, it compares the d= value in the signature with the visible From domain. If they match, the result is aligned and DMARC passes for that mechanism even if the other one fails.

There are two modes. Relaxed alignment accepts the organisational domain, so mail from marketing.example.co.in with a From of example.co.in is aligned because both resolve to the same organisational domain. Strict alignment requires an exact match. Most organisations publish relaxed alignment and rely on DKIM for the streams where the envelope domain differs, such as an email service provider sending on behalf of the brand.

This is where vendor configurations fail. A platform may sign with its own domain, or send from a bounce domain that belongs to the platform, and the message passes SPF for the platform while failing DMARC for the brand. The fix is not to loosen the policy. It is to configure a custom sending domain, a custom DKIM selector under your domain and a custom return path, so both checks align with the identity the recipient sees.

The record itself, tag by tag

A minimal record is one line: version, policy, and a reporting address. In practice a working record carries more, and each tag has an operational meaning. The version must be DMARC1 and must come first. The p tag sets the policy for the domain. The sp tag sets a different policy for subdomains, which matters when marketing sends from mail.example.com while the apex is locked down. The pct tag asks receivers to apply the policy to a percentage of failing mail.

The rua tag is the aggregate report destination, and ruf asks for forensic copies of individual failures. Aggregate reports are XML summaries, usually daily, and they are the only practical way to discover senders you forgot existed. Forensic reports are rare in practice because they raise privacy questions, and many large receivers do not send them at all, so do not build a process that depends on ruf.

Two more tags shape behaviour. adkim and aspf set relaxed or strict alignment for DKIM and SPF respectively. fo controls when a forensic report is generated, and ri sets the reporting interval. Publish one record, not several, and keep it under the DNS size limits, because a record split across strings is still one record but a second record at the same name is a misconfiguration that receivers may treat as no policy at all.

How the policy ladder actually behaves

p=none means monitor. Receivers still evaluate alignment and still send reports, but they deliver failing mail normally. It is not a weak setting; it is the only responsible first setting, because it reveals the sender inventory without breaking revenue. A week of aggregate reports on a domain with a long history usually shows between five and thirty distinct sending sources, and several of them are not in anyone’s documentation.

p=quarantine asks receivers to treat failing mail as suspicious, typically delivering it to spam. This is the stage where legitimate streams break loudly, which is why it should follow a period of monitoring in which every source has been authenticated or deliberately retired. Some teams stage the change with pct, applying quarantine to a slice of failing traffic first. That reduces blast radius, but it also means the domain is still spoofable for the remaining share, so pct is a staging tool rather than an end state.

p=reject asks receivers to refuse failing mail outright. Once enforcement is stable, this is the setting that actually stops brand impersonation, because a spoofed message claiming your domain has no path to the inbox. Enforcement also unlocks stronger treatment elsewhere: some providers gate sender benefits and brand indicators on an enforcing policy, and bulk sender expectations increasingly assume it.

Reading aggregate reports without drowning

An aggregate report lists, per reporting organisation, the IP addresses that sent mail claiming your domain, the authentication results, the alignment results, the message counts and the disposition applied. In XML it is verbose; as a table it is compact. The useful columns are source IP, envelope domain, header From domain, DKIM result with selector, SPF result, count and policy disposition.

The first pass is enumeration, not judgement. Group by source IP and by DKIM selector, then attribute each group to a system. Most groups are obvious once resolved: a CRM, a ticketing tool, a payroll platform, a printer, a monitoring service, a legacy form handler on a marketing site. A few are genuinely unknown, and those deserve attention because unknown senders are either forgotten infrastructure or someone abusing the domain.

The second pass is trend. Passing percentages per source, over weeks, tell you whether authentication is stable. A source that passes at 99 percent and then drops to 60 percent has usually had a key rotated or a DNS record changed. Report volume itself is a signal: a sudden jump in failing mail from a new IP range is the signature of a spoofing attempt, and it is also the best argument for finishing the move to enforcement.

A decade of legacy senders, and how to find them

Long-lived domains accumulate senders the way old offices accumulate keys. There is the email service provider from 2016, the applicant tracking system nobody remembers buying, the scanner that emails contracts to accounts, the old ticketing tool that still sends password resets, the developer who wired a cron job to send reports through a local mail relay, and the website form that posts through a hosting provider’s shared mail server. None of them are malicious. All of them will fail enforcement if left alone.

The inventory comes from three sources that must be combined. DNS shows what SPF and DKIM records currently authorise, including include chains that hide third parties several levels deep. Aggregate reports show what is actually sending, which is often a superset of DNS. And the finance and IT systems of record show what is being paid for, which catches the vendor whose mail is sent from infrastructure you never authorised in DNS at all.

Resolve include chains deliberately. A single include can pull in dozens of netblocks and a vendor that left the chain years ago. When a stream is identified, decide whether to keep it, authenticate it properly, or retire it in favour of a channel you control. That decision is a business one, and it should be made with the owner of the stream rather than by whoever holds the DNS login.

The rollout plan, phase by phase

A realistic rollout for a domain with legacy senders runs a quarter, sometimes two. Phase one is instrumentation: publish p=none with a reporting address you control, confirm reports arrive, and build the table that resolves sources to systems. Phase two is authentication: custom sending domains, DKIM keys under your own selectors, SPF records trimmed to what is genuinely used, and a documented owner for each stream.

Phase three is partial enforcement. Move to quarantine, either fully or with a percentage that rises week by week, and watch the complaint and bounce channels rather than only the reports. This is where a forgotten invoice stream announces itself, usually through a finance colleague forwarding a message that landed in spam. Phase four is full rejection, with sp set separately for subdomains and a monitoring loop that treats any new failing source as an incident.

Two details make the plan survivable. First, a rollback path: knowing exactly which record to restore and who can publish it within an hour. Second, a freeze window: no policy change during a major campaign, a product launch or a festive sale period. DMARC changes are small text edits with large blast radius, and treating them like a deployment rather than a DNS tweak is the difference between a controlled migration and a quiet revenue leak.

Where legitimate mail still fails

Forwarding is the classic casualty. When a mailbox forwards mail, the envelope sender changes to the forwarder while the visible From stays yours, so SPF fails. DKIM usually survives because the body signature travels with the message, which is exactly why relaxed alignment plus DKIM is the robust configuration for anything that might be forwarded. Mailing lists behave similarly, rewriting the subject and sometimes the body, and a list that breaks DKIM will break DMARC too.

Indian delivery adds its own wrinkles. Businesses commonly run mail on a regional provider, a global suite and a shared hosting mailbox at the same time, and the visible From domain is frequently a .co.in brand domain while the envelope belongs to the host. Government and public sector recipients often run strict filtering with their own allow lists. A vendor that works fine for a Bengaluru startup can fail at a PSU recipient because the PSU filters on alignment rather than on reputation.

The reliable pattern is to authenticate every stream under your own domain, avoid rewriting, and keep a small number of well-documented exceptions. Exceptions should be recorded with an owner and a review date, not left as an unexplained pct value that nobody dares to change.

What to measure once enforcement is live

Four numbers matter. DMARC pass rate by stream tells you whether authentication is stable. Alignment failure count tells you whether a vendor changed something without telling you. Rejected message volume tells you how much impersonation the policy is stopping, which is the number that justifies the project to a sceptical finance team. And complaint rate tells you whether legitimate mail is being caught in the net.

Read them together. A rising reject count with a stable pass rate is success: more spoofed mail is being refused. A rising reject count with a falling pass rate is an incident: a legitimate stream has broken and is being rejected along with the attackers. A flat reject count with a rising complaint rate suggests the policy is fine but the content is not.

Then extend the perimeter. Enforcement on the primary domain does nothing for a lookalike registered last month, a hyphenated variant, or a subdomain nobody monitors. Registering the obvious defensive domains and publishing records for them is cheap. Monitoring certificate transparency logs for new certificates that contain your brand is a useful early warning, and it pairs naturally with the DMARC work rather than replacing it.

Mistakes, and a worked example

The expensive mistakes are predictable. Publishing p=reject on day one breaks streams and teaches the organisation to distrust email security. Forgetting sp leaves subdomains open while the apex looks protected. Pointing rua at an external domain without publishing the authorisation record means reports are silently dropped. Leaving duplicate SPF records, or an SPF record with more than ten DNS lookups, produces permerror results that look like a DMARC failure and are not.

A worked example makes the sequencing concrete. Suppose a mid-market SaaS company sends 4,00,000 messages a month: 2,50,000 product notifications, 90,000 invoices and receipts, 40,000 lifecycle campaigns and 20,000 from a legacy form handler. Monitoring shows a fourth source, an old applicant tracking system, and a spoofing campaign of roughly 30,000 messages a month from an overseas range. Authentication fixes the first three, the form handler is rebuilt, the tracking system is retired, and enforcement stops the spoofing entirely.

The order matters more than the tooling. Inventory, authenticate, enforce, monitor. A team that buys a report-parsing product before it knows which systems send mail has automated the wrong step, and a team that enforces before it authenticates has simply moved its own invoices into spam.

• One DMARC record per name, one SPF record per name, no duplicates.
• Trim SPF to under ten lookups and remove vendors you no longer pay.
• Use your own DKIM selector names so rotation stays in your control.
• Publish the authorisation record for external report destinations.
• Set sp deliberately; the apex policy does not cover subdomains.