How to Set Up DMARC: A Complete Guide to SPF, DKIM, Reports, Alignment, and Safe Enforcement Across Domains

Cyberattackers forge the visible From address because it is the field recipients actually read, and a familiar sender name turns a fraudulent invoice into an approved payment. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports. A domain left unprotected effectively lends its reputation to every campaign that borrows it.

Publishing a DNS record is the straightforward part of the work. The difficulty lies in reaching enforcement without blocking the invoices, password resets, and recruiting messages that legitimate services send on an organization's behalf. Most stalled rollouts trace back to a forgotten sending system rather than to a syntax error. This guide covers:

• How to set up DMARC records at the _dmarc label, including the minimum policy and the optional pct, sp, aspf, and adkim tags;
• How to inventory every legitimate sender and confirm SPF and DKIM before any DMARC policy reaches production DNS;
• How to read aggregate reports and separate an authentication failure from an alignment failure;
• How to repair third-party vendor, forwarding, and mailing-list failures without weakening the published policy;
• How to set up DMARC enforcement in stages, advancing from p=none to p=quarantine and p=reject with a defined rollback owner;
• How to extend DMARC across subdomains, acquired domains, and parked domains, and where employee judgment still carries the remaining risk.

Forged sender addresses are only the opening move, and lookalike domains still land convincing requests with finance and executive teams. Adaptive Security rehearses those decisions through realistic phishing simulations.

Take a self-guided tour

What Does Setting Up DMARC Do?

Domain-based Message Authentication, Reporting and Conformance (DMARC) tells receiving mail servers how to handle messages that claim to come from a protected domain. It binds the visible From address to the results of SPF and DKIM through a rule called alignment, and it returns reports describing what receiving systems observed. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, internet crime drove $20.877 billion in reported losses, a 26% jump over the prior year ($16.6 billion in 2024).

How Does the DMARC Protection Model Work?

DMARC protects the identity recipients see in the From field. A cyberattacker can make an email appear to come from finance@example.com while sending it through infrastructure with no legitimate relationship to example.com. SPF and DKIM establish whether the message was authorized or cryptographically signed, and DMARC checks whether that authentication corresponds to the visible sending domain.

SPF, or Sender Policy Framework, lists the mail servers authorized to send mail for a domain. Receiving systems compare the message's envelope sender, sometimes called the Return-Path, with the domain's SPF record. If the sending server is not listed, SPF fails.

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing messages. The receiving server uses the public key published in DNS to verify that an authorized domain signed the message and that the signed content survived transit unaltered. DKIM often provides the more durable authentication path when mail passes through multiple forwarding or delivery services.

DMARC adds alignment to those checks. The domain in the visible From address must match, either exactly or by organizational domain, the domain authenticated through SPF or DKIM. A message passes DMARC when at least one of these combinations succeeds:

• SPF passes and the SPF-authenticated domain aligns with the visible From domain;
• DKIM passes and the signing domain in the d= value aligns with the visible From domain.

Google Workspace documentation on DMARC explains that relaxed alignment accepts a matching organizational domain or subdomain, while strict alignment requires an exact match. Most organizations begin with relaxed alignment to avoid disrupting legitimate third-party senders, then adopt stricter settings after documenting subdomain ownership and mail flows.

A DMARC DNS TXT record also specifies the receiver's action when a message fails. The p=none value requests delivery while generating reports, p=quarantine directs receivers to treat failures as suspicious, and p=reject asks receivers to refuse them. The policy guides receiving systems, although mailbox providers do not implement every action identically.

The desired end state is specific. Approved services authenticate mail correctly, reports show that legitimate traffic passes, unauthorized messages fail alignment, and receiving systems quarantine or reject those failures.

How Does the DMARC Setup Sequence Work?

Setting up DMARC belongs to the security, email administration, or domain operations team, with support from the owners of marketing platforms, customer communications, ticketing systems, payroll, and CRM tools. The implementer needs permission to edit DNS TXT records for each sending domain and access to a mailbox or reporting service that can receive aggregate reports. The sequence below orders the work, and each stage receives full treatment later in this guide:

• Inventory every legitimate sender, including forgotten subdomains and vendors managed outside IT;
• Confirm that SPF, DKIM, or both authenticate each of those senders consistently;
• Choose a reporting destination that a team monitors in place of an individual inbox;
• Publish a monitoring record at _dmarc.example.com with p=none and a rua address;
• Review aggregate reports and correct the SPF, DKIM, or alignment failures they expose;
• Raise enforcement gradually toward p=quarantine and then p=reject;
• Assign continuing ownership, because new SaaS tools, acquisitions, and vendor migrations create new sending paths.

This monitoring-first order aligns with CISA's 2025 phishing guidance, which describes DMARC reject as the control that causes receiving systems to refuse messages using a spoofed domain. Publishing p=reject before understanding legitimate traffic reverses the correct order and can create an avoidable mail outage.

Organizations that need a clear division of DNS, identity, and email responsibilities can document the work alongside their Microsoft 365 and Google Workspace integrations. Enforcement itself remains a domain-host and receiving-server function, so ownership must stay with the teams responsible for those systems.

What Does Setting Up DMARC Not Protect Against?

DMARC blocks direct spoofing of a protected domain when receiving systems honor the published policy. It does not authenticate the person behind a valid account or inspect the business decisions made through a trusted mailbox. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element, which is the exposure that sits outside every DNS record.

Mailbox compromise remains outside the protocol's scope. When a cyberattacker steals an employee's password, session token, or authentication factor and sends mail through the organization's approved platform, SPF and DKIM can pass and the message can align with the visible From domain. Phishing-resistant multifactor authentication, conditional access, session monitoring, and rapid account recovery address that gap.

Lookalike domains are different domains. A cyberattacker who registers examp1e.com or example-finance.com is not spoofing example.com at the DNS level, so a policy on the real domain offers those recipients no protection. Domain monitoring, brand protection, and secure web filtering close part of the gap, and employee judgment closes the rest.

Authenticated accounts can still send malicious messages. A compromised vendor account, trusted partner, or employee account can pass DMARC while delivering a fraudulent invoice, credential request, or malicious link. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 39% of breaches across the full attack chain, which is why an authenticated message deserves the same scrutiny as an unauthenticated one.

Forwarding and third-party delivery create legitimate failures. Mailing lists, ticketing systems, and marketing platforms can alter the envelope sender or message body, causing SPF or DKIM alignment to fail. That failure does not prove a cyberattack, and aggregate reports supply the evidence needed to distinguish broken mail flow from unauthorized sending.

Authentication proves where a message claims to originate without proving the request inside it is safe. Adaptive Security closes that gap with cybersecurity awareness training built around real employee decisions.

Explore the platform

DMARC Setup Prerequisites: Inventory Every Legitimate Email Sender

Before any policy reaches production DNS, the organization needs a written list of every system that sends email with its domain in the visible From address. That inventory drives the SPF and DKIM work, the vendor conversations, and the eventual enforcement decision. A complete sender map keeps legitimate invoices, password resets, recruiting messages, and customer notifications from failing authentication once DMARC enforcement begins.

Discover Every System That Sends Mail for the Domain

Sender discovery is the controlling step because DNS records cannot authenticate a service nobody knows exists. Useful starting points include the domain registrar, the Google Workspace or Microsoft 365 tenant, mail server logs, and any existing DMARC reports. Interviews with marketing, finance, sales, customer support, HR, IT, legal, and regional business units surface the rest.

Routine and exceptional senders both belong on the list. Marketing automation platforms deliver newsletters and campaign messages, while CRM systems send lead notifications, sales sequences, and account updates. Transactional providers handle receipts, invoices, shipping notices, password resets, and multifactor authentication codes.

Support desks send ticket updates, satisfaction surveys, and escalation notices, and HR platforms deliver recruiting messages, benefits information, and payroll alerts. According to the FBI's 2025 Internet Crime Report (released April 2026), cyber-enabled fraud accounted for almost 85% of all losses reported to IC3, totaling $17.7 billion (up from $13.7 billion in 2024), and business email compromise (BEC) remains the persistent risk at the costly center, accounting for $3.046 billion in losses (24,768 incidents, averaging $123,000 per case). Invoice and payroll streams therefore deserve the closest attention during discovery.

Systems outside the major cloud applications matter just as much. Printers and scanners that email documents, on-premises applications, ERP systems, monitoring tools, backup platforms, data-loss prevention alerts, and custom scripts all send mail. Subsidiaries, acquired companies, and agencies can also send as the parent domain, and a forgotten regional marketing account creates the same failure as a misconfigured production server.

