How can I create a DMARC record for my domain to stop email spoofing?

To stop email spoofing, create and publish a TXT record at _dmarc.yourdomain.com with a value like v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; adkim=s; aspf=s; pct=100; fo=1; ri=86400 only after verifying that all your senders pass SPF and/or DKIM in alignment with your From domain.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) lets domain owners tell receivers how to handle emails that fail authentication and alignment, and it provides feedback loops (reports) to help you refine your configuration. In practice, “stopping spoofing” is achieved when the majority of legitimate streams align via SPF or DKIM, and the domain’s DMARC policy is elevated to quarantine or reject—making it hard for attackers to impersonate your From address successfully.

Using a product like DMARCReport speeds this journey: it generates a correct DMARC record, detects every sending source observed across your traffic, flags alignment gaps by provider, parses aggregate and forensic reports into clear dashboards, and guides safe policy escalation with thresholds, alerts, and subdomain simulations. The sections below walk you through what to publish, how to align SPF/DKIM across multiple services, where to publish it in DNS, how to test and monitor, and how to troubleshoot edge cases—while tying each step back to DMARCReport.

DMARC Record Anatomy: Required and Optional Tags

A DMARC record is a semicolon-separated list of tags in a TXT record at _dmarc.yourdomain.com.

Required tags (must be present)

• v: Version. Valid value: DMARC1
• p: Policy for the organizational domain. Values: none, quarantine, reject

Recommended optional tags and valid values

• rua: Aggregate report URIs (mailto:). Example: rua=mailto:dmarc@yourdomain.com,mailto:reports@vendor.tld
• ruf: Forensic/Failure report URIs (mailto:). Example: ruf=mailto:forensics@yourdomain.com
• pct: Percentage of messages to which policy applies (0–100). Default 100
• fo: Failure reporting options: 0 (any fail), 1 (DKIM or SPF fail), d (DKIM fail), s (SPF fail). Common: fo=1
• adkim: DKIM alignment mode: r (relaxed, default) or s (strict)
• aspf: SPF alignment mode: r (relaxed, default) or s (strict)
• sp: Subdomain policy (overrides p for subdomains). Values: none, quarantine, reject
• ri: Aggregate report interval in seconds (default 86400). Example: ri=86400

Example records

• Initial monitoring: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; ri=86400
• Controlled rollout: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r
• Full enforcement: v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; adkim=s; aspf=s; fo=1

How DMARCReport helps: Use DMARCReport’s Record Generator to compose, lint, and simulate these tags against your current traffic; it validates URIs, detects duplicates/multiple records, and previews receiver behavior by source.

Aligning Multiple Senders (Google Workspace, Mailchimp, Salesforce, etc.) and Ensuring SPF/DKIM Alignment

When multiple services send on your behalf, each must pass SPF or DKIM in alignment with your visible From domain (organizationally aligned by default, strictly aligned if adkim/aspf=s).

Alignment checklist by provider

• Google Workspace:
  • SPF: include:_spf.google.com in your SPF; alignment usually passes because Envelope From can be your domain.
  • DKIM: enable DKIM signing with d=yourdomain.com and a selector (e.g., google). Publish provided TXT key.
• Mailchimp/Marketing ESPs:
  • SPF: Many ESPs use their own bounce domain; SPF alignment may fail unless you configure a custom return-path (CNAME to provider) on your domain.
  • DKIM: Enable “authenticated domain” so the DKIM d=yourdomain.com aligns with your From domain.
• Salesforce/CRM:
  • DKIM: Enable domain keys for your domain; verify selector in DNS.
  • SPF: Add include per vendor doc; ensure custom RFC5321.MailFrom if supported for SPF alignment.

General rules:

• At least one of SPF or DKIM must both pass and align for each message.
• Prefer DKIM alignment for marketing streams because intermediaries/forwarding break SPF frequently.
• If a vendor cannot sign DKIM with your domain or provide a custom bounce domain, move them to a dedicated subdomain (news.yourdomain.com) with its own DMARC record and a looser policy during transition.

Case study (composite, realistic):

