10 min read Alle Artikel auf Deutsch Tous les articles en français Todos os artigos em português
DMARC Setup: Record, Tags, Reports, Fixes
The short answer
To set up DMARC, first get SPF and DKIM passing for the domain in your From address. Then publish one TXT record at the host _dmarc with the value v=DMARC1; p=none; rua=mailto:an address you read. Read the aggregate reports until every legitimate sender passes with an aligned domain. Only then move the policy to p=quarantine and later to p=reject. A second DMARC record on the same host breaks the policy.
In this article
- What has to be in place before DMARC setup?
- How to set up a DMARC record, step by step
- What should my DMARC record be?
- How to add DMARC at Network Solutions or any other DNS host
- DMARC for Google Workspace
- How to view DMARC records and reports
- How to fix email DMARC failures
- Where EmailFlow OS fits with your DMARC record
- Questions people ask
What has to be in place before DMARC setup?
DMARC doesn't authenticate anything by itself. It reads the results of SPF and DKIM and asks one more question: does the domain that passed match the domain in the visible From header? The DMARC specification calls this match "alignment". A message passes DMARC if SPF passes and aligns, or if DKIM passes and aligns. It doesn't need both.
That's why the order matters. Before you publish a DMARC record, check two things for every service that sends as your domain. First, an SPF record that lists that service, all in one combined v=spf1 record. Second, a DKIM signature whose d= domain is your domain or one of its subdomains. If you're working through the whole chain, the cluster article on how DKIM, DMARC and SPF work together for cold email covers the setup order and the records a typical Workspace-plus-Brevo setup needs.
Where it doesn't work: a sending service can pass SPF for its own bounce domain without that domain matching yours. SPF passes, but it isn't aligned. In that case DMARC depends entirely on DKIM signed with your domain. If the service signs with its own domain instead, DMARC fails even though both checks show "pass".
How to set up a DMARC record, step by step
- Inventory your senders. List every system that sends mail with your domain in From: your mailbox provider, your outreach sending account, your CRM, billing, support desk. Any you miss will turn up as failures later.
- Confirm SPF and DKIM per sender. Send a test message to a mailbox you control. Open the original headers and find the Authentication-Results line. You want spf=pass or dkim=pass, with the domain shown matching your From domain.
- Create the TXT record. In your DNS provider, add a TXT record at the host _dmarc (which resolves to _dmarc.yourdomain.com) with the value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. That's the starting record the Google AI overview for this search also shows.
- Check that it resolves. Run dig TXT _dmarc.yourdomain.com +short or use a web DMARC lookup. You should see exactly one string starting with v=DMARC1.
- Collect reports. Receivers that support DMARC send aggregate XML reports to the rua address. Read them until every legitimate source shows aligned passes.
- Tighten the policy. Change p=none to p=quarantine, watch the reports, then move to p=reject once nothing legitimate fails.
Step 3 is where most DNS mistakes happen. Many DNS panels add your domain to the host field automatically. If you type the full _dmarc.yourdomain.com, you can end up with _dmarc.yourdomain.com.yourdomain.com, and receivers never find it.
What should my DMARC record be?
For a domain that hasn't had DMARC before, start in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. That tells receivers to deliver as normal and send you reports. The tags below come from the DMARC specification. Everything except v and p is optional.
| Tag | What it controls | Typical starting value |
|---|---|---|
| v | Version. Must be the first tag, exactly DMARC1. | v=DMARC1 |
| p | Policy for mail that fails DMARC on the organisational domain: none, quarantine or reject. | p=none |
| sp | Policy for subdomains. If you leave it out, subdomains inherit p. | Leave out at first |
| rua | Where aggregate (XML summary) reports go, as a mailto: URI. | rua=mailto:dmarc@yourdomain.com |
| ruf | Where failure (forensic) reports go. Many large receivers don't send these. | Optional |
| adkim | DKIM alignment mode: r (relaxed, subdomains match) or s (strict, exact match). | Leave at default relaxed |
| aspf | SPF alignment mode: r or s, same meaning as adkim. | Leave at default relaxed |
| pct | Share of failing mail the policy applies to, used for staged enforcement. | Leave out at p=none |
Strict alignment (adkim=s or aspf=s) catches people out. If your outreach tool signs DKIM with a subdomain such as mail.yourdomain.com while From says yourdomain.com, relaxed mode passes and strict mode fails. Only switch to strict if you know every signer uses the exact From domain.
How to add DMARC at Network Solutions or any other DNS host
The record is the same at every DNS host, whether that's Network Solutions, GoDaddy, Cloudflare or your registrar's own panel. Add one record of type TXT. Put _dmarc in the host or name field and your v=DMARC1 string in the value field. What changes is how each panel treats the host field, so check whether it wants just the label _dmarc or the full name. After saving, look up _dmarc.yourdomain.com from outside, not in the panel's own preview.
There's a second trap. If your domain's nameservers point somewhere other than the registrar, say to Cloudflare or a hosting company, records you add in the registrar's panel don't go live. You have to edit DNS wherever the NS records point. The GoDaddy DKIM guide for Brevo senders goes through the same nameserver mismatch for a DKIM key.
DMARC for Google Workspace
On a Google Workspace domain you publish DMARC in the same place as any other record: at your DNS host, not in the Admin console. Google's own help article on setting up DMARC (knowledge.workspace.google.com) lists SPF and DKIM as prerequisites. Workspace DKIM only signs once you've generated the key, published the google._domainkey TXT record and turned authentication on in the Admin console. Until then, Workspace mail can pass SPF but carries no aligned DKIM signature.
If you also send through Brevo from the same domain, Brevo needs its own DKIM record next to Google's. Both signatures can align with the same From domain, and one DMARC record covers both. The Google Workspace DMARC rollout guide covers the record and the move from p=none, and the G Suite DKIM setup steps cover the key activation that people often skip.
How to view DMARC records and reports
"Viewing DMARC" can mean two things: checking the published record, or reading the reports receivers send back. Each needs a different kind of tool. The table compares the realistic options by the same two questions: what it shows and where it stops.
| Option | What it shows | Where it stops |
|---|---|---|
| dig or nslookup (command line) | The raw TXT string at _dmarc, straight from DNS. Shows duplicates and typos. | Reads the record only. No reports, no explanation of the tags. |
| MXToolbox DMARC lookup (web) | The published record with its tags parsed. MXToolbox is among the sources Google's AI overview cites for this search. | A record check. Aggregate reports still arrive as XML in your rua mailbox. |
| Message headers in Gmail or Outlook (Show original / View source) | The Authentication-Results line for one message: dmarc=pass or fail, plus the SPF and DKIM domains. | One message at a time. It doesn't show mail other people sent pretending to be you. |
| DMARC report services such as Sendmarc, dmarcly or PowerDMARC | Collected aggregate reports by sending source. Sendmarc's ranking page, for example, describes guided record creation and monitoring. | A separate service to run. You point rua at an address it gives you, which means another domain receives your reports. |
If rua points to a mailbox on a different domain, the DMARC specification requires that domain to publish an authorisation record at yourdomain.com._report._dmarc.reportdomain.com. Report services set this up on their side. If you send reports to your own second domain, you have to publish it yourself. Otherwise receivers can quietly drop the reports.
How to fix email DMARC failures
Start with the Authentication-Results header of a failing message. It tells you which check failed and for which domain. Most failures come from one of these causes:
- Two DMARC records on _dmarc. The DMARC specification tells receivers to stop DMARC processing when they find more than one, so your domain effectively has no policy. Merge them into one.
- Syntax errors. v=DMARC1 isn't first, a semicolon is missing, or the rua lacks mailto:. Receivers ignore a record they can't parse.
- DKIM signed with the vendor's domain. The d= value in the DKIM-Signature header isn't your domain. Fix it by adding the vendor's DKIM record for your own domain.
- SPF passes but doesn't align. The Return-Path belongs to the sending service. Make sure DKIM aligns instead, or set up a custom bounce domain if the service offers one.
- Forwarding and mailing lists. Forwarding breaks SPF, and lists that rewrite the subject or footer break DKIM. These failures show up in reports. They aren't errors in your own setup.
- Policy tightened too early. A forgotten sender, such as invoices from your accounting tool, gets quarantined after a move to p=quarantine. Go back to p=none, add that sender's SPF and DKIM, then tighten again.
DMARC tells receivers how to treat mail that fails. It doesn't decide where passing mail lands. That depends on the receiving server's view of your domain and how you send. The guide on how sender reputation is checked, built and fixed picks up from there.
Where EmailFlow OS fits with your DMARC record
EmailFlow OS is a product for personalised AI video email in B2B cold outreach. You record one video, upload it to EmailFlow OS, connect your Brevo account and sending domain, and import your prospect list into EmailFlow OS. EmailFlow OS then makes a personalised version of that single recording for each recipient, not each company. Every version goes out from your own inbox, through your own Brevo account and on your own sending domain. There's no shared platform sender.
For DMARC, that means the record that applies is the one you publish at _dmarc on your own domain. The DKIM signature you set up in Brevo for that domain is the one that has to align, and the aggregate reports go to your rua address. Nothing in the DMARC steps above changes. You do the setup once for the domain you already control. How the sending works is described on the EmailFlow OS personalised video outreach page.
Questions people ask
- How long does a DMARC record take to work?
- It works as soon as receivers can resolve it. How quickly that happens depends on the TTL of the record and any cached negative answers at the resolvers. The first aggregate reports come later, because receivers send summaries for a reporting interval rather than one report per message. The optional ri tag lets you request an interval, but receivers decide how often they actually send.
- Is p=none a valid DMARC policy?
- Yes. p=none is a valid policy in the DMARC specification. It asks receivers to apply no DMARC-based action and to send reports. It's monitoring mode: you can see who sends as your domain, but spoofed mail isn't quarantined or rejected because of DMARC. Use it to find all your legitimate senders before moving to p=quarantine or p=reject.
- Do I need a separate DMARC record for each sending service?
- No. One domain has exactly one DMARC record, at _dmarc. It covers every service that sends with that domain in the From header. Each service needs its own SPF include and its own DKIM key. A second v=DMARC1 record on the same host doesn't add coverage. It makes receivers stop DMARC processing for the domain.
- What is the difference between rua and ruf in DMARC?
- rua sets where aggregate reports go: XML summaries per sending IP, with message counts and SPF, DKIM and DMARC results. ruf sets where failure reports go: copies or extracts of individual failing messages. Aggregate reports are the ones you use to roll out DMARC. Many large mailbox providers don't send failure reports at all.