Mail-flow evidence outperforms interviews alone. A review of the last 30 to 90 days of outbound messages, SMTP relay logs, application configuration files, and vendor administration consoles exposes senders that no team remembers. Message headers hold the detail worth capturing, including the visible From address, Return-Path, Authentication-Results, and DKIM-Signature fields.

Infrequent systems fail rollouts most often, so the review window should account for quarterly investor communications, annual benefits notices, and emergency status alerts. Every sending service then needs one record in a central register. Capture these fields:

• Sender and purpose: Application name, message type, and business process;
• Sending domain: Visible From domain, envelope-from or Return-Path domain, and DKIM signing domain;
• Authentication method: SPF, DKIM, both, or neither;
• DNS change required: SPF include, DKIM selector, custom return path, delegated subdomain, or vendor-side configuration;
• Business owner: Team, named administrator, and vendor contact responsible for approval and renewal;
• Test status: Not started, configured, passed, failed, or retired, with the test date and evidence location.

An unconfirmed sender is a production dependency rather than a low-priority exception. When a system cannot be tied to a business owner, authentication work should pause until someone establishes who still uses it. Retiring abandoned services reduces reporting noise and limits the number of vendors authorized to send as the organization.

Confirm SPF and DKIM Readiness Before Setting Up DMARC

SPF and DKIM must work before DMARC can enforce sender identity. SPF authorizes sending infrastructure through DNS, while DKIM adds a cryptographic signature to the message. Google Workspace's DMARC guidance requires SPF or DKIM first and recommends authenticating messages for at least 48 hours before enabling the policy.

Each sender needs its envelope-from domain verified, also called the Return-Path or bounce domain. SPF authenticates that envelope sender rather than the address a recipient sees in the From field, so a vendor can pass SPF and still fail DMARC when its envelope-from domain does not align. The register should record the exact domain and subdomain, including whether the vendor uses a shared bounce domain or offers a custom return path.

The DKIM-Signature header carries the second half of the picture. The value after d= identifies the DKIM signing domain, and the selector after s= identifies the public key in DNS. A vendor that signs with its own domain can still pass DMARC when the signing domain aligns with the protected From domain through a delegated or branded subdomain.

A signature alone settles nothing. The signing domain must match the organizational domain under the alignment mode named in the DMARC record. Testing every sender with a live message to a controlled mailbox is the only reliable confirmation, and the complete headers should document whether SPF passes, DKIM passes, and DMARC alignment passes.

Production workflows deserve the test instead of a vendor's preview tool. A CRM campaign, support ticket, invoice, and password reset can use different sending paths even when one vendor manages all four. Google defines relaxed SPF alignment as a match between the From domain and the envelope-from domain or one of its subdomains, and relaxed DKIM alignment similarly accepts the DKIM d= domain or one of its subdomains.

Strict alignment requires an exact match, so it suits organizations that have documented every approved sender and built a deliberate domain structure. DNS propagation and repeated message testing both need time before enforcement. Messages should go out from every workflow, with headers reviewed at multiple receiving providers and forwarding behavior checked separately, until the register shows which senders pass and which require remediation.

Establish Ownership for Third-Party Authentication

Third-party authentication fails at the boundary between the DNS team and the vendor's application team. Assigning one internal owner per sender fixes accountability, and that person collects the vendor's exact SPF, DKIM, envelope-from, and DNS instructions. Those instructions belong in the sender record alongside the contract owner and escalation contact.

Four questions settle most vendor relationships before approval:

1. 1Which domain appears in the envelope-from or Return-Path?
2. 2Can the service use a custom return path under the protected domain?
3. 3Which domain appears in the DKIM d= value?
4. 4Can the service sign with a custom DKIM domain and selector?

A vendor that supports neither a custom DKIM domain nor a custom return path cannot deliver aligned authentication for the visible From domain through its normal infrastructure. Broadening SPF or weakening the policy to accommodate one application is the wrong trade. The workable options are routing the mail through an approved relay, sending from a vendor-owned subdomain with a documented policy, replacing the service, or keeping the sender outside enforcement while the business formally accepts the delivery risk.

SPF ownership belongs in one place. Each domain should have one authoritative SPF record, and adding a second TXT record does not create a second authorization list. Every vendor should supply the smallest required include or IP range, retired services should come out, and nested lookups deserve review before any change is published.

Forwarding services and mailing lists need separate testing because they alter the message path. Forwarding breaks SPF when the forwarding server is not authorized by the original sender's SPF record, and mailing lists can modify the subject or body and invalidate DKIM signatures. DMARC can still pass when DKIM survives and aligns, so durable DKIM signing deserves priority for messages likely to be forwarded or redistributed.

Each test belongs in the register with the message ID, date, recipient environment, header evidence, owner approval, and remediation deadline. Senders earn approved status only after SPF or DKIM passes and at least one method aligns with the visible From domain. Unsupported vendors are exceptions with a compensating plan instead of successful senders.

This preparation creates the evidence for the DNS change. Organizations that centralize these records with their existing identity and application integrations can repeat the review as vendors, domains, and subsidiaries change.

An undocumented sending service is the most common reason a DMARC rollout stalls or breaks business mail. Adaptive Security surfaces the human exposure a sender inventory cannot reach.

Book a demo

How to Check for an Existing DMARC Record Before Setting Up DMARC

Duplicate and malformed records are common in organizations where several teams have touched DNS over the years, and a second policy record can silently disable enforcement. Querying _dmarc.yourdomain.com for every domain under management establishes what is actually published today. That check also separates DNS publication errors from authentication failures, because a correctly published policy can still report SPF or DKIM alignment problems.

Find an Existing DMARC Record

Start with the exact DMARC host name for each controlled domain. On macOS or Linux, the command is dig TXT _dmarc.yourdomain.com, and on Windows it is nslookup -type=TXT _dmarc.yourdomain.com. A public DNS inspection tool accepts the same host name, and the DNS zone in the provider dashboard will show a TXT record whose host is _dmarc.

A valid DMARC record begins with v=DMARC1, followed by policy tags such as p=none, p=quarantine, or p=reject. Record the complete response before changing anything, including reporting destinations such as rua=mailto:dmarc@yourdomain.com. A response showing NXDOMAIN or no matching TXT answer means the name publishes no policy today, which does not prove that every sending domain is ready for one.

A second resolver is worth using when testing a recent change. Comparing dig @1.1.1.1 TXT _dmarc.yourdomain.com with dig @8.8.8.8 TXT _dmarc.yourdomain.com exposes caching differences, and the authoritative nameserver settles any disagreement. DNS inspection tools and dashboards provide useful visibility, while command-line queries show the record that public resolvers actually return.

Resolve Duplicate or Overlong Records

A DMARC policy must resolve as one valid policy at the target name. Publishing two separate TXT records that both begin with v=DMARC1 does not create a stronger policy. RFC 9989, the DMARC core specification published in May 2026, states that receivers discard multiple DMARC policy records returned for the same target, so duplicates can leave a domain with no enforceable result at all.

Two records call for a merge instead of a deletion at random. Compare the tags, identify the intended enforcement level and reporting destinations, then combine the required directives into one record. Unrelated TXT records, such as domain-verification or SPF values, stay separate, and SPF belongs at the root domain instead of inside the DMARC value.

DNS dashboards often display a long DMARC value as several quoted strings, such as "v=DMARC1; p=none; rua=mailto:" "dmarc@yourdomain.com". Those strings are segments of one TXT record instead of multiple policies. Preserve the provider's segmentation when editing, and avoid adding quotation marks inside the policy unless the provider explicitly requires them.

Visual wrapping in a dashboard is not evidence of a problem, so inspect the returned DNS answer to confirm that the segments reassemble into one continuous value with no missing semicolons, spaces, or characters. A malformed or truncated TXT value is a DNS publication problem, repaired in the record itself. A policy that resolves correctly while producing dkim=fail, spf=fail, or alignment failures is an email authentication problem, repaired in the sender configuration.

Set a Practical Initial TTL

Lowering the TTL before the first change makes an error correctable without waiting through a long cache period. A practical starting point is 300 seconds, or five minutes, where the DNS provider permits it. That value can stay in place through initial validation and rise again once the record resolves consistently and the domain's mail streams have been reviewed.

TTL controls how long recursive resolvers can reuse a cached answer. It does not force every resolver to refresh immediately, and a resolver holding the previous record will keep returning it until its stored TTL expires. Testing from more than one network and waiting through the old TTL prevents a caching artifact from being mistaken for a broken record.