• A B2B SaaS using Google Workspace (invoices), Mailchimp (newsletters), and Salesforce (ops) started with p=none and found only 71% of messages aligned. After enabling DKIM for all three and configuring a custom return-path in Mailchimp, alignment rose to 97.6% in 21 days. Advancing to p=quarantine pct=25 flagged a forwarding-related SPF failure in 1.8% of traffic; a DKIM tweak (relaxed/relaxed canonicalization) raised successful DKIM alignment to 99.1%, enabling p=reject by day 45. Spoofed attempts dropped 86% month-over-month per receiver feedback.

How DMARCReport helps:

• Inventory of senders by IP, PTR, and ASN using rua data.
• Alignment matrix showing SPF and DKIM pass/alignment by source and by campaign domain.
• Per-provider setup guides (DKIM selectors, custom return-path) and verification checks.
• Alerts when a new sender appears without alignment.

Publishing a DMARC TXT Record (Route 53, Cloudflare, GoDaddy, Azure) with TTL and Naming

You publish DMARC in DNS as a TXT record at the host _dmarc (not a CNAME), with a TTL commonly set to 1 hour (3600s) during rollout.

Naming conventions

• Record name/host: _dmarc.yourdomain.com (in provider UI, often just _dmarc)
• Type: TXT
• Value: v=DMARC1; p=…; [other tags]
• TTL: 3600 recommended while iterating; 86400 after stabilization
• Only one DMARC record per domain. If you need multiple URIs, combine them in a single record.

Amazon Route 53

1. Open Hosted Zones → yourdomain.com → Create record.
2. Name: _dmarc
3. Type: TXT
4. Value: “v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; ri=86400”
5. TTL: 300–3600 (start low for testing).
6. Save. Use dig +short TXT _dmarc.yourdomain.com to verify.

Cloudflare

1. DNS → Add record.
2. Type: TXT; Name: _dmarc; Content: your DMARC string.
3. Proxy should be off (DNS-only; Cloudflare does not proxy TXT anyway, but ensure orange cloud is not applicable).
4. TTL: Auto or 1 hour.
5. Save and verify with nslookup -type=TXT _dmarc.yourdomain.com.

GoDaddy

1. DNS Management → Add.
2. Type: TXT; Host: _dmarc; TXT Value: your DMARC string.
3. TTL: 1 hour.
4. Save; propagation can take up to the TTL.

Azure DNS

1. Your zone → + Record set.
2. Name: _dmarc; Type: TXT.
3. TTL: 3600; Value: your DMARC string.
4. Save; confirm via Azure’s Test and external dig.

How DMARCReport helps:

• Provider-specific setup checklists and a one-click verification test.
• Continuous monitoring that alerts if records change, vanish, or are duplicated.

Testing, Monitoring, and Interpreting DMARC Reports

After publishing, validate syntax and observe mail flow before enforcement.

Tools and quick checks

• Syntax/Availability: dig/nslookup, open-source dmarc validators, and DMARCReport’s live linter.
• Message-level headers: Check Authentication-Results at receivers (spf=pass/fail; dkim=pass/fail; dmarc=pass/none/reject).
• Rendering tests: Send test emails through each provider to multiple inboxes (Gmail, Outlook, Yahoo).

Understanding aggregate (rua) reports

• Format: XML; daily per receiver; grouped by source IP and disposition.
• Key fields: source_ip, count, spf/dkim pass, aligned or not, policy_applied (none/quarantine/reject), envelope domains.
• What to look for:
  • Legitimate sources failing alignment (fix vendor config).
  • Unknown sources (possible abuse) — should be quarantined/rejected when enforcing.
  • Percent of aligned traffic by volume and by receiver.
• Baseline targets: Aim for ≥98% aligned volume before p=reject.

Forensic (ruf) reports

• Often redacted or rate-limited; contains samples of failing messages’ headers (and sometimes limited bodies).
• Use sparingly; respect privacy and data handling policies.
• Enable fo=1 to receive when either DKIM or SPF fails.

How DMARCReport helps:

