Last updated: July 2026

In short: After this guide your domain publishes a DMARC record that tells receiving servers what to do with unauthenticated mail — and shows you via reports who sends in your name.

Prerequisites

  • A Google Workspace account with your own domain
  • SPF and DKIM must be set up first — DMARC builds on both
  • Access to your domain’s DNS management (at the domain host)

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) combines SPF and DKIM into an enforceable policy. It’s a TXT record under the subdomain _dmarc. In it you define what a recipient should do with mail that fails the check (the p policy), and where it sends you reports (the rua address).

For bulk senders, DMARC is now mandatory at Google — together with SPF and DKIM. The reports are the clever part: via rua you get daily aggregated reports on which servers send in your name.

The starting point at Google Workspace

As with SPF and DKIM: there’s nothing to do for DMARC in the Google Admin console. The record is created at the domain host — Google says so itself: “Then sign in to your domain host and add the DMARC record …”. Where exactly is shown in our host guides, e.g. IONOS, Strato, or Netcup.

The safe path: none → quarantine → reject

You don’t switch DMARC to enforcing right away — Google too recommends starting with p=none and raising the policy “over time” to quarantine or reject:

  1. p=none — observe, block nothing. Mail is logged in the daily report.
  2. p=quarantine — suspicious mail lands in spam.
  3. p=reject — unauthenticated mail is rejected: “The message is rejected.”

Step-by-step guide

1. Set up a mailbox for reports

Create a mailbox or group that receives the aggregated rua reports (e.g. dmarc@beispiel.de). For analysis, a DMARC monitor like MARCo is worthwhile — it makes the daily XML reports readable and shows you which sources aren’t yet cleanly authenticated.

2. Start with p=none

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

v and p must come first — the remaining tags in any order. rua is optional according to Google, but “Google recommends always including it in your DMARC record”.

3. Create the DMARC entry at the domain host

At your domain’s DNS provider, create a TXT record on the host _dmarc, with your DMARC value.

4. Analyze reports, then tighten — with pct

After one or two weeks the reports show whether all sources are clean. Then tighten in stages. Google recommends using the pct tag during rollout (a whole number between 1 and 100). Google’s recommended target record with strict alignment:

v=DMARC1; p=reject; rua=mailto:postmaster@beispiel.de, mailto:dmarc@beispiel.de; pct=100; adkim=s; aspf=s

5. Wait until the change is live

DNS changes take time — a few hours depending on caching.

The most important tags

TagMeaning
v=DMARC1version, must be at the start
p=policy: none (observe), quarantine (spam), reject (reject)
pct=percentage of mail the policy is applied to (1–100)
rua=address for aggregated status reports
sp=separate policy for subdomains
adkim= / aspf=alignment (r relaxed, s strict) for DKIM and SPF respectively

Keep an eye on BIMI

If you later want to use BIMI (your logo in Gmail), that has consequences for DMARC: “BIMI doesn’t support DMARC policies where the p option is set to none” — and pct must then be 100. So BIMI requires DMARC enforcement.

Verify the result

Check your configuration with the free MXAudit scanner — it shows you the DMARC policy, SPF, and DKIM at a glance.

Common mistakes

Straight to p=reject. Without a prior none phase you almost certainly block legitimate sources. Always start with p=none and read the reports — Google recommends this too.

Looked for the record in the Admin console. DMARC is pure DNS — the record belongs at the domain host, not in the Google Admin console.

No rua set. Without a report address you’re flying blind. rua belongs in from the start.

DMARC without SPF/DKIM. DMARC checks the results of SPF and DKIM. First SPF and DKIM, then DMARC.

Further reading