The check applies separately to every organizational domain, delegated sending domain, and important subdomain. A policy at yourdomain.com can influence subdomains through DMARC's organizational-domain rules and sp= behavior, while a record published at _dmarc.mail.yourdomain.com takes precedence for that subdomain. A parent-domain query therefore proves nothing about the policy each subdomain actually receives.

Internationalized domains require one additional check. The query should use the correctly encoded ASCII-compatible form, known as Punycode, whenever the DNS tool or provider expects that representation. A visually correct Unicode name can point to a different DNS label or fail to resolve when it is encoded incorrectly.

Create the DMARC DNS TXT Record at _dmarc.yourdomain.com

Creating the record follows a fixed order: prepare a policy string, open the authoritative DNS console for the domain, choose a TXT record, enter _dmarc as the host, paste the value, and save. Monitoring mode comes first so that authentication results are visible before receiving servers are asked to quarantine or reject anything. The report destination deserves attention at this stage as well, because aggregate reports can carry large volumes of XML and expose details about sending infrastructure.

Add the Minimum DMARC Record

A DMARC record requires the v and p tags. The v tag identifies the protocol version and must be DMARC1. The p tag tells receiving mail servers what to do when a message claiming to come from the domain fails evaluation, and its values are none, quarantine, and reject.

An initial monitoring policy looks like this:

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

Replace yourdomain.com with the protected domain and use a mailbox or group that already exists. The rua tag sends aggregate reports to the listed address, and those reports summarize sending sources, SPF and DKIM results, alignment outcomes, and the disposition applied by receiving providers. Google Workspace recommends including rua so administrators can identify legitimate senders and authentication failures while the policy remains at none, as explained in its Google Workspace DMARC record guidance.

The Google Admin console is not the publication point unless Google also hosts the DNS. DMARC is published in the public DNS zone for the domain, usually through the registrar or DNS provider that manages the nameservers. GoDaddy, Amazon Route 53, Squarespace, Namecheap, and other providers each expose that zone through their own DNS management console.

According to IBM's Cost of a Data Breach Report 2026, phishing remained the top cyberattack vector for the fourth consecutive year, while voice and SMS phishing specifically appeared in 17% of attacks. That persistence is the reason SPF and DKIM should authenticate every legitimate sender before the policy is published. Google Workspace advises allowing 48 hours after configuring SPF and DKIM, because applying a policy before identifying all senders can disrupt delivery across marketing automation, payroll, customer support, ticketing, and CRM platforms.

The DNS interface may label the host field as Name, Host, Hostname, Alias, or Record name. Enter _dmarc when the provider automatically appends the domain name, and enter _dmarc.yourdomain.com when the provider expects a fully qualified hostname. If the console turns the entry into _dmarc.yourdomain.com.yourdomain.com, remove the duplicated domain before saving.

Set the record type to TXT. MX, CNAME, and provider-specific "DMARC" shortcuts do not qualify unless the DNS host's documentation confirms that the shortcut publishes the same TXT syntax at the _dmarc label.

Paste the value as one logical string. Some DNS consoles display a long TXT value in multiple visual segments, which is acceptable when the provider joins those segments in DNS. Separate TXT records for v, p, and rua are not valid, because a domain should have one policy record at _dmarc with tags separated by semicolons.

Add Optional Tags Only When They Solve a Defined Need

Optional tags should support a rollout decision, a subdomain policy, or an alignment requirement. The most useful additions are pct, sp, aspf, and adkim. The ruf tag requires more caution because support varies by receiving provider.

The pct tag controls the percentage of failing messages that receive the stated policy:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

This asks receiving servers to apply quarantine to 25% of messages that fail DMARC. Google Workspace defines pct as a whole number from 1 to 100, and the policy applies to 100% of messages when the tag is omitted. The value rises as reports confirm that legitimate senders pass authentication, ending at pct=100 once the policy is fully deployed.

pct is a legacy tag. RFC 9989 deprecates it, along with rf and ri, replacing it with a testing flag: t=y signals that the domain owner is testing, so failures are handled one level below the stated policy, and t=n (the default) applies the policy in full. Current receivers still honor pct, so the staged approach in this guide remains workable during the transition, but new records should plan for t and drop pct at the next DNS edit.

The sp tag applies when subdomains need a different policy from the organizational domain:

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

This applies quarantine to the primary domain while leaving subdomains in monitoring mode. Without sp, subdomains inherit the parent domain's p policy. The exception suits subdomains that are still being inventoried or controlled by separate teams, since inheritance otherwise reduces policy gaps.

The aspf and adkim tags control alignment. Alignment compares the domain visible to the recipient in the From: header with the domain authenticated by SPF or DKIM. In relaxed mode, represented by r, organizational domains can align, so From: billing@yourdomain.com can align with an SPF or DKIM domain such as mailer.yourdomain.com.

A relaxed record looks like this:

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

Relaxed alignment is the default and accommodates legitimate providers that send through subdomains. It is a practical starting point for organizations that use multiple mail platforms and have not yet verified every sender's exact domain behavior.

Strict alignment uses s and requires an exact domain match:

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

With strict SPF alignment, the envelope sender or Return-Path domain must exactly match the From: domain, and with strict DKIM alignment the d= value must match it exactly. Strict alignment suits subdomains managed by another entity or high-risk brand domains that require tighter control. It deserves testing before enforcement because it exposes overlooked SaaS senders.

The ruf tag requests message-level failure reports, sometimes called forensic reports:

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

Adding ruf does not guarantee reports. Google Workspace states that Gmail does not support the tag, so it creates no Gmail failure-report workflow. Message-level reports can also contain sensitive message details, so ruf belongs in a record only after the receiving providers and reporting platform are confirmed to support it, routed to a separately protected destination.

Secure the Report Destination Before Publishing

The report destination decides whether DMARC becomes an actionable monitoring system or an unmanaged mailbox filled with machine-generated messages. The choice among a dedicated mailbox, a protected group, and a specialized reporting platform depends on volume, staffing, and analysis requirements. Each option carries a different operating cost.

A dedicated mailbox works for a small domain with limited outbound email. Access should stay restricted to security or messaging administrators, with multifactor authentication required, external forwarding disabled, and a retention period matched to investigation and compliance needs. An individual employee's mailbox is unsuitable because ownership changes, accidental deletion, and offboarding all interrupt reporting.

A protected group works when several administrators need access. Posting permissions should be limited, public membership prevented, external delivery restricted, and recipients documented. A group improves coverage during leave and on-call rotations, although it does not interpret XML, identify unknown senders, or distinguish a legitimate service from an unauthorized source.

A reporting platform fits domains that generate large volumes of email, use many third-party senders, or require trend analysis across multiple domains. Google Workspace notes that large organizations can receive hundreds or thousands of reports daily, which makes automated parsing important. Data retention, encryption, administrator roles, export controls, and support for aggregate XML all deserve confirmation before reports are directed there.

The reporting address itself carries one DNS requirement. When the rua address belongs to the same domain as the DMARC record, publication is straightforward, and when reports go to a different domain, the external reporting domain must publish a DNS record authorizing the protected domain to send reports there. Without that authorization, providers can discard the reports to prevent abuse of third-party reporting addresses.

After the TXT record is saved, a query against _dmarc.yourdomain.com should return a value containing v=DMARC1, p=none, and the intended rua address. Confirm that the host was not duplicated, that the value was not split incorrectly, and that only one DMARC record is visible.

A reporting address nobody reviews turns email authentication into paperwork while spoofed messages keep arriving. Turn reported messages into verified triage signals and targeted follow-up with Adaptive Security.

Take a self-guided tour

Publish a Monitoring-Only DMARC Policy and Begin Reviewing DMARC Reports

The monitoring period is where how to set up DMARC stops being a DNS exercise and becomes an evidence-gathering one. Receiving systems start returning aggregate data about every source using the domain, and that data decides when enforcement is safe. Treating this stage as discovery protects valid business email, because an incomplete sender inventory only becomes visible once reports arrive.

What a Monitoring-Only DMARC Policy Actually Does

A monitoring policy uses p=none at the _dmarc label:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The p=none value does not instruct receiving systems to quarantine or reject messages that fail evaluation. Those messages continue through the receiving system's normal processing while reporting supplies visibility into what happened. A failed check is not proof of malicious activity, because a legitimate marketing platform, help desk, payroll provider, or CRM system can fail alignment when its sending configuration is incomplete.