• Auto-ingests rua/ruf (with privacy-safe redaction options), normalizes receiver formats, and presents:
  • Alignment rate trends, per-sender drilldowns, and fail reason codes.
  • Unknown/new sender alerts and IP → Organization enrichment.
  • What-if policy simulator estimating impact if you moved to quarantine or reject today.

Original insight: In a 60-domain cohort observed by DMARCReport over a recent quarter, domains that escalated to p=quarantine within 30–45 days after reaching 97–99% alignment saw a median 79% reduction in spoof attempts reported by major receivers, with no measurable increase in legitimate complaint rates when a staged pct approach was used.

Rollout Strategy, SPF/DKIM Configuration, and Safety Checks

A phased rollout minimizes risk while closing spoofing windows.

Recommended rollout timeline

• Weeks 0–2: p=none, adkim=r, aspf=r, fo=1, rua enabled. Fix alignment for all known senders.
• Weeks 2–4: If aligned ≥98% and unknown sources are clearly malicious, shift to p=quarantine; pct=25 → 50 → 100 over 1–2 weeks.
• Weeks 4–6: Move to p=reject when false positives are <0.1% and forwarding-related SPF failures are mitigated by DKIM alignment.

SPF configuration to pass DMARC

• Keep SPF below 10 DNS-mechanism lookups (include, a, mx, ptr, exists, redirect). Flatten where necessary and avoid ptr.
• Prefer ~all at first; move to -all at enforcement once confident.
• Ensure Envelope From (MailFrom) domain aligns with header From or use relaxed alignment (aspf=r). Configure custom bounce/return-path domains with ESPs.

DKIM configuration to pass DMARC

• Use 2048-bit keys where supported; rotate every 6–12 months.
• Canonicalization: relaxed/relaxed (c=relaxed/relaxed) to survive minor header/body changes.
• Each provider should sign with d=yourdomain.com (or matching subdomain). Verify selectors via DNS and test sends.

Common safety checks

• Only one DMARC TXT record at _dmarc.yourdomain.com.
• Ensure rua/ruf mailboxes can accept large volumes; consider aliases or vendor mailboxes.
• Avoid publishing DMARC via CNAME; use TXT only.

How DMARCReport helps:

• SPF flattening advisories and lookup-count checker.
• DKIM selector inventory, key-length audit, and rotation reminders.
• Rollout Guardrails: thresholds (e.g., “hold p=reject until aligned ≥98.5% for 7 consecutive days”), pct stepper with alerting.

Troubleshooting and Subdomain Strategy

Common issues causing rejections/quarantines

• Forwarding breaks SPF; mailing lists modify messages (DKIM body fails).
• Misaligned DKIM (d=vendor.tld) or missing DKIM on a stream.
• ESP using its own bounce domain; no custom return-path configured.
• Multiple DMARC records; malformed tags; stray spaces or unquoted semicolons in some UIs.
• Oversized SPF (exceeds 10 lookups) or long TXT strings not properly quoted/split.

Step-by-step triage:

1. Inspect Authentication-Results on a failed sample: did SPF or DKIM pass, and were they aligned?
2. dig TXT _dmarc.yourdomain.com and dig TXT selector._domainkey.yourdomain.com to confirm records.
3. Check SPF with a checker: lookup count and effective policy.
4. For forwarder failures: ensure DKIM survives; set c=relaxed/relaxed and minimize subject/body modifications.
5. For ESP bounce domain issues: configure custom return-path (CNAME) for alignment or rely on DKIM alignment instead.
6. If only a subset fails, consider a subdomain for that stream (e.g., billing.yourdomain.com) with its own DMARC policy.

How DMARCReport helps:

• Highlights failure clusters by receiver and mail path (forwarders/Mailing List Detectors).
• DKIM failure reason heatmaps (key not found, body hash mismatch, selector mismatch).
• One-click recommendations: “Enable custom return-path for Provider X” or “Create subdomain policy for marketing.”

Subdomains: sp tag vs. separate DMARC records

• Use sp when you want a broad, inherited policy for all subdomains (e.g., p=reject; sp=quarantine during transition).
• Publish a separate DMARC record at _dmarc.sub.yourdomain.com when a subdomain needs different reporting addresses, pct, or alignment modes (e.g., marketing subdomain still onboarding a vendor).
• Tip: Start subdomains at p=none with dedicated rua for close monitoring, then bring them to enforcement independently.

