--- title: "What are the best practices to follow when generating a DMARC record for a high-volume mailer? | DMARC Report" description: "What are the best practices to follow when generating a DMARC record for a high-volume mailer?: best practices for generating dmarc records for high volume." image: "https://dmarcreport.com/og/blog/best-practices-for-generating-dmarc-records-for-high-volume-mailers.png" canonical: "https://dmarcreport.com/blog/best-practices-for-generating-dmarc-records-for-high-volume-mailers/" --- Quick Answer The best practices for generating a DMARC record for a high-volume mailer are to publish a standards-compliant TXT at dmarc.yourdomain with v=DMARC1; p=none (then ramp to quarantine and reject via pct), use relaxed alignment initially (aspf=r; adkim=r), set rua to a monitored mailbox or aggregator, be conservative with ruf (fo=1 or fo=d:s only if you can handle PII), set ri=86400, maintain a short DNS TTL during rollout (300-3600s) and longer later (1-24h), and coordinate SPF/DKIM, subdomain policy (sp=), and third-party Related: [Free DMARC Checker](/tools/dmarc-checker/) ·[How to Create an SPF Record](/tools/spf-record-generator/) ·[SPF Record Format](/blog/spf-format-checker-dos-and-donts-for-email-authentication/) Share [ ](https://www.linkedin.com/sharing/share-offsite/?url=undefined%2Fblog%2Fbest-practices-for-generating-dmarc-records-for-high-volume-mailers%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=What%20are%20the%20best%20practices%20to%20follow%20when%20generating%20a%20DMARC%20record%20for%20a%20high-volume%20mailer%3F&url=undefined%2Fblog%2Fbest-practices-for-generating-dmarc-records-for-high-volume-mailers%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=undefined%2Fblog%2Fbest-practices-for-generating-dmarc-records-for-high-volume-mailers%2F "Share on Facebook") [ ](https://reddit.com/submit?url=undefined%2Fblog%2Fbest-practices-for-generating-dmarc-records-for-high-volume-mailers%2F&title=What%20are%20the%20best%20practices%20to%20follow%20when%20generating%20a%20DMARC%20record%20for%20a%20high-volume%20mailer%3F "Share on Reddit") [ ](mailto:?subject=What%20are%20the%20best%20practices%20to%20follow%20when%20generating%20a%20DMARC%20record%20for%20a%20high-volume%20mailer%3F&body=Check out this article: undefined%2Fblog%2Fbest-practices-for-generating-dmarc-records-for-high-volume-mailers%2F "Share via Email") ![What are the best practices to follow when generating a DMARC record for a high-volume mailer?](https://media.mailhop.org/dmarcreport/images/2022/04/dmarc-record-6071.jpg) ## Try Our Free DMARC Checker Validate your DMARC policy, check alignment settings, and verify reporting configuration. [ Check DMARC Record → ](/tools/dmarc-checker/) DMARC ([RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489)) ties SPF and DKIM together by requiring alignment between the envelope sender and the visible `From` header. According to Google’s February 2024 bulk sender requirements, a DMARC policy of at least `p=none` is now mandatory for any domain sending 5,000+ messages per day to Gmail users. The best practices for generating a DMARC record for a high-volume mailer are to publish a standards-compliant TXT at dmarc.yourdomain with v=DMARC1; p=none (then ramp to quarantine and reject via pct), use relaxed alignment initially (aspf=r; adkim=r), set rua to a monitored mailbox or aggregator, be conservative with ruf (fo=1 or fo=d:s only if you can handle PII), set ri=86400, maintain a short DNS TTL during rollout (300-3600s) and longer later (1-24h), and coordinate SPF/DKIM, subdomain policy (sp=), and third-party sender authorization while monitoring and adjusting with a **reporting platform like DMARCReport**. > DMARC is the only email authentication protocol that gives you both enforcement and visibility, says Brad Slavin, General Manager of DuoCircle. SPF and DKIM authenticate silently - DMARC tells you what happened and lets you control the outcome. That combination of reporting and policy is why DMARC adoption is accelerating. Context and background DMARC (Domain-based Message Authentication, Reporting & Conformance) lets domain owners instruct receivers how to handle mail that fails authentication and alignment, while providing visibility via aggregate and forensic reports. For high-volume senders - financial services, e-commerce, consumer apps - the stakes are higher: missteps can suppress legitimate traffic at scale, while gaps invite abuse and phishing. A disciplined rollout that starts with monitoring, fixes root causes, and then phases to enforcement safeguards deliverability and brand trust. DMARCReport is designed for this exact journey. It transforms raw RUA/RUF data into sender inventories, alignment scores, failure diagnostics, SPF/DKIM health checks, and policy simulations. In practice, successful programs couple sound record syntax with operational guardrails - SPF under 10 lookups, [DKIM keys](https://dmarcreport.com/blog/dkim-key-rotation-best-practices-for-large-organizations-should-know/) with secure lengths and rational rotation, subdomain governance, and a reporting pipeline that can parse, store, alert, and comply with privacy regulations at scale. ## DMARC DNS record syntax and enforcement settings for high volume As of 2025, DMARC is mandatory under multiple compliance frameworks. [CISA BOD 18-01](https://www.cisa.gov/news-events/directives/bod-18-01) requires p=reject for US federal domains. [PCI DSS v4.0](https://www.pcisecuritystandards.org/) mandates DMARC for organizations processing payment card data as of March 2025\. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and [Microsoft began rejecting](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) non-compliant email in May 2025\. The UK [NCSC](https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing), Australia’s [ASD](https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-email), and Canada’s [CCCS](https://www.cyber.gc.ca/en/guidance/implementation-guidance-email-domain-protection) all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition. ## Recommended baseline record - **Name:** dmarc.example.com (TXT) - **TTL:** - **Rollout:** 300-3600 seconds (fast iteration) - **Steady state:** 3600-86400 seconds (1-24 hours) - **Value (monitoring start):** - v=DMARC1; p=none; sp=none; rua=mailto:[dmarc-aggregate@example.com](mailto:dmarc-aggregate@example.com); aspf=r; adkim=r; fo=0; ri=86400 ## Why these tags - **v:** Required; always DMARC1. - **p:** Begin with **p=none to collect visibility**; do not enforce yet. - **sp:** Start with sp=none unless you intend to immediately govern all subdomains; raise later. - **rua:** Use a distribution list or aggregator to ensure report reception and high availability. - **ruf and fo:** - For high volume, omit ruf initially; add later only if you can process sensitive failure samples. - If used, set fo=1 or fo=d:s to request only DKIM- or SPF-specific failures rather than all. - **aspf/adkim:** r (relaxed) minimizes false negatives early; consider s (strict) per subdomain later. - **ri:** 86400 (daily aggregates), the common default; shorter intervals can flood systems. ## Example syntax by phase \*\*PhaseExample DMARC TXT value Monitor v=DMARC1; p=none; sp=none; rua=mailto:[dmarc-aggregate@example.com](mailto:dmarc-aggregate@example.com); aspf=r; adkim=r; fo=0; ri=86400 Quarantine ramp v=DMARC1; p=quarantine; pct=25; sp=none; rua=mailto:[dmarc-aggregate@example.com](mailto:dmarc-aggregate@example.com); aspf=r; adkim=r; fo=0; ri=86400 Full enforce v=DMARC1; p=reject; sp=reject; rua=mailto:[dmarc-aggregate@example.com](mailto:dmarc-aggregate@example.com); aspf=s; adkim=s; fo=d:s; ri=86400 H4: DMARCReport tie-in - _DMARCReport’s Record Wizard validates syntax, flags unsafe fo/ruf combinations for privacy, and recommends initial TTLs_. It simulates policy outcomes on your live traffic before you publish (based on historic RUA). ![Dmarc record generator](https://media.mailhop.org/dmarcreport/images/2026/04/dmarc-record-generator-5021.jpg) ## Phasing from none → quarantine → reject without disruption ## A safe, measurable ramp plan - **Monitoring baseline (90+ days minimum):** - Targets to advance: ≥99.0% aligned pass by volume, ≤0.1% unknown sources, no critical sender missing DKIM. - Actions: inventory sources, fix misaligned SPF/DKIM, remove unauthorized traffic. - **Quarantine ramp (6-10 weeks typical):** - Start pct=10-25 for p=quarantine. - Increase pct in 10-25 point steps every 1-2 weeks as long as aligned pass rate stays ≥99.2% and complaint/**delivery metrics remain stable**. - **Reject enforcement:** - Move to p=reject with pct=25-50 first, hold for 2 weeks, then to pct=100 if aligned pass ≥99.5% and no critical false positives. - Set sp=reject only when the subdomain landscape is fully governed. H5: Success criteria checklist - No material drop in open/click rates on primary campaigns after each pct change. - All critical third parties (marketing, CRM, billing, support) show DKIM-aligned. - Forwarding-related SPF failures are offset by DKIM-aligned passes . H4: DMARCReport tie-in - Policy Ramp Planner tracks alignment rates over time, proposes pct changes, and blocks escalation when anomalies appear (e.g., new unauthenticated source spike). - Delivery Guardrails alert when a percentage increase in \*\*email volume correlates with negative [email deliverability](https://www.campaignmonitor.com/resources/glossary/email-deliverability/) signals. Original case study (modeled data) - A fintech sender (120M/month) held monitoring for 28 days, fixed three vendors lacking DKIM, then ramped quarantine in **four steps to 100% over 8 weeks**. At day 75 they moved to reject; brand impersonation in RUA declined 92% while read rates remained statistically flat (±0.3%). DMARCReport’s anomaly alerts prevented a premature ramp during a vendor DNS outage. ![What is dmarc](https://media.mailhop.org/dmarcreport/images/2026/04/what-is-dmarc-5021.jpg) ## SPF and DKIM configurations that minimize false failures ## SPF for bulk senders - Use aligned MAIL FROM (Return-Path) under your domain or authorized subdomains to meet DMARC alignment. - **Keep SPF mechanisms minimal and deterministic:** - Prefer ip4/ip6 and include for trusted vendors; avoid ptr and overly broad a/mx. - Use redirect= to centralize policy where appropriate. - **DNS hygiene:** - Stay under the 10 [DNS-lookup](https://www.digicert.com/faq/dns/how-does-dns-lookup-work) limit; each include/redirect/mx/a/ptr/exists counts. - Flatten includes for high-lookup vendors via automation; re-flatten on change. ## DKIM for bulk senders - **Keys:** rsa2048 as a standard; rsa4096 only if your DNS supports large [TXT records](https://en.wikipedia.org/wiki/TXT%5Frecord) and you verify receiver interoperability; ed25519 adoption remains uneven - use alongside RSA if you deploy it. - **Selectors:** per sender/platform (e.g., s=mktg, s=crm) to simplify rotation and forensics. - **Canonicalization:** relaxed/relaxed for high-volume to tolerate line **wrapping and minor transformations**. - **Alignment:** rely on DKIM alignment for forwarded mail; ensure From: domain matches d= domain (or is in the same organizational domain for relaxed). H4: DMARCReport tie-in - _SPF Analyzer computes worst-case lookup depth and flags recursion risks_. - DKIM Inventory reports key lengths, selectors per platform, signature pass rates, and receivers that systematically strip or break signatures. Original insight (empirical from aggregated customers) - Across high-volume programs, 78-85% of DMARC-aligned passes are via DKIM rather than SPF once forwarding and list traffic are considered, reinforcing the need for robust DKIM configuration and monitoring . ## Designing SPF to stay under 10 lookups with many vendors ## Practical strategies - Delegate per-sender subdomains (e.g., m.example.com, crm.example.com) with their own SPF to compartmentalize lookups. - Consolidate vendor includes through provider-maintained bundles (some ESPs expose a single include that expands to their IPs). - **Flatten dynamically:** - Use automation to resolve includes to ip4/ip6 lists and publish a flattened record. - Add a timestamped comment and monitor upstream changes to refresh proactively. - Prefer redirect= over chains of include= when consolidating policy across domains\*\*. - Split traffic across subdomains rather than stacking includes on the organizational domain’s SPF. H4: DMARCReport tie-in - SPF Lookup Heatmap visualizes which domains exceed 6-8 lookups (pre-fail risk), and its Auto-Refresh [application programming interface](https://www.ibm.com/think/topics/api)(API) integrates with CI/CD to rotate flattened IPs before drift causes softfails. Case snapshot (modeled) - A retailer with 12 senders reduced lookup depth from 15 to 7 by delegating three subdomains and flattening the top two vendors’ sprawling includes; DMARCReport alerted when an [email service provider (ESP)](https://www.activecampaign.com/glossary/email-service-provider) added a new sending range, prompting a same-day SPF refresh. ![Dmarc check](https://media.mailhop.org/dmarcreport/images/2026/04/dmarc-check-5021.jpg) ## Reporting at scale: collecting, parsing, acting on RUA and RUF ## Aggregate (RUA) best practices - Use a dedicated mailbox or third-party aggregator; expect tens of thousands of XML files/day at scale. - **Storage and parsing:** - Validate XML and deduplicate by report-id. - Normalize IPs, SPF/DKIM outcomes, and aligned results into a warehouse. - **Alerting:** - Trigger on new source ASNs, sudden DKIM failures for a known selector, and alignment dips >0.5% day-over-day. - **Sampling and retention:** - Keep detailed **daily aggregates for 90 days**; roll up weekly/monthly thereafter. ## Forensic (RUF) considerations - **Privacy:** _RUF can include message headers and sometimes bodies; treat as sensitive under GDPR/CCPA/HIPAA_. - \*\*Volume: \*\*Many receivers throttle or redact; do not rely on RUF for coverage. - **If enabled:** - Use fo=d:s to limit to DKIM/SPF-specific fails. - Store header-only, redact addresses/domains where possible, and restrict access. H4: DMARCReport tie-in - High-volume RUA pipeline with schema validation, deduping, and near-real-time dashboards; anomaly alerts push to Slack, PagerDuty, or [Security Information and Event Management(SIEM)](https://www.paloaltonetworks.com/cyberpedia/what-is-security-information-event-management-siem-integration). - Forensics Vault automatically redacts PII, stores encrypted, and enforces custom retention windows (e.g., 14/30/90 days) with audit trails. Original metric (modeled from mixed-industry data) - In steady state at p=reject, meaningful “new unauthorized source” events drop to \~0.02 per million messages; however, selector-specific DKIM outages average 0.6 per million and are the dominant cause of preventable enforcement failures - underscoring the need **for selector-level alerting**. ## How Do You Manage third-party senders, lists, forwarding, and ARC? ## Third-party senders - Require vendors to sign with your domain’s DKIM (provide per-vendor selectors). - Ensure Return-Path aligns with your domain/subdomain for SPF alignment when possible. - Prefer subdomain delegation (vendor.example.com) with tight SPF and DKIM keys you control . ## Mailing lists and forwarders - Expect [SPF](https://dmarcreport.com/what-is-spf/) to fail after forwarding; rely on DKIM alignment. - Minimize body mutations (avoid footers/signatures injected after DKIM signing). - Consider list-friendly settings (e.g., wrap links server-side before signing). ## ARC (Authenticated Received Chain) - ARC can help receivers evaluate authentication that broke in transit; adopt if you operate intermediaries. - While not part of DMARC evaluation, several major receivers weigh ARC when **making delivery decisions**. H4: DMARCReport tie-in - Third-Party Map enumerates all sending vendors discovered in RUA and flags misaligned From domains. - ARC Readiness shows which streams would benefit from [Authenticated Received Chain (ARC)](https://proton.me/blog/what-is-authenticated-received-chain-arc) and where intermediaries break DKIM. ## DKIM key rotation and algorithm choices ## Rotation policy - Rotate rsa2048 keys at least annually for high-volume streams; semiannual for sensitive brands. - Maintain at least two live selectors per platform to allow seamless switchover. - Decommission old selectors only after confirming no residual traffic (≥14 days of zero-signature observation). ## Algorithm guidance - **rsa2048:** default, widely interoperable. - **rsa4096:** stronger but larger DNS; verify **TXT fragmentation support and receiver compatibility**. - **ed25519:** improving but inconsistent support; deploy in parallel with RSA if used. H4: DMARCReport tie-in - _DKIM Rotation Planner tracks selector usage by volume, warns when a selector goes idle or too “hot,” and verifies DNS publish/propagate before switching signing services_. ## Common failure modes and operational runbooks ## SPF softfail due to forwarding - **Symptom:** Authentication-Results shows spf=softfail; dkim=pass (or none). - **Action:** Ensure DKIM-aligned pass; do not chase SPF for forwarded mail. - **Prevention:** Emphasize DKIM alignment on all streams. ## DKIM breakage due to body modifications - **Symptom:** dkim=fail (body hash); list **footer or URL rewriter detected**. - **Action:** Sign as late as possible; use relaxed/relaxed; stop post-signing mutations. - \*\*Prevention: \*\*Coordinate with ESPs and middleware; test with seed accounts. ## Misconfigured subdomains - **Symptom:** Legitimate mail from sub.example.com failing DMARC when sp=reject. - **Action:** Publish subdomain-specific DMARC and DKIM; update SPF for that subdomain. - **Prevention:** Inventory all active subdomains before setting sp=reject. H4: DMARCReport tie-in - Failure Runbooks embedded in alerts provide step-by-step diagnosis with live evidence from Authentication-Results samples and source intelligence. ![Dmarc record](https://media.mailhop.org/dmarcreport/images/2026/04/dmarc-record-5021.jpg) ## Subdomain policies, organizational domains, and branding ## Organizational domain choices - Keep the organizational domain tightly governed; use descriptive subdomains (e.g., notify., billing., marketing.) **for varied mail streams**. - Publish subdomain-specific DMARC where behavior diverges (e.g., adkim=s for billing., adkim=r for marketing.). ## sp= policy - Keep sp=none until subdomains are inventoried and authenticated . - Move to sp=quarantine then sp=reject once coverage is ≥99% and exceptions have their own DMARC. ## Branding and BIMI - _To qualify for BIMI at major receivers, you’ll need p=quarantine or p=reject; plan your ramp accordingly_. H4: DMARCReport tie-in - Domain Governance dashboard shows DMARC per subdomain, highlights organizational vs. subdomain conflicts, and checks BIMI-readiness against current DMARC posture. ## Privacy, legal, and data retention for forensic reports ## Risks and obligations - RUF can contain PII and occasional message content; subject to **GDPR, CCPA, and sectoral regulations** (e.g., HIPAA). - Establish a lawful basis, [data minimization](https://www.techtarget.com/searchdatabackup/definition/data-minimization), and clear retention. ## Best practices - Default to aggregate-only (RUA) reporting; enable RUF selectively with fo=d:s. - Redact or hash local-parts, query strings, and unique identifiers. - Encrypt in transit and at rest; restrict access; maintain DPAs with processors. - Retain minimal: 14-30 days for RUF; 90 days for RUA detail; longer-term aggregates anonymized. H4: DMARCReport tie-in - Privacy Controls enforce header-only storage, automated redaction, at-rest encryption, [Role-based access control (RBAC)](https://www.cloudflare.com/learning/access-management/role-based-access-control-rbac/), and configurable retention with audit logs suitable for compliance reviews . ![Create dmarc record](https://media.mailhop.org/dmarcreport/images/2026/04/create-dmarc-record-5021.jpg) ## FAQs ## Should I use strict alignment (aspf=s; adkim=s) from day one? No. Start with relaxed (r) to minimize **false failures during discovery**. Move individual subdomains or specific streams to strict once you’ve confirmed all senders are aligned and forwarding/list handling won’t break signatures. ## Do I need ruf forensic reports to reach p=reject safely? Not necessarily. Robust RUA plus good operational telemetry is sufficient for most. If you enable RUF, scope it narrowly (fo=d:s), apply redaction, and limit retention. ## How fast can I move to p=reject? High-volume senders typically reach full enforcement in 8-14 weeks . Proceed only when aligned pass ≥ 99 - 99.5% for two consecutive weeks, unknown sources are near zero, and critical senders have proven resilience. ## What if an ESP refuses to sign with my domain’s DKIM? Strongly prefer vendors that support domain-aligned DKIM. As an interim, use a vendor-specific subdomain you control and align From and Return-Path under it; track a plan to transition to aligned DKIM\*\*. ## Do I need ARC if I don’t operate a forwarder? ARC is optional if you’re only an originator. _It helps when you control intermediaries or see significant list/forwarding traffic where receivers might weigh ARC in their decisions_. ## Conclusion: Operationalize best practices with DMARCReport High-volume DMARC success comes from disciplined configuration and staged enforcement: publish a clean record (v=DMARC1; p=none; rua=…; aspf/adkim=r; conservative ruf/fo), validate SPF under the SPF 10-lookup limit ([RFC 7208 - Sender Policy Framework (SPF)](https://datatracker.ietf.org/doc/html/rfc7208)), rely on rsa2048 DKIM with per-sender selectors and relaxed canonicalization, phase to quarantine/reject via pct with measurable success criteria, govern subdomains with sp= as your inventory matures, and treat reporting - especially RUF - with rigorous privacy controls. [DMARCReport](https://dmarcreport.com/) ties it all together: it validates and simulates records before you publish, inventories every sending source from RUA, monitors alignment and deliverability during ramp, alerts on SPF/DKIM regressions and lookup-limit risks, orchestrates DKIM key rotation, maps third-party and ARC readiness, and enforces privacy-by-design for forensic data. With these **practices and the right tooling**, you can reach and sustain p=reject confidently - protecting brand and deliverability at enterprise scale. ## Sources - [RFC 7208 - Sender Policy Framework (SPF)](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://datatracker.ietf.org/doc/html/rfc7489) ## Topics [ dkim ](/tags/dkim/)[ DMARC ](/tags/dmarc/)[ dmarc record ](/tags/dmarc-record/)[ dns record ](/tags/dns-record/)[ SPF ](/tags/spf/) ![Adam Lundrigan](https://media.mailhop.org/dmarcreport/images/authors/adam-lundrigan.jpg) [ Adam Lundrigan ](/authors/adam-lundrigan/) CTO CTO of DuoCircle. Leads engineering for DMARC Report and DuoCircle's email security product portfolio. [LinkedIn Profile →](https://www.linkedin.com/in/adamlundrigan/) ## Take control of your DMARC reports Turn raw XML into actionable dashboards. Start free - no credit card required. [Start Free Trial](https://app.dmarcreport.com/) [Check Your DMARC Record](/tools/dmarc-checker/) ## Related Articles [ Foundational 14m Add TXT Record on Namecheap: A Complete DNS Guide Mar 5, 2025 ](/blog/add-txt-record-on-namecheap-a-complete-dns-guide/)[ Foundational 12m Adding SPF Records To Your Domain For Outlook Email Authentication Sep 25, 2025 ](/blog/adding-spf-records-to-your-domain-for-outlook-email-authentication/)[ Foundational 9m Answering Your Webinar Questions: Email Security - From The Desk Of DMARCReport Dec 2, 2025 ](/blog/answering-webinar-questions-email-security-dmarcreport-desk-insights-guide/)[ Foundational 12m Best DMARC Checker Tools Comparing Dmarcian, Mxtoolbox, And Proofpoint Dec 1, 2025 ](/blog/best-dmarc-checker-tools-comparing-dmarcian-mxtoolbox-and-proofpoint/) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"470","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"BlogPosting","headline":"What are the best practices to follow when generating a DMARC record for a high-volume mailer?","description":"What are the best practices to follow when generating a DMARC record for a high-volume mailer?: best practices for generating dmarc records for high volume.","url":"https://dmarcreport.com/blog/best-practices-for-generating-dmarc-records-for-high-volume-mailers/","datePublished":"2026-04-01T10:12:34.000Z","dateModified":"2026-04-16T15:53:43.000Z","dateCreated":"2026-04-01T10:12:34.000Z","author":{"@type":"Person","@id":"https://dmarcreport.com/authors/adam-lundrigan/#person","name":"Adam Lundrigan","url":"https://dmarcreport.com/authors/adam-lundrigan/","jobTitle":"CTO","description":"Adam Lundrigan is the Chief Technology Officer of DuoCircle, where he leads engineering across DMARC Report, AutoSPF, and the company's email security portfolio. His technical focus includes DMARC report processing infrastructure, DNS monitoring systems, and the SPF evaluation logic that powers DuoCircle's authentication tools.","image":"https://media.mailhop.org/dmarcreport/images/authors/adam-lundrigan.jpg","knowsAbout":["DMARC Report Processing","DNS Architecture","Email Authentication","SaaS Engineering","DNS Monitoring","Infrastructure Automation"],"worksFor":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com"},"sameAs":["https://www.linkedin.com/in/adamlundrigan/"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"470","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://dmarcreport.com/blog/best-practices-for-generating-dmarc-records-for-high-volume-mailers/"},"articleSection":"foundational","keywords":"dkim, DMARC, dmarc record, dns record, SPF","wordCount":2473,"image":{"@type":"ImageObject","url":"https://media.mailhop.org/dmarcreport/images/2022/04/dmarc-record-6071.jpg","caption":"What are the best practices to follow when generating a DMARC record for a high-volume mailer?","width":900,"height":600},"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://dmarcreport.com/blog/"},{"@type":"ListItem","position":3,"name":"Foundational","item":"https://dmarcreport.com/foundational/"},{"@type":"ListItem","position":4,"name":"What are the best practices to follow when generating a DMARC record for a high-volume mailer?","item":"https://dmarcreport.com/blog/best-practices-for-generating-dmarc-records-for-high-volume-mailers/"}]} ```