Add a DMARC TXT record at _dmarc.yourdomain.com with a policy of p=none first, watch the reports for a few weeks, then move to p=quarantine and eventually p=reject. Skipping straight to p=reject before you know what's sending mail on your behalf is how legitimate email starts bouncing. If you're troubleshooting emails landing in spam, DMARC is usually the last piece after SPF and DKIM are already working.
What DMARC actually does
SPF and DKIM each answer a narrow question: SPF checks whether the sending IP is authorized, DKIM checks whether the message was signed with a valid key. Neither tells the receiving server what to do when a check fails, and neither ties the result back to the domain in the visible "From" address. DMARC closes both gaps. It requires alignment between the DKIM/SPF domain and the visible From domain, and it publishes a policy telling receivers what to do with mail that fails: nothing, quarantine it, or reject it outright. It also gives you reporting, so you find out who's sending mail as your domain, including services you forgot about.
Adding the record
Go to Domains, click your domain, then DNS, and add a TXT record:
- Name:
_dmarc - Type:
TXT - Value:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
The rua tag is where aggregate reports get sent daily. Use an inbox you actually check, or a dedicated address, since these reports arrive as XML attachments and most people use a parsing tool rather than reading them raw. Before adding DMARC, confirm SPF and DKIM are actually in place. For domains using our hosted email, both are configured automatically, and you can verify the DKIM TXT record under the same DNS page. If you route mail through Google Workspace or another provider, follow their SPF/DKIM setup first, since DMARC only evaluates checks that are already passing or failing on their own.
The p=none to p=reject path
p=none is monitor-only. Failing mail still gets delivered normally, but you start receiving aggregate reports showing every source sending mail as your domain, including ones that pass and ones that don't. Run this for two to four weeks minimum. This is the stage where you usually discover an old marketing tool, a CRM, or a helpdesk platform sending as your domain without proper alignment.
p=quarantine tells receivers to route failing mail to spam instead of the inbox. Move here once your reports show only expected senders passing. Start with a partial rollout using the pct tag if you want to ease into it, for example v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com, then raise pct over subsequent weeks.
p=reject tells receivers to refuse failing mail outright, no delivery at all. This is the end state for a domain you're confident about, but treat it as a one-way door in practice: once legitimate traffic depends on you being at reject, reverting a broken sender's alignment issue means bounced mail in the meantime, not spam-foldered mail. Get here only after reject-level confidence, not optimism.
Gmail and Yahoo's bulk sender rules
Since early 2024, Gmail and Yahoo require senders who send a high volume of mail to personal accounts (Google's stated threshold is around 5,000 messages a day) to have SPF, DKIM, and a DMARC record at minimum p=none, plus a one-click unsubscribe header for marketing and bulk mail. Below that volume threshold DMARC isn't strictly mandated by these rules, but both providers now weight DMARC alignment heavily in spam filtering regardless of volume, so a domain with no DMARC record at all is at a real disadvantage even sending small volumes. If you send any marketing or notification email at scale, whether through hosted email or through Google Workspace, SendGrid, Mailchimp, or similar, add DMARC now rather than waiting for a delivery problem to force the issue.
One detail that trips people up: alignment mode. The default is relaxed alignment (aspf=r; adkim=r), which allows subdomains to match the organizational domain. Strict alignment (aspf=s; adkim=s) requires an exact match, which breaks legitimately for some third-party senders unless they've specifically configured strict alignment support. Stick with relaxed unless you have a specific reason not to.
Reading the reports
Aggregate reports (the rua ones) arrive as gzipped XML, one per sending source per day roughly, from major mailbox providers. Each report lists the sending IP, the volume of mail, and whether SPF and DKIM passed and aligned. Reading raw XML isn't practical at any volume, so use a parser. Free options like dmarcian's report viewer or the open-source parsedmarc tool convert them into readable tables. What you're looking for on each pass:
- Sources you recognize (your hosting, your CRM, your email marketing tool) showing consistent pass results.
- Any unrecognized IP or service sending as your domain, which usually means either a forgotten integration or a spoofing attempt.
- Volume trends before you tighten the policy, since a spike right before a rollout is a signal to hold at the current stage a bit longer.
Forensic reports (the optional ruf tag) send per-message failure details instead of daily aggregates. Most receivers have stopped honoring ruf due to privacy concerns, so aggregate reports are what you'll actually rely on.
When to contact support
If your DMARC TXT record isn't showing up in DNS lookups after a few hours, or you're not sure whether an existing DKIM record is correctly in place before you add DMARC on top of it, open a ticket from Support → New ticket in the portal. It's real people on the other end, and they can check your domain's current DNS state directly rather than you guessing from the outside.