The UK National Cyber Security Centre's email security and anti-spoofing guidance describes DMARC as a mechanism that tells receiving email servers how to handle messages failing SPF or DKIM while generating reports about email handling. For parked or inactive domains, a monitoring record creates visibility without interrupting mail that should not exist yet could reveal attempted spoofing. Verifying the public DNS record afterward confirms the intended policy, reporting address, and syntax, since a typo in the hostname or reporting address leaves the domain without usable monitoring.

Open the First Monitoring Window

The first monitoring window begins when receiving systems discover the DNS record and process messages claiming to use the domain. Reports rarely arrive immediately after publication. They often come in recurring batches, commonly daily, although cadence varies by receiving organization, reporting system, message volume, and local processing schedules.

One quiet day provides no meaningful baseline. The window should cover normal business cycles, including weekdays, weekends, recurring invoices, automated notifications, and monthly or quarterly communications. A domain used for payroll, billing, or customer alerts can have important senders that never appear during a short test.

When nothing arrives after a reasonable observation period, three checks resolve most cases: the public DNS record, the ability of the rua mailbox or reporting service to receive messages, and the authorization of that address to receive reports for the domain. Organizations managing several domains should monitor each one separately, since a parent-domain record can affect subdomains depending on the sp setting while a subdomain can publish its own policy.

Accountability decides whether the window produces anything useful. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of highly resilient organizations indicate that board members receive regular cybersecurity updates, and 48% report that board members are actively engaged with cybersecurity issues. Recording the domain, policy, reporting address, and publication date in an implementation tracker gives that oversight a factual baseline to compare against later changes.

Read What Aggregate DMARC Reports Contain

Aggregate reports, often called rua reports, summarize activity over a reporting period. They support trend analysis over investigation of one individual message. A report can show which systems sent mail using the domain, how many messages each source sent, and whether those messages passed authentication.

Six fields carry most of the meaning:

• Source IP: The sending server or service that transmitted the messages;
• Message count: The number of messages represented by that record during the reporting period;
• SPF result: Whether the sending IP was authorized by the domain's SPF policy;
• DKIM result: Whether the message carried a valid DKIM signature;
• Identifier alignment: Whether the authenticated SPF or DKIM domain aligned with the visible From domain;
• Policy disposition: Whether the receiving system applied none, quarantine, or reject to the messages.

The policy disposition requires careful interpretation. With p=none, a report can show a failure alongside a disposition of none because the published policy told the receiving system not to quarantine or reject. That combination reports a failure while following the monitoring instruction without indicating a pass.

Authentication failure and sender legitimacy are separate questions. An unfamiliar source IP that fails SPF and DKIM deserves investigation, while a familiar cloud service that fails alignment usually needs configuration work. Contacting the service owner, confirming authorization, and configuring SPF or DKIM according to the provider's documented process resolves most of these cases.

Broad third-party SPF mechanisms added merely to clean up a report expand the set of systems permitted to send as the domain, which is the opposite of the intended outcome. Aggregate reports also expose forwarding and third-party delivery patterns, where a message passes DKIM but fails SPF after forwarding, or passes SPF but fails DKIM because a service modified the message. DMARC passes when at least one authenticated path both passes and aligns, so the combined result matters more than one failed check.

Decide Whether Forensic ruf Reports Are Worth Enabling

Forensic reports can contain message-level details such as headers and portions of the failed message. That context makes a specific spoofing attempt easier to investigate, and it also creates privacy, volume, and handling obligations that many organizations are not ready to meet. The decision belongs to whoever owns data handling rather than to whoever edits DNS.

Aggregate reporting works as the default channel for broad visibility. It provides enough information to map legitimate senders, identify unauthorized infrastructure, and measure progress without routinely collecting message content. It also creates a more predictable workload, because one report can summarize many messages.

Forensic reporting deserves consideration only after an organization can receive, restrict, retain, and delete message-level data appropriately. A high-volume domain can generate more alerts than an analyst can review, turning a useful signal into an unmanageable queue. Access rules, retention periods, storage locations, and regional data-handling requirements all need answers before the tag is published.

The monitoring period ends with a verified sender inventory in preference to an automatic move to stricter enforcement. Every material source needs review, every legitimate SPF, DKIM, and alignment failure needs resolution, and every unexplained source needs investigation until the domain's legitimate sending activity is clear.

Monitoring data shows which brands and departments cyberattackers impersonate, and that intelligence expires if nothing acts on it. Adaptive Security turns those patterns into targeted phishing simulations.

Explore the platform

Analyze DMARC Reports for Authentication and Alignment Failures

Reading reports correctly means separating authentication from alignment before touching the policy. A source that authenticates perfectly can still fail DMARC, and a source that fails SPF can still pass. Aggregate XML, individual message headers, and the business context behind each sender together determine which failures are configuration problems and which are unauthorized sending.

Read Aggregate Data Without Confusing Authentication With DMARC

Aggregate reports show how receiving systems evaluated messages that used the domain. The sending IP, message count, and policy result come first, followed by the authenticated domains and the visible From domain. A message can pass SPF or DKIM authentication and still fail DMARC when the authenticated domain does not align with the domain a recipient sees.

Google Workspace Admin's DMARC alignment guidance defines alignment as the relationship between the domain in the From header and the domain authenticated by SPF or DKIM. DMARC passes when at least one path succeeds in both ways: SPF authentication plus SPF alignment, or DKIM authentication plus DKIM alignment. A raw SPF pass by itself settles nothing.

A redacted aggregate record might look like this:

<record>

  <row>

    <source_ip>203.0.113.24</source_ip>

    <count>184</count>

    <policy_evaluated>

      <disposition>none</disposition>

      <dkim>pass</dkim>

      <spf>fail</spf>

    </policy_evaluated>

  </row>

  <identifiers>

    <header_from>example.com</header_from>

    <envelope_from>mailer.vendor.example</envelope_from>

  </identifiers>

  <auth_results>

    <dkim>

      <domain>example.com</domain>

      <selector>news2026</selector>

      <result>pass</result>

    </dkim>

    <spf>

      <domain>mailer.vendor.example</domain>

      <result>pass</result>

    </spf>

  </auth_results>

</record>

This source sent 184 messages, and the receiving system recorded SPF authentication as a pass for mailer.vendor.example. The visible sender was example.com, so SPF does not align under strict mode. DKIM authenticated with d=example.com, and supplied the aligned path required for DMARC to pass.

The policy_evaluated block describes the DMARC decision path instead of the underlying protocol result. The dkim and spf values inside it are evaluated DMARC outcomes, while the detailed auth_results values identify the authenticating domain. Reading both together shows whether an authenticated path aligned with the visible sender.

A <disposition>none</disposition> value is not proof that every message passed. It can mean the receiving system observed a failure and delivered the message anyway because the published policy was monitoring-only. According to Sumsub's 2025–2026 Identity Fraud Report, sophisticated fraud surged 180% YoY including deepfakes, synthetics, and telemetry tampering, so an unexplained source in a report deserves the same scrutiny as any other anomaly.

Grouping each source by sending IP, authenticated domain, visible From domain, and message volume prevents a common error. One IP can serve multiple customers, and one vendor can use several IP ranges. Source grouping stops teams from approving an entire provider after reviewing one authenticated stream.

Diagnose Alignment With Relaxed and Strict Modes

Alignment compares three domains that appear in different parts of an email. The visible From domain is the address a recipient sees, the SPF-authenticated domain is normally the envelope sender represented by the Return-Path or bounce domain, and the DKIM-authenticated domain is the value in the signature's d= tag. Every alignment decision comes down to how those three relate.

Consider this redacted header:

From: Billing <billing@example.com>

Return-Path: <bounce@send.example.com>

DKIM-Signature: v=1; d=send.example.com; s=s1; ...

Under relaxed alignment, example.com and send.example.com share the same organizational domain, so SPF and DKIM can align when authentication passes. Under strict alignment, neither authenticated domain exactly matches example.com, so both checks fail. The aspf tag controls SPF alignment and the adkim tag controls DKIM alignment, with r for relaxed and s for strict.

Publishing those values explicitly makes the operating choice visible to the team reviewing DNS, even though relaxed is the default when the tags are omitted. Strict alignment suits situations where subdomains are managed separately or where mail sent from a subdomain must not inherit alignment from the parent domain.

The most confusing failure occurs when SPF and DKIM both pass individually while DMARC fails:

Authentication-Results: receiver.example;

  spf=pass smtp.mailfrom=vendor-mail.example.net;

  dkim=pass header.d=vendor-mail.example.net;

  dmarc=fail header.from=example.com

