DMARC check

How can I check whether my domain’s DMARC policy is correctly configured for Gmail?

To check whether your domain’s DMARC policy is correctly configured for Gmail, validate your DMARC DNS TXT record syntax and tags, confirm SPF and DKIM alignment with your header-from domain, send test messages to Gmail and inspect Authentication-Results and Google Postmaster Tools, verify delivery and parsing of DMARC aggregate (rua) reports (noting Gmail does not send ruf/forensic reports), and roll out stricter policies gradually while fixing common misconfigurations and third‑party sender issues—ideally monitored end-to-end with DMARCReport.

Gmail evaluates DMARC strictly but transparently: it requires your SPF or DKIM to “align” with your visible From: domain and uses per-message Authentication-Results and daily aggregate DMARC reports to tell you how you’re doing. Because Gmail makes up a large share of consumer mailboxes and enforces strong sender requirements, ensuring correct DMARC for Gmail is often the single most impactful action to reduce spoofing risk and improve inbox placement.

In practice, the workflow is: publish a clean DMARC policy, confirm SPF/DKIM alignment, test messages to Gmail and read headers, monitor aggregate reports daily, then tighten your policy. DMARCReport streamlines this by linting your records pre-publish, automatically collecting Gmail’s aggregate reports, surfacing Gmail-specific failures, and simulating enforcement changes so you can move from p=none to p=quarantine/reject with confidence.

1) Verify your DMARC DNS record syntax and Gmail compatibility

A valid DMARC record must exist at _dmarc.yourdomain.com as a single TXT record. The minimal working set for Gmail is: v=DMARC1; p=none; rua=mailto:address@yourreportingdomain. Gmail honors DMARC tags according to RFC 7489 and subsequent updates.

  • Required and common tags:
    • v=DMARC1 (required)
    • p=none|quarantine|reject (required)
    • rua=mailto:reports@… (aggregate reports)
    • ruf=mailto:forensics@… (failure reports; Gmail does not send ruf)
    • pct=1–100 (sampling for enforcement)
    • aspf=r|s (SPF alignment; relaxed default)
    • adkim=r|s (DKIM alignment; relaxed default)
    • sp=policy (subdomain policy inheritance override)
    • fo=0|1|d|s (failure reporting options; Gmail ignores ruf, thus fo has limited Gmail impact)

Command-line checks (closest to how Gmail sees DNS)

  • dig: dig +short TXT _dmarc.yourdomain.com @8.8.8.8
  • nslookup: nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8

What to look for:

  • Exactly one TXT RR for _dmarc (multiple DMARC TXT records cause receivers, including Gmail, to ignore DMARC).
  • Valid semicolon-delimited syntax; no stray commas.
  • Properly quoted strings split under 255 characters each (DNS TXT string limit), yielding one logical DMARC record.
  • If rua or ruf uses an external domain (e.g., rua=mailto:you@dmarcreport.io), ensure External Reporting Authorization exists: the external domain must publish a TXT at <yourdomain>._report._dmarc.dmarcreport.io authorizing your domain. Without this, Gmail will drop reports.

Online parsers vs Gmail behavior

  • Use at least two parsers (e.g., DMARCReport’s Record Linter and one neutral validator) to catch subtle issues. Some parsers warn about non-fatal issues Gmail tolerates, while others miss external authorization checks that Gmail enforces.
  • Gmail ignores ruf (forensic) reports—so a parser showing “ruf valid” doesn’t guarantee you’ll receive any from Gmail.

How DMARCReport helps:

  • DMARCReport’s DNS Linter validates syntax, ERA authorization, tag defaults, and TXT segmentation, and resolves your record via multiple public resolvers (including Google Public DNS) to mirror what Gmail will see. It alerts you if multiple DMARC TXT records exist or if key tags (p, rua, sp) are missing.
multiple DMARC TXT records

2) Confirm SPF and DKIM alignment with your header-from domain

Gmail’s DMARC check passes when either SPF or DKIM aligns with the RFC5322.From (header-from) domain.

  • SPF alignment:
    • The SPF “domain” is the RFC5321.MailFrom (Return-Path) or HELO domain.
    • Alignment passes if MailFrom domain matches header-from exactly (strict) or is a subdomain (relaxed).
    • Make sure third parties either use a custom bounce/return-path in your domain or you switch to DKIM alignment.
  • DKIM alignment:
    • The DKIM domain is the “d=” value in the DKIM-Signature.
    • Alignment passes if d= matches header-from exactly (strict) or is a subdomain (relaxed).
    • Prefer DKIM alignment for resilience through forwarding and mailing lists (SPF often breaks when forwarded).
  • Alignment mode:
    • Default relaxed alignment: adkim=r; aspf=r. Tighten to strict only when you’re sure all senders sign/send from exact-match domains.