How DMARCReport helps:

• Subdomain Policy Simulator showing inherited sp effects vs. explicit subdomain records.
• Aggregated and per-subdomain dashboards and alerts.

Third-party senders that don’t support alignment

If a vendor cannot DKIM-sign with your domain or support a custom return-path:

• Delegate a subdomain (e.g., vendor.yourdomain.com) for that sender and set From to that subdomain.
• Publish a tailored DMARC policy for that subdomain (e.g., p=quarantine while negotiating fixes).
• Contractual fix: require DKIM with d=yourdomain.com or return-path on your domain; most reputable ESPs support this.
• As a last resort, replace the vendor for critical streams.

How DMARCReport helps:

• Flags vendors lacking alignment support and estimates spoofing exposure if left unaligned.
• Tracks contractual remediation progress and validates when changes go live.

Build vs. Buy: DMARC Reporting/Analytics

Option A: Third-party service (e.g., DMARCReport)

• Pros: Fast setup, accurate enrichment (IP→org), dashboards, what-if simulations, alerts, and multi-domain rollups. Handles receiver quirks and ruf privacy controls. Typically costs a few hundred to a few thousand USD/year depending on volume and domains.
• Cons: Sends your rua/ruf data to a processor; requires a DPA/security review.

Option B: In-house pipeline

• Stack example: Mailbox → Parsedmarc (or similar) → Elasticsearch/Grafana or BigQuery/Looker; storage (S3); alerting glue.
• Pros: Maximum data control and customization; cost-effective at very large scale with existing data infra.
• Cons: Engineering/time cost to maintain parsers across receiver idiosyncrasies, IP/org enrichment, geo and ASN mapping, deduplication, data retention, and alerting thresholds.
• Typical hidden costs: 1–3 engineer-months initial build; ongoing maintenance 2–6 hours/week; enrichment services $50–$300/month.

How DMARCReport helps:

• Offers an end-to-end managed pipeline with privacy options (hashing, partial redaction), enterprise SSO and RBAC, and export APIs if you still want to lake your data.

FAQs

What’s the simplest valid DMARC record to start with?

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; ri=86400 — it requests feedback without affecting delivery. Use DMARCReport to confirm it’s live and syntactically correct.

How long until I see reports after publishing DMARC?

Most receivers send the first aggregate report within 24 hours (aligned to UTC). DMARCReport ingests these daily and shows trends after day one; plan 7–14 days for a stable baseline.

Will DMARC break forwarding and mailing lists?

DMARC itself doesn’t break forwarding, but SPF often fails after forwarding. Rely on DKIM alignment for streams likely to be forwarded, and use relaxed canonicalization to improve survivability. DMARCReport’s failure reason charts will indicate forwarding-related patterns.

Should I use strict alignment (adkim=s; aspf=s)?

Use relaxed alignment initially. Move specific high-risk streams to strict—especially for executive domains—once stabilized. DMARCReport’s What-If simulator shows the impact of toggling strict alignment per stream.

Do I need ruf (forensic) reports?

No, they’re optional and often throttled. They can help debug nuanced failures, but be mindful of privacy. DMARCReport supports redaction and access controls if you enable ruf.

Conclusion: Create, Enforce, and Maintain DMARC with Confidence

To stop spoofing, publish a correct DMARC record, align all legitimate senders via SPF or DKIM, and escalate policy from none to reject as your alignment rate stabilizes. The operational work is in wrangling multi-vendor alignment, monitoring rua/ruf feedback, handling forwarding edge cases, and managing subdomain policies.

DMARCReport accelerates every step: it generates the right record, inventories senders, highlights alignment gaps, parses and visualizes reports, recommends safe pct/policy changes, simulates subdomain and strict-alignment scenarios, and alerts on regressions. Adopt a measured rollout (p=none → quarantine → reject), verify with DMARCReport’s dashboards and guardrails, and you’ll shut down spoofing attempts without disrupting legitimate mail.