Both protocols authenticated the message, and neither authenticated example.com. The vendor proved control of vendor-mail.example.net instead of the domain displayed to the recipient. The repair is a custom Return-Path and DKIM configuration at the vendor, or a routing change to infrastructure that signs with the protected domain, since adding vendor IP addresses to SPF cannot fix a DKIM domain mismatch.

Forwarding creates the opposite pattern. A forwarding service can preserve the DKIM signature while changing the envelope sender or source IP, causing SPF to fail while DKIM and DMARC pass. Mailing lists can modify content and break DKIM while also replacing the Return-Path, so those paths deserve message-level review instead of a blanket unauthorized-sender label.

Prioritize Remediation by Source Type and Failure Pattern

Remediation starts with ownership instead of with the largest number in the report. Each source needs checking against the mail inventory, confirmation that the business still uses it, and evidence that the provider authenticates with a domain aligning to the visible From domain. Volume indicates urgency without indicating legitimacy.

Use this triage order:

• Known legitimate sender: Confirm its SPF authorization, custom Return-Path, and DKIM d= value, preferring an aligned DKIM signature because it survives many forwarding paths better than SPF;
• Unauthorized source: Check whether the IP belongs to a forgotten application, a compromised account, or a genuine spoofing attempt, then remove abandoned services and investigate active infrastructure;
• Forwarding or mailing-list path: Compare the original sender, final recipient, and message modifications, preserving aligned DKIM and documenting expected SPF failures;
• Misconfigured vendor: Give the application owner the exact failing domain pair, selector, and message path, then verify the change in the next aggregate reports;
• Unknown high-volume source: Correlate the source IP, authenticated domain, timestamps, and business records before allowing it into SPF or approving its sending domain.

Individual headers confirm what aggregate reports summarize. In a message under investigation, the From, Return-Path, DKIM-Signature, and Authentication-Results fields tell the whole story. A header showing header.from=example.com, smtp.mailfrom=example.com, and header.d=example.com describes a clean aligned path when SPF and DKIM pass.

A header showing header.d=vendor.example or smtp.mailfrom=bounces.vendor.example requires an alignment decision even when the authentication results say pass. A remediation log covering the source, owner, authentication result, alignment result, required change, and verification date keeps that decision retrievable. This evidence trail documents every exception and stops the same vendor from reappearing as an unexplained failure months later.

A DMARC reporting dashboard makes these patterns easier to track, although the decision still depends on matching each source to a legitimate business purpose. Raising p while legitimate sources still fail both aligned paths converts a reporting problem into a delivery incident. Correcting the highest-volume known senders, investigating unexplained sources, and reviewing forwarding behavior across multiple reporting cycles turns enforcement into a controlled decision.

Aggregate reports name the vendors being impersonated, yet employees rarely see that intelligence. Adaptive Security routes reported messages through automated triage and returns coaching to the affected employees.

Book a demo

Fix Legitimate Sender Failures Before Increasing DMARC Enforcement

Every legitimate failure resolves into one of three causes: SPF authentication, DKIM authentication, or alignment. Correcting the sender's own configuration is the only durable repair, since weakening the domain policy to accommodate one vendor lowers protection for every other sender. According to the APWG's Phishing Activity Trends Report, 4th Quarter 2025, 3.8 million phishing attacks were observed during 2025, up slightly from 3.76 million in 2024, which is the volume a permissive policy invites.

Correct Third-Party Vendor Authentication

Third-party senders cause most legitimate failures because a vendor sends on the organization's behalf without authenticating as the protected domain. The failing message supplies the diagnostic data worth recording: the visible From: domain, the envelope-from or return-path domain, the DKIM signing domain in the d= value, the sending IP, the vendor name, and the authentication results. A vendor that passes SPF or DKIM while failing alignment is not yet fixed.

Vendors should supply domain-specific instructions instead of a generic include that administrators paste and hope for. Use this order of preference:

• Custom DKIM signing: Publish the vendor's DKIM selector record in DNS, activate signing for the protected domain in the vendor console, and confirm that messages carry a signature with d=yourdomain.com or an authorized subdomain;
• Custom envelope-from or return-path: Configure a bounce domain such as mail.example.com or bounce.example.com and publish the vendor's required DNS records so the envelope-from domain aligns with the visible From: domain;
• SPF authorization: Add the vendor's documented include: or sending IP range only when the vendor requires it and the organization has approved the service.

Google's DMARC guidance for third-party services directs administrators to authenticate the provider, align the envelope sender, and add the provider's sending infrastructure to SPF. Where a vendor cannot support any aligned path, the remaining options are changing the visible From: address to an aligned subdomain or routing the message through infrastructure that can sign for the domain.

Every vendor is an authorization relationship with a defined owner, business purpose, data classification, sending volume, authentication method, and renewal date. Unused SPF includes, DKIM selectors, and vendor access should come out when a contract ends. Familiarity is not a security property, because a compromised vendor account or an abused sending platform produces authenticated mail that the organization never approved.

Handle Forwarding and Mailing Lists Without Weakening the Policy

Forwarding changes a message's path and sometimes its headers, so SPF can fail even when the original sender was authorized. The forwarding server usually sends from its own IP address rather than the original sender's SPF-authorized infrastructure. DKIM often remains intact, which makes aligned DKIM the stronger control for forwarded mail.

Google's sender guidance recommends authenticating the sending domain and following forwarding practices in preference to allowlists or exceptions. Mailing lists create a separate problem because they can modify the subject, body, or headers, invalidating DKIM while the list server's IP fails the original sender's SPF check. Configuring the list service to preserve DKIM signatures, using ARC where the intermediary is trusted, and requiring the list to identify itself accurately together reduce the damage.

Authenticated Received Chain, or ARC, allows a trusted intermediary to record the authentication results it observed before forwarding a message. ARC does not make an untrusted sender legitimate, so it should never become a blanket bypass for forwarded mail.

Services that cannot customize DKIM or the envelope-from domain need isolation in place of exceptions. A dedicated subdomain such as updates.example.com with a narrowly scoped policy, or a route through an approved relay that can authenticate the traffic, preserves protection for the primary domain. The service, owner, expected recipients, data type, authentication limitation, compensating control, and review date all belong in the documentation.

Adding every vendor to SPF is a false economy. SPF has a finite DNS lookup budget under the SPF specification, and nested vendor includes consume it without making the record easier to govern. Tracking each include, removing duplicates, preferring vendors that consolidate their infrastructure, and reviewing the record after provider changes keeps it maintainable.

Careless SPF flattening creates its own failure mode, because hard-coded IP addresses go stale when a vendor changes its sending network. Where flattening is unavoidable, automated updates and drift monitoring become mandatory. Aligned DKIM should remain in place as the second authentication path.

Verify Each Fix With Controlled Messages

After a vendor or relay configuration changes, controlled messages to test mailboxes at multiple receiving providers confirm the result. Transactional mail, marketing mail, password resets, support tickets, forwarded messages, and mailing-list traffic each need separate tests. Complete headers should confirm that the visible From: domain aligns with either the DKIM d= domain or the SPF envelope-from domain.

A configuration change is not a licence to jump straight to rejection. The message must pass SPF or DKIM with alignment at the receiving system, and aggregate reports must show the sender's normal traffic behaving the same way. Google recommends beginning deployment with p=none, monitoring authentication results, and progressing toward quarantine or reject as legitimate sources pass.

A limited pct value helps during rollout only when the organization understands which traffic it covers, and every policy change belongs in the change-management record. For each repaired sender, the before-and-after headers, DNS changes, vendor ticket, test recipients, test date, result, and accountable owner form the evidence package. Monitoring continues after the fix, because vendors change infrastructure, forwarding paths shift, and forgotten applications reappear during business projects.

A sender that fails again should have its own traffic quarantined or its authorization removed instead of lowering the domain-wide policy. The end state is a maintained inventory where every legitimate sender authenticates with aligned SPF or DKIM, every trusted intermediary has a documented reason for ARC treatment, and every unresolved source has an owner and an expiration date.

Vendor mail that fails alignment quietly trains employees to accept unauthenticated messages as normal business traffic. Counter that habit with Adaptive Security's cybersecurity awareness training built on real sending patterns.

Take a self-guided tour

How to Set Up DMARC Enforcement: Move From p=none to p=quarantine and p=reject Safely