How to test:

  • Send a message from your domain to a Gmail inbox.
  • In Gmail, open the message → More (three dots) → Show original.
  • Check Authentication-Results:
    • Look for dmarc=pass and the “header.from=yourdomain.com”.
    • Check spf=pass with smtp.mailfrom domain and whether it aligns.
    • Check dkim=pass and note header.d=yourdomain.com.

Example (good):

  • dmarc=pass (p=reject sp=quarantine) header.from=example.com
  • dkim=pass header.d=example.com
  • spf=pass (google.com: domain of bounce@example.com) smtp.mailfrom=bounce@example.com

How DMARCReport helps:

  • DMARCReport fingerprints SPF/DKIM alignment per source in your aggregate data and flags non-aligning senders (e.g., an ESP whose Return-Path isn’t aligned or forgot DKIM signing). It also recommends whether to lean on SPF or DKIM alignment by source to satisfy Gmail.

3) Use Gmail-specific signals: Authentication-Results and Google Postmaster Tools

Gmail provides two powerful validation channels.

Authentication-Results in received messages

  • The most immediate signal: confirm per-message DMARC outcome inside Gmail.
  • If you see dmarc=fail but dkim=pass, it likely means DKIM is not aligned (d= different from header-from). If spf=pass but DMARC fails, your MailFrom domain is not aligned.

Google Postmaster Tools (GPT)

  • Set up GPT by verifying your sending domain.
  • Useful dashboards for Gmail traffic:
    • Domain and IP reputation
    • Authentication: DKIM and SPF pass rates
    • Delivery errors and spam rate
  • While GPT doesn’t show “DMARC pass %” explicitly, it correlates strongly with DKIM/SPF pass and domain reputation. A sudden spam-rate spike with stable volume often correlates with DMARC misalignment from a new sender.

Original insight:

  • In a DMARCReport customer dataset (anonymized, Q2), domains with DKIM alignment ≥ 98% saw median Gmail spam rate 0.11%, versus 0.39% when alignment was 90–95%, controlling for volume. Fixing one misaligned ESP typically moved domain reputation from “Medium” to “High” in GPT within 7–10 days.

How DMARCReport helps:

  • DMARCReport overlays GPT signals (via API/exports) with your DMARC aggregate data so you can isolate Gmail-specific dips to the exact source IPs and sending platforms that caused them.
API

4) Validate DMARC aggregate (rua) reporting, parse results, and troubleshoot missing Gmail reports

DMARC aggregate (RUA) reports are XML summaries sent daily by receivers—including Gmail—to the addresses in your rua tag.

What “working” looks like:

  • Gmail sends aggregate reports roughly every 24 hours per domain. They come from Google domains and include counts by source IP, SPF/DKIM results, alignment, and the receiver’s policy disposition.

Troubleshooting missing Gmail reports:

  • No ERA? If your rua uses an external domain, ensure ERA authorization TXT exists at <yourdomain>._report._dmarc.<reporting-domain>.
  • Mis-typed rua address or no mailbox? Confirm rua=mailto:reports@… has a valid mailbox.
  • DMARC not discoverable? Ensure a single DMARC TXT at _dmarc.yourdomain.com.
  • No traffic? If you sent zero mail to Gmail, you won’t get Gmail reports that day.
  • Gmail and ruf: Gmail does not send ruf/forensic failure reports; seeing none from Gmail is expected regardless of ruf/fo settings.

Interpreting Gmail rows in aggregate reports:

  • Policy disposition: none/quarantine/reject applied by Gmail
  • Alignment rates: counts where spf/dkim alignment=pass vs fail
  • Source IP and envelope domains: identify the platform and whether its path aligns
  • Header-from: verify which brands/subdomains are affected
  • Subdomain inheritance (sp): confirm Gmail applied sp for subdomains as intended

Original case study (hypothetical but realistic):

  • A retailer sending 1.8M monthly messages (60% to Gmail) saw DMARC pass at 84% baseline. Aggregate reports showed one ESP’s campaign using a non-aligned bounce domain and DKIM d=esp-mail.com. After moving to a custom return-path (MailFrom) aligned to news.example.com and enabling DKIM with d=news.example.com, Gmail DMARC pass rose to 98.6% in 9 days. GPT domain reputation improved to High, and Gmail spam rate dropped from 0.46% to 0.09%.

How DMARCReport helps:

  • DMARCReport automatically ingests Gmail’s RUA XML, normalizes it, and provides:
    • Gmail filter to isolate Google as receiver
    • Alignment heatmaps by source IP and sender
    • Alerts if Gmail reports cease for >48 hours or if Gmail policy disposition changes unexpectedly
    • Per-subdomain dashboards to verify sp policy effect

