DMARC Policy: What It Is, How It Works & Why It Matters

Spoofed email is not a theoretical risk—it is a daily reality. Without a published DMARC policy, any server on the internet can send email claiming to be from your domain, and inbox providers have no instructions to stop it. DMARC solves this by letting you publish a DNS record that tells receiving mail servers exactly what to do when a message fails authentication: monitor it, quarantine it, or reject it outright. For Salesforce senders, a correctly configured DMARC policy is no longer optional—Google and Yahoo made it mandatory for bulk senders in 2024, and the consequences of missing or misconfigured records range from spam folder placement to outright delivery rejection. This guide covers everything you need to understand and implement DMARC correctly for your sending domain.

What a DMARC Policy Is and the Problem It Solves

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It is an email authentication protocol that builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to give domain owners a policy layer—a set of instructions that receiving mail servers follow when they encounter a message that fails authentication checks. Without DMARC, a mail server that detects an SPF or DKIM failure has no guidance from the domain owner and may accept, flag, or reject the message at its own discretion.

The core problem DMARC solves is domain spoofing—sending email with a forged From address to impersonate a trusted brand. Phishing, BEC, and spam campaigns exploit domains without a DMARC policy because nothing stops them. According to the DMARC.org overview, a published DMARC policy protects your domain's reputation, prevents brand abuse, and provides the visibility needed to understand your complete email ecosystem—including third-party senders that send on your behalf.

DMARC also generates reports. When receiving servers process mail claiming to be from your domain, they send aggregate and forensic reports back to an address you specify. These reports reveal which sending sources pass or fail authentication, making them a critical tool for Salesforce email deliverability monitoring—especially when your domain sends through multiple services like Salesforce, a third-party ESP, and a support platform simultaneously.

The Three DMARC Policy Modes: none, quarantine, and reject

The DMARC policy is set with the p= tag in your DNS TXT record and controls what receiving servers do with failing messages. There are three values.

p=none (Monitor Mode) instructs receiving servers to take no action on failing messages—they are delivered normally. The policy does nothing to protect your domain from spoofing, but it generates DMARC reports that show you who is sending email using your domain. Every DMARC deployment should start here, because jumping straight to quarantine or reject without understanding your sending sources will block legitimate mail.

p=quarantine (Spam Folder Mode) routes failing messages to the spam folder rather than the inbox, reducing spoofed message reach while keeping them deliverable so administrators can identify false positives before advancing further.

p=reject (Block Mode) instructs receiving servers to reject failing messages outright—they are not delivered at all, and the sender receives a bounce notification. This is the strongest protection and the end goal of any mature DMARC implementation. Google and Yahoo require a published DMARC record (p=none or higher) for bulk senders, and the MassMailer guide to Google and Yahoo’s DMARC requirements covers the full compliance timeline and enforcement thresholds in detail.

The pct= tag controls what fraction of failing messages the policy applies to. A setting of pct=25 applies quarantine or reject to only 25% of failures—useful for gradual rollout. Default is 100 when pct is omitted.

DMARC Alignment: How SPF and DKIM Connect to the From Domain

DMARC passes only when at least one of its underlying protocols—SPF or DKIM—is both passing and aligned with the domain in the message's From header. Alignment is the key concept that separates DMARC from basic SPF/DKIM checks.

SPF alignment requires that the Return-Path domain match the visible From header domain. Salesforce's Return-Path often uses a Salesforce domain unless you configure a custom one—this breaks SPF alignment even when SPF itself passes, which is why the Salesforce email authentication guide recommends configuring DKIM as the primary alignment mechanism.

DKIM alignment requires that the domain in the d= tag of the DKIM signature matches the domain in the From header. Salesforce generates DKIM keys through Setup → Email → DKIM Keys, but DNS publishing is managed outside the platform—which creates a visibility gap when domain configurations change. When DKIM alignment passes, DMARC passes regardless of SPF alignment status.

Both alignment modes support strict (exact domain match) and relaxed (organizational domain match) checking. Relaxed alignment—the default—allows subdomains to pass alignment against the root domain. For example, a DKIM signature from mail.yourdomain.com passes relaxed alignment against yourdomain.com in the From header. The full DMARC specification in RFC 7489 documents all alignment rules and tag definitions.

How to Publish a DMARC DNS Record

A DMARC record is a DNS TXT record published at the subdomain _dmarc.yourdomain.com. It is readable by any receiving mail server when it processes email from your domain. Here is a minimal starting record for a new DMARC deployment:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

A more complete production record with percentage enforcement and forensic reporting looks like this:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; aspf=r; adkim=r

