A DMARC record tells receiving mail servers how to evaluate mail sent in your domain's name and what to do with forgeries. It builds on SPF and DKIM: those two check whether a message is authentic, while DMARC compares the result with the domain in the visible "From" header and publishes a policy. The classic mistake is switching DMARC on with p=reject on day one, only to find that invoices, website order notifications and CRM newsletters stop reaching customers. A staged rollout driven by reports avoids that.
What a DMARC record looks like
DMARC is a plain TXT record published at the _dmarc subdomain, so for example.uz the name is _dmarc.example.uz. Tags are separated by semicolons. The key tag is p: none means monitor only, quarantine asks receivers to treat failing mail as spam, and reject asks them to refuse it outright.
_dmarc.example.uz. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.uz; fo=1"The rua tag sets where aggregate reports go. Large providers typically send a daily XML report listing which IPs sent mail as your domain, how many messages, the SPF and DKIM results and whether they aligned. Few providers send forensic failure reports, so aggregate reports are what you will actually rely on.
Stage 1: monitor with p=none
Nothing is blocked yet; the goal is an inventory of every system that sends as your domain. Reports routinely reveal senders nobody remembered: the website contact form, accounting software, a newsletter platform, even an old office scanner. Use a dedicated mailbox for reports and consider a DMARC analysis service that turns the XML into readable tables. If reports go to an address on a different domain, that domain must publish an authorization record:
example.uz._report._dmarc.analytics-domen.uz. IN TXT "v=DMARC1"Monitor for at least two to four weeks so that monthly invoices and other infrequent mail show up in the data.
Fixing legitimate sources
For each source ask whether it is legitimate. If it is, it must pass SPF or DKIM with an aligned domain; one aligned pass is enough. A newsletter platform that signs with its own domain passes DKIM but not alignment, so you enable custom-domain DKIM in its settings and add the CNAME or TXT record it provides.
| Source | Typical problem | Fix |
|---|---|---|
| Hosting mailboxes | DKIM not enabled | Enable DKIM, publish the key |
| Website form | PHP mail() sent as the server | Send through authenticated SMTP |
| Newsletter service | Signed with the service's domain | Configure custom-domain DKIM |
| Unknown foreign IPs | Spoofing | Leave them; DMARC will block them |
Stage 2: quarantine, gradually
Once nearly all legitimate mail passes, move to quarantine. Most receivers honour pct, which applies the policy to a share of failing mail, for example 25, then 50, then 100 percent. The tag is being revised in the updated DMARC specification, so keep watching reports rather than relying on it alone.
_dmarc.example.uz. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.uz"Stage 3: reject and subdomains
When reports stay clean for several weeks, publish p=reject. Use sp for subdomains; a strict policy is valuable for subdomains that never send mail, since attackers like plausible names such as billing.example.uz.
_dmarc.example.uz. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.uz"
dig +short TXT _dmarc.example.uzExample: a furniture shop in Tashkent
A Tashkent furniture shop takes orders online, staff use company mailboxes and a monthly promo newsletter goes out. After customers receive a fake "confirm your payment" email in the shop's name, it publishes p=none. Reports show four sources: mailboxes, the website, the newsletter platform and some foreign IPs. The form is moved to SMTP, DKIM is configured in the newsletter tool, and after a month the shop moves to quarantine, then to reject three weeks later. On sayt.uz hosting, the DKIM, SPF and DMARC records are all added as DNS records in the cabinet.
Common mistakes
- Publishing two DMARC records, which can cause receivers to ignore both.
- Skipping monitoring and losing legitimate mail.
- Collecting reports nobody reads, leaving
p=nonein place forever. - Adding every service to SPF and exceeding the 10-lookup limit.
Keep reviewing reports after reaching reject: every new CRM or mailing tool shows up there first.