You usually decide to create DMARC record after something already went sideways. Spoofed mail. Gmail warnings. A vendor asking for DNS changes. Or a deliverability report that shows SPF and DKIM passing on some mail and failing on the rest. If you're still building the rest of your stack, start with our business email guide so the domain, mailbox, and DNS pieces line up from day one.
Here's the blunt version: if you create DMARC record the wrong way, nothing explodes immediately. That's what makes it dangerous. The record can exist and still be useless. Wrong host. Bad policy. Reports going nowhere. No alignment. Then spoofing keeps happening and legitimate mail still lands in spam.
This guide shows you exactly how to create DMARC record, what tags matter, what to publish at _dmarc.yourdomain.com, and when to move from monitoring to enforcement. No fluff. No generic DNS advice.
What you publish when you create DMARC record
To create DMARC record, publish a TXT record at _dmarc.yourdomain.com that starts with v=DMARC1 and includes a valid policy tag like p=none, p=quarantine, or p=reject. DMARC tells receiving servers what to do when mail claiming to be from your domain fails aligned SPF and DKIM checks.
The shortest valid example looks like this:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;That works. Barely. It's watch mode. Good for first deployment, weak for long-term protection.
A more useful starting record looks like this:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100And if you're ready to enforce:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100RFC 7489 says the v tag must be first and the p tag must be present, or receivers can ignore the policy. That's not optional. Read the source if you want the protocol details: RFC 7489.
Where to create DMARC record in DNS
When you create DMARC record, you do not publish it at the root of the domain. You publish a TXT record on the host _dmarc. For example.com, the full lookup target is _dmarc.example.com. Put it anywhere else and receivers won't use it.
This is the mistake that burns hours. People add the value at @, or they paste _dmarc.example.com into a DNS panel that expects only _dmarc. Same record. Different UI rules. Easy to get wrong.
After you create DMARC record, verify it from the command line instead of trusting the DNS panel:
dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.comYou want to see one TXT response, not two, and it should start with v=DMARC1.
If you're using TrekMail, the fastest path is to add the domain, copy the required DNS values, and verify them against live lookups in the dashboard. The relevant docs are Adding a Domain, Required DNS Records, and Checking DNS Status.
Tags to use when you create DMARC record
When you create DMARC record, most tags are optional, but a few do real work. Start with v, p, and rua. Then add alignment tags if you need tighter control. Ignore exotic settings until the basics are clean.
| Tag | Required | What it does | Practical advice |
|---|---|---|---|
v | Yes | Version identifier | Must be DMARC1 and must come first |
p | Yes | Policy for failing mail | Use none, then move to quarantine, then reject |
rua | No | Aggregate reports destination | Use it. Flying blind is dumb |
ruf | No | Failure report destination | Useful in some environments, noisy in others |
adkim | No | DKIM alignment mode | r is the default and right for most teams |
aspf | No | SPF alignment mode | r first, s only if you know why |
pct | No | Sampling percentage | Keep at 100 unless you're phasing enforcement carefully |
sp | No | Policy for subdomains | Useful if marketing or support mail lives on subdomains |
If you create DMARC record with only p=none and no rua, you are technically compliant and operationally blind. Better than nothing. Still not good.
How to choose the right policy when you create DMARC record
To create DMARC record safely, start with p=none if you do not fully control every sender using your domain. Move to p=quarantine after you review reports and fix misaligned services. Use p=reject only when you are confident unknown senders are actually unauthorized.
| Policy | What receivers do | When to use it | Main risk |
|---|---|---|---|
p=none | Monitor only | Initial rollout | Spoofed mail still gets through |
p=quarantine | Send failing mail to spam or junk | Most business domains after cleanup | Some valid edge-case mail may get spammed |
p=reject | Reject failing mail outright | Mature setup with known senders only | Misconfigured legit mail gets blocked hard |
Google's current sender guidance says bulk senders should have SPF and DKIM, and the organizational domain in the From header should align with either SPF or DKIM. Google also states that full alignment on both is the direction of travel. Source: Google's email sender guidelines FAQ.
Translation: don't treat DMARC like a checkbox. If your CRM uses your domain in the From header but signs with its own domain and sends from its own bounce domain, DMARC can still fail even when the vendor claims "authentication is enabled."
Step by step: create DMARC record the right way
If you want to create DMARC record without breaking live mail, follow a staged rollout. Inventory senders first, publish watch mode second, and enforce only after the reports stop showing surprises.
- List every service that sends as your domain. That includes Google Workspace, Microsoft 365, support tools, CRMs, forms, invoicing apps, and newsletter platforms.
- Confirm SPF is valid and DKIM is enabled for each sender. DMARC sits on top of those two checks. It does not replace them.
- Create a report mailbox such as
dmarc@yourdomain.comor route reports to a reporting service. - Create DMARC record with
p=nonefirst. - Wait for aggregate reports and review who is actually sending mail.
- Fix alignment problems. This is usually a From-domain or DKIM-domain issue, not a DMARC issue.
- Move to
p=quarantine. - Move to
p=rejectwhen the reports stay clean.
A solid starting record for most business domains in 2026 looks like this:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100If forwarding is part of your workflow, read forward domain email to Gmail. Straight forwarding breaks SPF by design. DMARC survives only if DKIM alignment still passes or the forwarding stack uses the right protocols.
Common mistakes when you create DMARC record
Most DMARC failures are not protocol failures. They are operator mistakes. Wrong host, duplicate TXT records, broken report addresses, or expecting DMARC to fix bad SPF and missing DKIM. Create DMARC record cleanly, then test it from the outside.
Here are the mistakes that show up again and again:
1. Publishing at the root instead of _dmarc.
If you create DMARC record on @, receivers won't see it.
2. Using more than one DMARC TXT record.
RFC 7489 says multiple DMARC policy records cause DMARC processing to stop. One domain. One DMARC record.
3. Adding p=reject on day one.
This is how you block your own password resets, invoices, or helpdesk replies because one forgotten service was still sending as your domain.
4. Pointing rua to a mailbox that doesn't exist.
Then you think no one is sending reports. They are. You're just not receiving them.
5. Expecting DMARC to repair forwarding.
It won't. DMARC depends on aligned SPF or DKIM. Forwarding usually breaks SPF. DKIM has to carry the load.
Example: your site sends order confirmations through one SMTP provider, support replies through another, and marketing through a third. You create DMARC record with
p=rejectbefore checking all three. One passes. Two fail. Customers stop getting mail. The DMARC record did exactly what you told it to do.
If you're still setting up the full domain from scratch, our create email with your domain guide covers the full DNS and mailbox workflow around SPF, DKIM, and DMARC together.
Old Way vs New Way: create DMARC record across many domains
The old way to create DMARC record across a fleet of domains is spreadsheets, registrar logins, and random TXT values copied from old tickets. The new way is a single dashboard, live DNS verification, and standardized records per domain so you can spot conflicts fast.
| Old Way | New Way with TrekMail |
|---|---|
| Log into each registrar and guess which DNS values are current | Use one dashboard for multi-domain email management |
| Manually compare TXT records and hope propagation is done | Run live DNS verification and see exact conflicts |
| Manage SPF, DKIM, and DMARC separately across tools | Use TrekMail's SPF/DKIM/DMARC workflow in one place |
| Pay per user even when most domains have low mailbox counts | Use flat-rate multi-domain pricing starting at $3.50/mo |
TrekMail is built for this exact operational mess: multiple domains, pooled storage, IMAP mailboxes, built-in migration, catch-all, forwarding, and either managed SMTP or your own SMTP. The Nano plan stays free for up to 10 domains with BYO SMTP. Paid plans start at $3.50/month. If you want included SMTP and a cleaner sending setup, check TrekMail pricing.
The practical win is not just that you can create DMARC record faster. It's that you can verify the whole mail stack around it without juggling five vendors and twenty browser tabs.
Final checklist before you create DMARC record and enforce it
Before you create DMARC record in enforcement mode, make sure SPF and DKIM are already working for every legitimate sender, your reporting address exists, and your DNS panel is publishing one valid TXT record at _dmarc. DMARC is the policy layer. It is not a shortcut around broken authentication.
Use this quick final check:
- One DMARC TXT record only.
- Host is
_dmarc. - Value starts with
v=DMARC1; p=.... ruapoints to a real mailbox or reporting service.- SPF is merged into one record, not split across many TXT records.
- DKIM is enabled for every sender that uses your domain in the From header.
- Command-line lookup shows the exact record you expect.
- Policy starts at
noneunless you already know every sender is aligned.
If your goal is to create DMARC record once and not babysit DNS forever, TrekMail is the cleaner operating model. One place to manage custom domains, IMAP mailboxes, DNS health, SMTP choice, and migrations. Start at trekmail.net and stop treating deliverability like a side quest.
