A dmarc record example is just a DNS TXT record that tells receiving servers what to do when SPF or DKIM fail alignment for mail sent from your domain. If that sounds abstract, here’s the practical version: publish the wrong record and spoofed mail gets through, real mail lands in spam, or Gmail starts rate-limiting you. If you still need the wider setup, start with this guide to business email and this walkthrough on create email with your domain.
The fix is simple once you know the parts. Put one valid DMARC TXT record at _dmarc.yourdomain.com, start with monitoring if you’re not sure what’s sending mail, then move to quarantine or reject when your senders are clean. TrekMail’s required DNS records guide shows the base DNS layout, but this article goes deeper on which dmarc record example to use and when.
What a dmarc record example actually does
A good dmarc record example tells receivers three things: that the record is DMARC, what policy to apply to failing mail, and where to send reports. DMARC sits on top of SPF and DKIM. It does not replace them. It decides whether their results are aligned with your visible From domain.
Here’s the shortest working record for a domain that wants reports but no enforcement yet:
Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.comBreak it down:
v=DMARC1identifies the record as DMARC.p=nonemeans monitor only. Don’t quarantine or reject yet.rua=mailto:dmarc@example.comasks receivers to send aggregate XML reports.
That’s the core. Everything else is tuning.
Think of DMARC as policy, not proof. SPF and DKIM provide the proof. DMARC decides whether that proof matches the domain your users actually see in the From header.
5 working dmarc record example templates
Most searches for dmarc record example stop at one generic string. That’s not enough. The right record depends on whether you’re monitoring, rolling out enforcement, protecting subdomains, or tightening alignment for high-risk traffic.
Monitoring only. Use this when you’re still discovering vendors and forwarded traffic.
v=DMARC1; p=none; rua=mailto:dmarc@example.comQuarantine suspicious mail. Good middle ground for most teams.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comReject failures. Best for mature setups with known senders.
v=DMARC1; p=reject; rua=mailto:dmarc@example.comGradual rollout. Use percentage sampling if you want to move slower.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comSubdomain control with strict alignment. Useful when parent and subdomain traffic need different treatment.
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com
| Policy | Best for | Main upside | Main risk |
|---|---|---|---|
p=none | Discovery phase | Zero disruption | Does not block spoofing |
p=quarantine | Most SMBs | Pushes failures to spam | Can surface misaligned apps fast |
p=reject | Clean production setup | Strongest anti-spoofing | Bad config breaks real mail |
pct=25 | Careful rollout | Lower blast radius | Slower enforcement |
adkim=s; aspf=s | High-control environments | Tighter identity match | Fails more third-party mail |
If you want one answer fast, the safest starting dmarc record example for most domains is:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comIt gives you real enforcement without going straight to hard rejection.
How to publish a dmarc record example in DNS
To publish a dmarc record example, create a TXT record on the host _dmarc, paste the value exactly once, then verify it from the command line. The two mistakes that waste the most time are publishing it at the root instead of _dmarc and accidentally creating two DMARC TXT records.
Use this pattern in your DNS panel:
Host: _dmarc
Type: TXT
TTL: 3600
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comThen verify it:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comIf the response shows one TXT value with v=DMARC1 at the start, you’re in business.
Per RFC 7489, DMARC processing stops if receivers find multiple DMARC records or none at all. That one rule causes a lot of fake mystery outages. Another easy trap is using your mailbox provider’s DNS formatting blindly. Some UIs want only _dmarc. Others want the full host. Double-check before saving.
If you’re building the full DNS stack, TrekMail’s docs on required DNS records cover MX, SPF, DKIM, and DMARC together.
Common dmarc record example mistakes that break mail
A broken dmarc record example usually fails in predictable ways: wrong host, duplicate records, bad report mailbox, strict alignment before you’re ready, or confusing SPF forwarding failures with real DMARC failures. Most of these are operator mistakes, not protocol mysteries.
Here are the big ones:
- Publishing DMARC at the root domain. The host must be
_dmarc, not@. - Creating two DMARC TXT records. One domain, one DMARC policy record.
- Using
p=rejectbefore inventory is clean. That’s how forgotten CRMs and billing tools stop sending overnight. - Blaming DMARC for forwarding. Forwarding often breaks SPF. DKIM is what saves you there. TrekMail’s guides on forward domain email to Gmail and email alias forwarding cover the mechanics.
- Ignoring alignment. SPF can pass and DMARC can still fail if the authenticated domain does not align with the visible From domain.
- Skipping reports. No
ruameans less visibility when something goes sideways.
Google’s current sender guidance is blunt: missing DMARC policy and failed alignment can trigger rate limits for mail sent to Gmail accounts. See the official Email sender guidelines FAQ. If you send business mail at any volume, DMARC is not optional busywork anymore.
Best dmarc record example for TrekMail setups
The best dmarc record example for TrekMail depends on how you send mail. If you use Managed SMTP on a paid plan, TrekMail handles the authentication path cleanly. If you use BYO SMTP, you need to authorize that provider in SPF and verify DKIM alignment yourself.
Here’s the old way vs new way:
| Setup | Old way | New way |
|---|---|---|
| Managed sending | Patch together mailbox hosting and a separate SMTP vendor | Use TrekMail Managed SMTP so SPF and DKIM stay aligned by default |
| BYO SMTP | Guess which provider record matters and debug after failures | Use TrekMail as the mailbox layer, then add the exact SMTP provider SPF include and DKIM config up front |
| Multi-domain ops | Edit each domain manually and hope nothing drifts | Standardize DNS templates and monitor reports domain by domain |
TrekMail’s docs are explicit on this point. With Managed TrekMail SMTP, paid plans include SMTP and TrekMail keeps SPF and DKIM aligned for deliverability. With Bring Your Own SMTP, your SPF record must authorize the external provider, and DMARC may still depend on DKIM if SPF alignment breaks.
That matters because a TrekMail mailbox setup and a sending setup are not always the same thing. If your app sends through SES, SendGrid, or Mailgun, your dmarc record example can be perfect and you can still fail DMARC if SPF or DKIM are misaligned upstream.
For TrekMail customers, the practical recommendation is simple:
- If you want the lowest-friction path, use Managed SMTP on a paid plan.
- If you need external sending control, use BYO SMTP and treat SPF, DKIM, and DMARC as one change set.
- If you manage lots of domains, standardize one reporting mailbox pattern and one rollout policy.
TrekMail starts at $3.50 per month on Starter. Paid plans have a 14-day free trial, and the Nano plan stays free with no card required. If you want flat-rate multi-domain hosting with pooled storage and built-in IMAP migration, check TrekMail pricing.
Recommended dmarc record example rollout for 2026
The right dmarc record example rollout in 2026 is staged, not reckless. Start with visibility, confirm every sender, then tighten policy. Going straight to reject feels decisive, but it’s usually just a faster way to discover forgotten systems in production.
- Publish monitoring first.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - Watch reports for 7 to 14 days. Identify every legitimate sender, including invoicing tools, CRMs, ticketing systems, and forwarded flows.
- Fix SPF and DKIM alignment for each sender. If a vendor can’t align, don’t guess. Replace them or isolate them.
- Move to quarantine.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - When reports are clean, move to reject.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
If you run agencies, client portfolios, or many parked brands, this staged approach scales better than heroic one-off fixes. It also fits the way TrekMail is built: one dashboard, multi-domain control, flat pricing, pooled storage, and server-side IMAP migration instead of mailbox-by-mailbox chaos.
The short answer is this: the best dmarc record example is the one that matches your actual senders today and your enforcement goal tomorrow. Start with reports. Fix alignment. Then quarantine or reject. That’s how you stop spoofing without taking down your own mail.
If you want a sane operating model behind the DNS records, TrekMail gives you the mailbox layer, DNS guidance, Managed SMTP or BYO SMTP, and the multi-domain control surface most teams are missing. See trekmail.net if you want the infrastructure without the per-user tax.