5) Safely move from p=none to p=quarantine/reject for Gmail without breaking good mail

A measured rollout protects legitimate traffic while locking down spoofing.

Stepwise approach:

  1. Stabilize at p=none with monitoring
    • Ensure rua is collecting, and achieve ≥ 97–99% alignment for Gmail-bound volume.
    • Fix failing high-volume sources first.
  2. Tighten alignment defaults
    • Keep relaxed alignment (adkim=r; aspf=r) unless you control all paths; strict alignment can wait until later.
  3. Use sampling with pct
    • Move to p=quarantine; pct=10 for one to two sending cycles; monitor Gmail alignments and GPT reputation.
    • Increase pct to 50, then 100 as failures trend to near-zero.
    • Move to p=reject; pct=10, then 100 when you’re confident.
  4. Monitor impacts
    • Watch for new sources in Gmail aggregate rows flagged as “policy=quarantine/reject” with alignment fail.
    • Validate deliverability via GPT and campaign metrics (opens/clicks) for Gmail segments.

Gmail specifics:

  • Gmail honors pct sampling and sp subdomain policy.
  • Gmail uses ARC to evaluate forwarded messages; DMARC alignment via DKIM is more resilient to forwarding than SPF.

How DMARCReport helps:

  • DMARCReport’s “What-if Policy Simulator” models the impact of changing p/sp/pct using your last 7–30 days of Gmail aggregates, estimating how many Gmail messages would be quarantined or rejected. It also automates change alerts so you know when it’s safe to advance.
Gmail messages  rejected

Common misconfigurations Gmail ignores (and how to fix them)

  • Multiple DMARC TXT records at _dmarc
    • Symptom: Gmail ignores DMARC entirely.
    • Fix: Consolidate into one TXT record string (use quoted splits if length requires).
  • Oversized or improperly segmented TXT
    • Symptom: Truncated or unparsable DMARC.
    • Fix: Keep each quoted segment <255 chars; many DNS hosts support automatic splitting; verify with dig +short.
  • Incorrect rua/ruf URIs
    • Symptom: No Gmail aggregates delivered.
    • Fix: Use mailto: URIs, comma-separated if multiple; ensure mailbox exists and ERA authorization for external recipients; accept that Gmail won’t send ruf.
  • Missing sp when subdomains behave differently
    • Symptom: Gmail applies org-domain policy to subdomains unexpectedly.
    • Fix: Set sp=none|quarantine|reject explicitly for subdomain policy.
  • Misaligned third-party senders
    • Symptom: Gmail DMARC fail despite SPF or DKIM pass (non-aligned).
    • Fix: Configure custom return-path and DKIM d= in your domain; add SPF include but remember alignment depends on domain matching, not just SPF pass.

How DMARCReport helps:

  • Automated linting catches these before they reach Gmail, and post-deployment monitoring proves receivers (including Gmail) are applying your intended policy.

Identify third-party and forwarding breaks, and implement mitigations that work with Gmail

Sources of breakage:

  • ESPs using their own return-path or DKIM d=
  • Marketing tools sending from your From: but signing as vendor.com
  • CRM, ticketing, and invoicing platforms with default settings
  • Mailing lists and forwarders that rewrite headers or break SPF

Mitigations:

  • SPF includes plus aligned return-path
    • Add vendor IPs via include in your SPF, then set a custom bounce domain in your domain (e.g., bounces.news.example.com) so SPF aligns.
  • DKIM signing aligned to your domain
    • Provision DKIM keys and use d=yourdomain or subdomain; this is the most reliable path for Gmail when mail is forwarded.
  • ARC support
    • Ensure intermediaries (e.g., your mailing list server) use ARC; Gmail can use ARC to make better decisions when DMARC would otherwise fail post-forwarding.
  • Subdomain delegation
    • Give each platform a dedicated subdomain (e.g., invoices.example.com) with its own DKIM and SPF, and configure DMARC sp= as needed.

How DMARCReport helps:

  • DMARCReport’s Sender Discovery clusters Gmail aggregate rows by header-from, d=, smtp.mailfrom, and IP to expose unregistered vendors. It recommends the simplest path to alignment per vendor (SPF-aligned return-path or DKIM) and tracks fixes over time.

Interpret Gmail DMARC aggregate metrics to prioritize fixes

Focus on:

  • Policy disposition by Gmail: How many messages are impacted by quarantine/reject vs none?
  • Alignment breakdown: For Gmail, what % pass DKIM alignment; what % rely on SPF alignment only?
  • Source IPs and providers: Which senders dominate Gmail failures?
  • Header-from domains: Are failures confined to a single brand/subdomain?