Enforcement is a controlled rollout rather than one DNS change. Legitimate SPF and DKIM failures get corrected first, then the policy advances through quarantine and rejection using pct, report reviews, and a named rollback owner. Current documentation from the DNS host, email provider, and third-party senders belongs alongside the standard, because report handling and policy processing vary by provider.

Move to Quarantine After Correcting Known Failures

The p=none value is a monitoring policy. It tells receiving mail systems to deliver messages normally while reporting whether messages claiming to come from the domain pass or fail. It stops no spoofed mail, so it functions as an inventory and repair phase without providing protection against impersonation.

Before enforcement increases, every legitimate sender in the aggregate reports needs identification. Marketing platforms, payroll systems, customer support tools, ticketing systems, CRM applications, cloud services, scanners, and applications that send directly from the domain all qualify. For each one, SPF must include the correct authorized source or DKIM must sign the message with an aligned domain.

The p=quarantine value tells receiving systems to treat failing messages as suspicious, commonly placing them in spam or another review area rather than the inbox. It gives security teams an enforcement signal while preserving a recovery path for a misconfigured legitimate sender. The National Cyber Security Centre's guidance on marking spoof emails as spam recommends resolving authentication issues during this stage before progressing to rejection (NCSC, 2025).

The pct tag limits how much failing mail receives the quarantine treatment:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

This illustrative setting applies the requested policy to approximately 25% of messages that fail evaluation, rather than to 25% of all outbound mail. Receiving-system behavior differs, so the result deserves validation against current documentation for Gmail, Microsoft 365, and the systems most important to the organization.

The percentage should rise only after report review and a check of business workflows. A practical sequence is 25%, 50%, 75%, and 100%, although a smaller organization with a well-documented sender inventory can use fewer stages. Each stage needs enough time to cover routine traffic, scheduled campaigns, monthly invoices, and unusual sending patterns, because a critical sender that transmits once a quarter will not appear in a week of data.

Move to Reject Only After Quarantine Is Stable

The p=reject value is the strongest policy available. It instructs receiving systems to refuse messages that fail evaluation instead of delivering them or filing them in spam. That decisiveness blocks direct spoofing, and it also turns an overlooked legitimate sender into a delivery incident.

Speed matters on both sides of this decision. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds. A domain left at monitoring for months while the inventory stays untouched is a standing invitation to impersonation.

Before rejection is published, legitimate mail must be passing SPF or DKIM with the visible From domain aligned to the authenticated domain. Forwarded messages, mailing lists, automated notifications, and vendors that use the domain in the visible sender field all need confirmation. Each provider should supply its current SPF, DKIM, and DMARC implementation instructions in preference to an old configuration guide.

Google's current DMARC setup documentation advises organizations to begin with p=none, review reports, then update the receiver policy to quarantine or reject (Google Workspace, 2025). Rejection also starts with a limited percentage:

v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@example.com

The progression from 10% to 25%, 50%, 75%, and 100% depends on a report review at each stage. NCSC guidance recommends applying reject to a small percentage first, increasing it as genuine delivery is confirmed, and monitoring reports for at least four weeks after quarantine reaches 100% (NCSC, 2025). That period is a minimum checkpoint rather than an automatic deadline, and it should extend for organizations with seasonal campaigns, acquisitions, multiple email platforms, or low-volume senders.

A complete record might look like this:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@example.com

The rua destination should remain a monitored mailbox or approved reporting service throughout. Reports need to reach someone who can connect an authentication failure to an application owner, vendor, or business process, because an unreviewed mailbox turns an enforcement policy into guesswork.

Protect Subdomains With the sp Tag

The sp tag sets the policy for subdomains such as mail.example.com or events.example.com. When sp is absent, subdomains generally inherit the parent domain's policy. That inheritance works well where every subdomain follows the same authentication and ownership model, and it causes disruption where separate teams or providers manage subdomains.

Setting sp=reject extends the same strict protection to subdomains that the parent domain receives. A separate record on a subdomain makes sense only when that subdomain requires its own policy and the DNS hierarchy permits it. Documentation should capture who owns the subdomain, which services send from it, and how its SPF and DKIM records are maintained.

Parked and unused domains need a defensive policy even when they send no legitimate mail, since cyberattackers can use them for spoofing. A record such as v=DMARC1; p=reject; sp=reject; pct=100; with a reporting address provides both protection and visibility. Where the domain has no valid senders, enforcement can begin at 100% after verifying that no operational service depends on it.

Define Rollback Before Changing DNS

Rollback belongs in the plan from the beginning, since it corrects a sender problem without signalling that the rollout failed. Three named roles cover it: one owner who can authorize and publish a policy change, one technical operator who can edit DNS, and one communications contact who can notify affected teams. The previous DMARC value, DNS provider access path, change window, and escalation procedure all belong on record before quarantine or rejection is published.

When legitimate mail is affected after quarantine takes effect, lowering pct reduces enforcement temporarily, and returning to p=none suits a widespread delivery impact. The sender then needs identification, an SPF or DKIM correction, alignment confirmation with the visible From domain, and controlled test messages. The next available aggregate reports confirm the repair before quarantine is restored.

When legitimate mail is affected after rejection takes effect, reducing to p=quarantine beats repeatedly toggling records without diagnosis. Correcting the sender at its source, confirming that the provider's current instructions have been followed, and revalidating the full delivery path come next. Rejection then returns at a limited pct value with coverage increasing in measured stages.

Broadly adding unknown infrastructure to SPF or weakening alignment without understanding the consequence solves nothing, since every new sender expands the domain's trusted email surface. A vendor that cannot support aligned DKIM or an authorized SPF path needs an approved relay, a dedicated sending subdomain, or a replacement workflow. A written review schedule closes the rollout, covering continuous report monitoring, third-party sender reviews after vendor or platform changes, and parked-domain rechecks during domain-portfolio reviews.

Enforcement blocks forged senders while impersonation moves to text messages, voice calls, and collaboration tools that DNS never sees. Adaptive Security builds multi-channel readiness across those routes with realistic scenarios.

Explore the platform

How to Verify DMARC Success After Setup and Controlled Mail Testing

Anyone following how to set up DMARC reaches a point where confirmation matters more than configuration. Verification proves that every DNS change reached the resolvers recipients actually use and that real mail from every system authenticates and aligns.

Success means complete sender coverage, valid alignment, expected reports, and no unexplained disruption to legitimate mail. The presence of a TXT record proves none of those things on its own.

Validate the DNS Record From Multiple Resolvers

DNS validation confirms that recipients can retrieve the intended policy. Querying _dmarc.example.com through at least two independent resolvers, such as an internal resolver and a public one, exposes disagreements. A local answer can look correct while another resolver still holds an older cached response.

The result should contain one syntactically valid record beginning with v=DMARC1;, and each tag should match the change request. The p tag must show the intended policy, and the rua addresses, ruf if used, adkim and aspf alignment modes, pct percentage, and any sp subdomain policy all need confirmation. Duplicate records, unsupported tags, and accidental quotation marks inserted by the DNS management interface all need removal.

The same check belongs after the DNS provider reports the change as complete. Cached TTL values can produce mixed results for hours, so one successful lookup does not prove universal visibility. Recording the timestamp, resolver, returned value, and TTL gives change control the evidence it needs.

Keeping the DNS output from before and after the change, including screenshots or command-line results, lets a later investigation distinguish a policy error from normal propagation delay. Pairing that record review with phishing simulations extends validation to the human decisions that authentication cannot cover.

Send Controlled Test Messages From Every Sending System

Controlled messages establish whether real mail passes authentication and alignment. Separate tests belong to Microsoft 365 or Google Workspace, marketing automation, customer support platforms, payroll services, CRM tools, transactional providers, scanners, and any application that sends using the domain. One message from the primary corporate mailbox tests one path out of dozens.

The destination mailbox must expose complete headers, and more than one receiving provider should be involved, because receiving systems evaluate DMARC independently and apply different local handling. A normal message, a reply or forwarded message where relevant, and a representative high-volume notification together cover the realistic cases. Testing only the easiest path produces a false sense of readiness.

The resulting Authentication-Results header carries the verdict. A successful result identifies dmarc=pass and shows the authenticated domain aligned with the visible From domain. Where DKIM is not aligned, the SPF result and the envelope-from or return-path domain determine whether the message had a passing aligned path.

Arrival in the inbox is not a success signal. Delivery can occur because a provider accepted the message under local reputation rules, because the policy is still monitoring-only, or because the message passed SPF or DKIM without satisfying alignment. Complete headers for each test belong with the DNS change record.

Diagnose Message-Level Results Before Changing Policy