Tag definitions: v= specifies the DMARC version (always DMARC1). p= sets the policy mode. pct= controls the percentage of failing mail the policy applies to. rua= is the address for aggregate reports. ruf= is the address for forensic (message-level) reports. aspf= sets SPF alignment mode (r = relaxed, s = strict). adkim= sets DKIM alignment mode. sp= sets a separate policy for subdomains—useful when subdomains send different types of mail.

Publish via your DNS provider (GoDaddy, Cloudflare, Route 53, etc.). Changes propagate within minutes to hours, depending on TTL. Verify using Google Admin Toolbox or MXToolbox before assuming the record is active. The SPF, DKIM, and DMARC best practices guide on MassMailer includes a step-by-step validation checklist for Salesforce environments.

Reading DMARC Reports: Aggregate and Forensic Data

DMARC reports are the feature that makes the protocol genuinely useful beyond policy enforcement. Without them, you are flying blind on who is sending mail from your domain and how much of it passes authentication.

Aggregate reports (rua) are XML files sent daily by participating receiving mail servers. Each report covers a 24-hour period and contains: the sending source (IP address and sending domain), the volume of messages processed, the SPF and DKIM pass/fail result for each source, and the DMARC alignment outcome. Aggregate reports let you map your full sending infrastructure—revealing legitimate sources you may have forgotten to configure (an older marketing tool, a transactional platform, a CRM integration) alongside illegitimate sources attempting to spoof your domain.

Forensic reports (ruf) are message-level reports triggered on individual DMARC failures. They contain email headers and are useful for diagnosing specific failures, though not all receivers send them. Their use is declining due to privacy concerns, so aggregate reports remain the primary diagnostic tool.

Most organizations use a third-party tool (Postmark, Dmarcian, or Valimail) to process DMARC reports because raw XML is not readable at scale. The Google Postmaster Tools guide on bulk sender requirements covers how Gmail specifically evaluates authentication and domain reputation for bulk senders—including DMARC—which affects inbox placement for all Salesforce campaigns targeting Gmail addresses.

DMARC for Salesforce Senders: Requirements and Best Practices

Salesforce senders face a specific authentication challenge: Salesforce's mail infrastructure sends on behalf of your domain, meaning your SPF and DKIM records must explicitly authorize Salesforce’s sending servers, and DKIM alignment must be configured correctly for DMARC to pass. When either is missing or misconfigured, even legitimate Salesforce campaigns fail DMARC—meaning they hit spam folders or get rejected once your policy moves past p=none.

The recommended implementation path for Salesforce senders: Start with p=none and collect aggregate reports for two to four weeks. Identify every sending source that appears in reports—Salesforce CRM, Marketing Cloud, any AppExchange email tool, transactional platforms, support systems. Ensure each source has correct SPF authorization or a valid DKIM signature aligned to your From domain. Only move to quarantine after all legitimate sources pass. Move to reject only after quarantine produces no false positives over a sustained monitoring period.

High-volume Salesforce senders using a native email application like MassMailer benefit from authentication alignment built into the platform—DKIM signing, dedicated IP management, and email bounce handling that prevents reputation damage from triggering aggressive DMARC enforcement. The Salesforce email security guide provides the full SPF, DKIM, and DMARC configuration sequence for Salesforce, including DNS record examples for common sending configurations.

Finally, protect your subdomains. The sp= tag in your DMARC record sets the policy for subdomains independently of the main domain policy. An unprotected subdomain like send.yourdomain.com or mail.yourdomain.com can be exploited even if your root domain has p=reject—making subdomain coverage a critical but commonly missed step in email marketing compliance for organizations with complex sending infrastructure.

Authenticate Your Salesforce Domain and Stop Spoofing Before It Damages Your Sender Reputation

MassMailer keeps your Salesforce email authentication—SPF, DKIM, and DMARC alignment—in sync with your sending infrastructure. No configuration gaps, no deliverability surprises. Schedule a call with our team to review your current authentication setup and fix any gaps before they affect your next campaign.

Key Takeaways

  • DMARC is a DNS-published authentication policy that instructs receiving mail servers what to do when email fails SPF or DKIM checks—monitor (none), quarantine, or reject.
  • DMARC passes only when SPF or DKIM is both passing and aligned with the domain in the visible From header—SPF or DKIM passing alone is not sufficient without alignment.
  • Every DMARC deployment should start at p=none to collect aggregate reports and map all sending sources before advancing to quarantine or reject—skipping this step blocks legitimate mail.
  • Aggregate reports (rua) reveal every server sending email from your domain, identifying forgotten legitimate sources and active spoofing attempts in a single daily XML delivery.
  • Google and Yahoo require a published DMARC record for bulk senders—organizations sending high volumes to Gmail or Yahoo addresses without one face spam folder placement or delivery rejection.
  • The sp= tag in your DMARC record controls subdomain policy independently—unprotected subdomains remain spoofable even when the root domain has p=reject configured.