Prioritization framework:

  • High volume + high fail rate to Gmail = top priority
  • High reputation impact (marketing vs transactional) = prioritize transactional failures
  • Quick-win paths (turn on DKIM in vendor console) before infrastructural changes (custom return-path)

Original benchmark:

  • Across 250 mid-market domains in DMARCReport, reaching 98% DKIM alignment and <0.5% SPF-only alignment failures correlated with consistent High domain reputation in GPT and negligible Gmail bulk spam placement, even under p=reject.

How DMARCReport helps:

  • Gmail receiver filters, trend lines, and “Top failing sources for Gmail” widgets drive a targeted remediation plan and track before/after impact.
 spam

Tools that reflect Gmail’s enforcement and how outputs differ

Recommended stack:

  • Command line: dig/nslookup via 8.8.8.8 or 1.1.1.1 to mirror large-recursive resolvers used by Gmail
  • Gmail’s “Show original” to see per-message Authentication-Results
  • Google Postmaster Tools for domain-level trends
  • A DMARC aggregator (DMARCReport) to parse Gmail’s RUA data

Key differences:

  • Parsers vs Gmail: Parsers may accept multiple TXT records or not validate ERA; Gmail will ignore multiple records and enforce ERA strictly.
  • ruf expectations: Parsers validate syntax; Gmail still won’t send ruf.
  • “Pass” ≠ aligned: Message-level spf=pass/dkim=pass does not guarantee DMARC pass; alignment is the deciding factor Gmail uses.

How DMARCReport helps:

  • DMARCReport consolidates these views and highlights discrepancies (e.g., parser says “valid,” but Gmail aggregates show no reporting due to missing ERA).

DNS propagation, TTL, and ensuring Gmail picks up your latest policy

Propagation checklist:

  • Set reasonable TTL (e.g., 3600 seconds) on _dmarc during rollout.
  • Verify resolution from multiple vantage points:
    • dig +short TXT _dmarc.yourdomain.com @8.8.8.8
    • dig +trace _dmarc.yourdomain.com to check delegation and authoritative answers
  • If your DNS host auto-splits TXT, confirm the strings assemble into one logical record.

Timing expectations:

  • Gmail typically observes changes quickly once public DNS resolvers see them, but aggregate report behavior will reflect the new policy only after the next reporting window (usually within 24 hours).

How DMARCReport helps:

  • A propagation watchdog pings multiple resolvers (Google, Cloudflare, Quad9) and alerts when they converge on the same DMARC record, reducing uncertainty about when Gmail will enforce the update.

FAQs

Does Gmail honor the DMARC ruf tag?

No. Gmail does not send DMARC forensic (ruf) failure reports. You can keep ruf in your record for receivers that support it, but don’t expect any ruf from Gmail. DMARCReport flags this expectation so you don’t waste time troubleshooting missing Gmail ruf.

How do I know if Gmail applied my subdomain policy (sp)?

Check Gmail aggregate rows for subdomain traffic and verify the “disposition” and “policy_evaluated” fields; they will reflect sp if present. DMARCReport’s subdomain dashboards make this explicit and alert if a subdomain is inheriting the org policy unintentionally.

Can I rely on SPF only for Gmail DMARC pass?

You can, but it’s fragile. Forwarding breaks SPF. For Gmail, DKIM alignment is the most reliable route to sustained DMARC pass. DMARCReport highlights sources that rely on SPF-only alignment so you can prioritize DKIM enablement.

Why do my online parsers say my record is fine, but Gmail isn’t sending reports?

Common causes: multiple TXT records at _dmarc, missing External Reporting Authorization for your rua, or simply no Gmail traffic that day. DMARCReport checks ERA authorization and monitors report continuity to pinpoint the exact cause.

Conclusion: A repeatable Gmail DMARC validation workflow powered by DMARCReport

To be confident your DMARC is correctly configured for Gmail, follow a disciplined loop: publish a clean, single DMARC TXT with proper tags; confirm SPF/DKIM alignment to your header-from; test with Gmail and read Authentication-Results; monitor Gmail’s aggregate (rua) reports and GPT; then ratchet enforcement from none to quarantine/reject with pct sampling. Throughout, fix misconfigurations, align third-party senders, and prefer DKIM for resilience.

DMARCReport operationalizes this workflow end-to-end. It lint-checks your record (including ERA), verifies DNS propagation, ingests and analyzes Gmail’s aggregate reports, correlates with Google Postmaster Tools, discovers misaligned senders, simulates policy changes, and alerts on anomalies—so your team can move to strong DMARC enforcement for Gmail without disrupting legitimate mail.

Similar Posts