Message headers separate a publishing problem from a sender configuration problem. A dmarc=pass result means the receiving system found an aligned SPF or DKIM path, and it does not prove that every sender is covered or that aggregate reports will arrive at the expected mailbox. Three result values deserve specific handling.

A temperror result is a temporary evaluation failure, usually a DNS lookup timeout or an unavailable dependency, and it calls for a retest from another mailbox and resolver before any policy change. A permerror result is a configuration failure requiring correction, such as malformed syntax, multiple policy records, or an invalid DNS result. Loosening enforcement before identifying the failed component treats the symptom.

A bestguesspass result is not a genuine pass. It indicates that a receiver inferred what might have passed from available authentication signals, often when no valid policy was found. Only an explicit dmarc=pass result in the Authentication-Results header demonstrates that enforcement will work consistently.

Aggregate reports need the same confirmation, arriving at the address in rua and identifying all legitimate sending sources. Comparing report data with the sender inventory, investigating unknown sources, and checking for missing expected messages closes the loop. Legitimate mail that fails alignment needs its SPF, DKIM, or visible From configuration corrected before monitoring gives way to enforcement.

Accountability for that decision usually sits above the messaging team. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 30% of highly resilient organizations reported that board members hold personal liability in the event of cyber breaches, compared with 9% of organizations with insufficient resilience. A documented verification gate protects the people who carry that responsibility:

• Pass: One valid TXT policy is visible through multiple resolvers, intended tags are present, every major sender produces aligned authentication, aggregate reports arrive, and legitimate mail shows no unexplained disruption;
• Fail: The record is duplicated or malformed, resolvers return conflicting policies after the expected TTL, a sender produces temperror, permerror, or only bestguesspass, reports do not arrive, or a legitimate workflow is rejected without an identified cause.

Retaining the before-and-after DNS responses, resolver timestamps, complete message headers, test destinations, and report samples gives security and change-management teams a repeatable audit trail.

A passing authentication result says nothing about whether an employee should act on the message. Measure that judgment with Adaptive Security through reporting behavior instead of module completion.

Take a self-guided tour

Troubleshoot Common DMARC Setup Problems and Maintain Coverage

Learning how to set up DMARC includes the operational work that follows publication. A malformed policy, a missing report destination, or a forgotten vendor can leave spoofed mail unchallenged or push legitimate messages into quarantine and rejection. According to the APWG's Phishing Activity Trends Report, 1st Quarter 2026, 971,181 phishing attacks were observed in the first quarter of 2026, a 13.8% increase over the previous quarter, so a lapsed policy has an immediate cost.

Which DMARC Symptoms Indicate a Configuration Problem?

Every symptom traces to the record, a sender, or receiving-provider behavior, and that trace should happen before any policy change. This discipline prevents teams from weakening enforcement when the real issue is an undiscovered sender. The table below maps the symptoms that appear most often during and after a rollout.

A failure is not automatic evidence of malicious activity. It can indicate forwarding, a third-party platform configured with the wrong domain, or a vendor that signs with its own domain while sending on the organization's behalf. The critical diagnostic question is whether SPF or DKIM passed with alignment to the visible From domain.

How Should the DMARC Report Mailbox Be Operated?

The report destination is a monitored security function rather than an ordinary employee inbox. A dedicated address with restricted access, multifactor authentication, attachment scanning, forwarding controls, and a retention policy preserves the investigation window without allowing unbounded XML accumulation. A personal mailbox or a shared address with no designated owner fails that standard.

For a small domain with limited sending volume, weekly report review during rollout is sufficient. Each source IP, DKIM selector, and envelope domain gets checked against the sender inventory and classified as approved, unknown, forwarded, or retired. A reporting service becomes appropriate for organizations managing multiple domains, receiving more XML than analysts can inspect, needing historical trend analysis, or unable to map IP addresses to business owners reliably.

Provider selection has three practical criteria: exposure of raw reports, documented parsing logic, and support for export. No dashboard replaces independent DNS and message validation. Keeping p=none while unknown legitimate senders remain under investigation is the safer position, with quarantine and rejection following once the authorized-sender map is stable.

What DMARC Maintenance Cadence Keeps Coverage Current?

Coverage decays when the business changes faster than its DNS records. SPF, DKIM, and DMARC deserve weekly review during initial rollout and after each policy change. Once the configuration stabilizes, a monthly technical review and a quarterly confirmation with sender owners in marketing, finance, HR, customer support, and IT keeps the inventory accurate.

Certain events require confirmation regardless of the calendar: mail-platform migrations, domain acquisitions, SaaS integrations, regional launches, and outbound-relay changes. At each review, current reports get compared with the approved inventory, new SPF includes get inspected, active DKIM selectors get verified, and subdomain inheritance of the intended sp policy gets checked.

Stale vendors should come out promptly, exceptions need an owner and an expiry date, and high-value mail such as invoices, password resets, and executive communications deserves retesting. A current phishing simulation program reinforces the reporting behavior that helps employees flag suspicious messages while authentication handles sender identity.

Domains, vendors, and sending platforms change faster than most review cycles, and every gap is an opening. Track human risk continuously with Adaptive Security before exposure becomes an incident.

Book a demo

Extend DMARC Across Subdomains, Multiple Domains, and Brand Signals

Scale changes the shape of the work. Single-domain deployment centralizes policy and reporting, while a multi-domain deployment requires separate records, ownership, and monitoring for each organizational domain. Parent-domain policies can govern subdomains through sp, and direct subdomain records provide clearer control when business units or mail streams carry different risk profiles.

How Should Organizations Manage Domain Portfolios?

Each organizational domain is a separate authentication boundary in place of one line item in one DNS project. Every domain needs its own record at _dmarc.example.com, an inventory of legitimate senders, reporting recipients, and a policy owner. Inheritance through sp=quarantine or sp=reject should be a deliberate choice recorded somewhere other than the DNS zone.

Separate records suit subdomains with a distinct sending team, provider, or business purpose. A domain such as marketing.example.com might send campaign mail through a marketing platform, while billing.example.com sends invoices through an enterprise resource planning system. Assigning ownership to each stream stops one team from changing authentication requirements without informing the others.

Small and mid-sized organizations often carry the most inherited domains relative to their staffing. According to Verizon's 2026 Data Breach Investigations Report, 96% of ransomware victims were small and medium-sized businesses (SMBs), as SMBs present unpatched devices, compromised credentials, and limited recovery capabilities. A portfolio review sorts domains into five groups:

• Active organizational domains: Monitor legitimate senders, then move toward enforcement once alignment is stable;
• Subdomains with independent owners: Publish direct records where policy, reporting, or vendor relationships differ from the parent domain;
• Parked domains: Publish SPF with no authorized senders, such as v=spf1 -all, alongside a restrictive policy to prevent spoofing;
• Unused legacy domains: Confirm that no forgotten service, forwarding rule, or application still sends mail before applying rejection;
• Internationalized domains: Validate DNS, mail-transfer, and provider support before deployment, especially where labels or addresses use non-ASCII characters.

Consistent ownership matters because failures often originate in forgotten SaaS accounts, inherited domains, and untracked transactional systems. One accountable owner should cover domain registration, DNS changes, provider approval, and aggregate-report review. That operating model gives every failure a defined escalation path.

How Should Transactional, Marketing, and Support Mail Streams Be Separated?

Email streams are separated by business function, sender identity, and operational consequence. Transactional mail, including invoices, password resets, and shipping notices, requires close delivery monitoring because a failed message interrupts a customer action. Marketing mail needs separate DKIM selectors and provider tracking controls, since campaign platforms often rewrite links, envelope senders, or return paths.

Support mail involves ticketing systems, shared inboxes, and human replies that require their own authentication testing. Distinct subdomains suit providers or teams that cannot share a controlled authentication model. A structure such as notify.example.com, news.example.com, and support.example.com makes ownership visible and lets security teams investigate reports by function.

Before enforcement, each stream needs a confirmed pass through SPF alignment or DKIM alignment. Advanced tags added merely to make a record look comprehensive add risk without adding protection. Reliable monitoring comes first, followed by a tightened p, an adjusted sp, a reviewed pct, and documented exceptions.

What Does BIMI Require Beyond DMARC?

BIMI connects authenticated email to a brand logo as a presentation layer built on email authentication. The mailbox provider evaluates the message's authentication and the domain's BIMI record before deciding whether to display the logo. A logo cannot compensate for weak alignment, an unmonitored sender, or a permissive spoofing policy.

BIMI readiness generally requires enforcement at the organizational domain, typically p=quarantine or p=reject. The BIMI Group implementation guidance also identifies certificate requirements that apply to particular mailbox-provider displays. Current provider rules deserve verification, and the BIMI TXT record belongs in DNS only after enforcement is reliable.

The correct sequence runs from authentication to alignment, enforcement, BIMI publication, and mailbox-provider testing. The BIMI record and certificate lifecycle belong under the same ownership model as DNS and brand governance. That structure prevents a marketing team from publishing a logo while security teams still lack visibility into unauthorized senders.

What Changes for Internationalized Domains and Non-ASCII Addresses?

Internationalized email introduces compatibility risk because domain labels and mailbox addresses can contain Unicode characters outside the traditional ASCII range. The IETF's 2025 email-core work describes ongoing standards considerations for email address syntax and internationalized messages. Providers therefore need testing rather than assumed support.

Validation should cover the registrar, DNS host, sending provider, receiving provider, reporting platform, and security tooling before deployment. Test messages should originate from internationalized domains and travel to non-ASCII recipients, exercising forwarding, bounce handling, DKIM signing, and aggregate-report parsing. An ASCII-compatible operational alias, documented provider limitations, and enforcement applied only after consistent results keep the rollout defensible.

Acquisitions, regional launches, and forgotten legacy domains all create sending paths nobody reviews. Adaptive Security keeps employee risk visible across every business unit as the domain portfolio expands.

Book a demo

How DMARC Supports the Human Layer After Setup

Authentication and employee judgment protect different parts of the same cyberattack path. CISA's 2025 phishing guidance recommends DMARC alongside SPF and DKIM to interrupt phishing before it reaches an employee's inbox. What survives that filter arrives looking legitimate, often from a lookalike domain or a compromised partner account, which makes the recipient's decision the last control in the chain.

Where Do Technical and Human Controls Meet?

Aggregate reports tell administrators which services send mail on the organization's behalf and which unauthorized sources attempt to use the domain. That intelligence has a second audience. Security leaders can use the same impersonation patterns to focus cybersecurity awareness training on the specific requests employees are being asked to approve.

Useful content follows the observed patterns rather than a generic curriculum. Invoice changes, password resets, executive requests, malicious attachments, suspicious links, vishing, smishing, and messages that pass authentication all belong in the rotation. According to the National Cybersecurity Alliance's 2025–2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 52% of employed participants reported they have not received any training on the security or privacy risks of AI tools, despite 65% now using AI and 43% admitting to sharing sensitive work information with AI tools.

The objective is a calibrated pause instead of blanket suspicion. A finance employee who receives an authenticated vendor-change request should confirm it through a known phone number or approved workflow, and an executive assistant who receives an urgent wire-transfer request should verify it through a separate trusted channel. Authentication proves where a message claims to originate without proving that the request inside it is safe.

How Can Observed Email Patterns Drive Behavior Change?

Reporting becomes more valuable when administrators connect it to human-risk priorities. A recurring failed-alignment pattern using the CFO's name should trigger a review of executive impersonation procedures, finance-team practice, and reporting instructions. A surge in messages impersonating a payroll provider should lead to targeted rehearsal around benefits, direct-deposit, and tax-document requests.

A practical process has four steps:

1. 1Review authentication failures and identify recurring sender names, domains, brands, and request types;
2. 2Separate infrastructure problems from likely impersonation activity, correcting approved senders and investigating unauthorized sources;
3. 3Rehearse the matching employee behavior with realistic examples, covering sender inspection, unsafe links, and verification of unusual requests;
4. 4Measure reporting quality and verification behavior in preference to module completion.

That final measurement point deserves emphasis. As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer (October 2020), compliance metrics do not tell the whole story and fail to measure the effectiveness of the program in a sustained change in employee attitudes and behaviors. Employees who report suspicious messages give administrators a signal that DMARC cannot produce, particularly when a message arrives from a lookalike domain or a compromised legitimate account.

Telemetry from the domain therefore doubles as a prioritization signal for the cybersecurity awareness training program. It indicates which departments need practice, which impersonation themes require clearer verification rules, and which reporting workflows need reinforcement. Both halves of the work start from the same artifact, which is an accurate inventory of every legitimate email sender.

Close the Gap Between Authenticated Email and Employee Decisions With Adaptive Security

Security leaders who reach p=reject still see impersonation attempts land, because lookalike domains and compromised vendor accounts never touch the protected domain's DNS. The organizations that reduce that residual exposure are the ones measuring what employees do with a convincing message rather than how many finished a module. Adaptive Security is built for that outcome, connecting detection, reporting, and practice into one record of human risk.

Adaptive Security's Cloud Email Security layers AI-native detection over Google Workspace and Microsoft 365 through an API integration, so no MX record or mail-flow change is required alongside a DMARC rollout. Behavioral signals, intent analysis, and language-model reasoning catch AI-generated business email compromise attempts that signature-based filters miss, and confirmed cyber threats are removed automatically from every inbox they reached. Each detection then feeds the targeted employee's risk profile, turning an intercepted cyberattack into the next lesson that employee receives.

Around that detection layer, phishing simulations rehearse email, voice, and SMS impersonation, phish triage converts reported messages into verified signals, and cybersecurity awareness training and compliance content keeps policy obligations current across regulated teams. Reporting ties the results back to departments, domains, and request types, which is the same axis aggregate reports use. Security leaders get one view of where authentication ends and human judgment begins.

Reaching enforcement removes forged senders while leaving lookalike domains and compromised vendor accounts in the inbox. Adaptive Security detects those messages, removes them automatically, and trains the employees they targeted.

Book a demo

Frequently Asked Questions About How to Set Up DMARC

How Long Does It Take to Set Up DMARC and Start Receiving Aggregate Reports?

Setup can begin in a few hours, although at least 48 hours should pass while SPF and DKIM authenticate mail before enforcement is enabled. Google Workspace guidance recommends that preparation period. After a valid p=none record with a rua address is published, aggregate reports typically arrive on a daily cycle, although the receiving provider controls delivery timing under RFC 9990. The initial monitoring period exists to inventory senders, confirm alignment, and correct legitimate failures, so quarantine and rejection should wait until reports show that authorized mail is consistently authenticated.

Can DMARC Protect a Domain if SPF and DKIM Both Pass?

DMARC protects the visible From domain only when at least one passing SPF or DKIM result also aligns with that domain. Both protocols can pass while DMARC fails, which happens when the authenticated envelope-from domain and DKIM signing domain do not align with the From domain. Google's guidance distinguishes authentication from alignment and recommends checking both before enforcement. The protocol also does nothing about a compromised legitimate account, a lookalike domain, or a malicious message from an authenticated sender, so employee reporting and verification of unexpected payment, credential, and document requests remain necessary.

What Happens if a Domain Has Multiple DMARC TXT Records?

Multiple TXT records make the policy invalid because receivers cannot select one authoritative record. RFC 9989 directs receivers to disregard the policy when DNS returns multiple records at the _dmarc hostname. The result can include absent enforcement and missing or unpredictable reporting, even when the individual records look correct. The repair is to query _dmarc.example.com, remove duplicates, merge the required tags into one syntactically valid TXT value, and confirm the result from more than one resolver after DNS changes propagate.

Should DMARC Forensic Reports Use the ruf Tag?

The ruf tag belongs in a record only when the organization has a documented privacy, access-control, and processing plan for failure reports. RFC 9991 defines ruf as the destination for message-specific failure reports, and receiving providers are not required to send them. These reports can contain message headers or other sensitive content, and many providers limit or omit them entirely. Aggregate rua reports usually provide the safer operational baseline for sender discovery and alignment analysis, and any organization enabling ruf should use a protected mailbox or reporting service, restrict access, and set retention rules.

What Should Be Done if Legitimate Email Is Rejected After Moving to p=reject?

Reduce enforcement temporarily, identify the legitimate sender's authentication or alignment failure, fix its configuration, and revalidate before restoring rejection. Aggregate reports and the rejected message's Authentication-Results headers together show whether SPF, DKIM, or alignment failed. Google's setup guidance recommends authenticating third-party senders and rolling out the policy gradually, so the repair usually involves custom DKIM, an aligned return path, or an approved vendor configuration. Documenting the change, sending controlled tests, and monitoring reports after each adjustment turns enforcement into reliable domain protection.

Domain authentication is a solved problem compared with the judgment call an employee makes on a convincing message. Adaptive Security measures and improves that decision across email, voice, and SMS.

Explore the platform