What Is DMARC? A Practical Guide to Email Authentication

DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that checks whether the domain visible in an email’s From: address is legitimately connected to the message. It uses SPF and DKIM, plus domain alignment and a DNS policy, to help receiving mail providers identify spoofed mail and decide how to handle it.

What is DMARC and what problem does it solve?

Email was designed for interoperability, not for proving that the friendly-looking sender address in a message is genuine. Without authentication, a bad actor can create a message that appears to come from billing@yourcompany.com, support@yourcompany.com, or an executive at your organization. The recipient sees a familiar domain in the From: field, even though your company never sent the message.

DMARC gives the owner of yourcompany.com a way to publish instructions in DNS about mail that claims to be from that domain. It does three important things:

1. It checks identity. DMARC evaluates SPF and DKIM authentication results.
2. It checks alignment. A passing SPF or DKIM identity must align with the domain a recipient sees in the visible From: address.
3. It publishes a policy and requests reports. The domain owner can ask receivers to monitor, quarantine, or reject messages that fail DMARC, and can receive aggregate reports describing observed mail streams.

This matters because SPF or DKIM alone can pass without protecting the exact brand domain shown to the recipient. For example, a message could pass SPF for an unrelated return-path domain while displaying From: invoices@yourcompany.com. DMARC closes that gap by asking whether the authenticated identity is appropriately related to yourcompany.com.

At a practical level, DMARC is a domain-level anti-spoofing control and an email-infrastructure visibility tool. It does not guarantee inbox placement, stop every phishing campaign, or replace permission-based sending practices. It does make it much harder for unaffiliated systems to send mail that convincingly impersonates a protected domain.

How DMARC works with SPF, DKIM, and alignment

DMARC depends on two underlying authentication methods: SPF and DKIM. A receiver evaluates those methods during normal message processing, then applies the DMARC logic to the visible From: domain.

SPF: authorization for the envelope sender

Sender Policy Framework, or SPF, lets a domain publish which mail servers are authorized to send mail using that domain in the SMTP envelope sender, commonly called the MAIL FROM, return-path, or bounce domain.

An SPF record is stored in DNS as a TXT record. A simplified example might look like this:

v=spf1 include:spf.example-email-provider.net -all

When a receiving server evaluates SPF, it checks whether the connecting mail server is authorized by the domain used in the envelope sender. SPF is useful, but it has a limitation: the envelope sender is usually not the address a recipient sees in their email client.

A marketing message might display:

From: Acme Updates <news@acme.com>

while its envelope sender is:

bounce@send.acme-mail.example

SPF can pass for send.acme-mail.example, but that result does not automatically establish that acme.com in the visible From: field is authentic. DMARC adds the alignment test.

DKIM: a cryptographic signature for message content

DomainKeys Identified Mail, or DKIM, adds a digital signature to an email. The sending system signs selected headers and parts of the body with a private key. The recipient retrieves the matching public key from DNS and verifies that the signed content has not been altered in a way that breaks the signature.

A DKIM signature includes a d= value that identifies the signing domain. A simplified header fragment could look like this:

DKIM-Signature: v=1; a=rsa-sha256; d=acme.com; s=mail1; ...

Here, d=acme.com is the domain relevant to DMARC alignment. If the signature verifies and acme.com aligns with the visible From: domain, DKIM can satisfy DMARC even if SPF fails.

That resilience is one reason many senders use both SPF and DKIM. SPF can fail during forwarding because the forwarding server may not be authorized in the original sender’s SPF record. A valid aligned DKIM signature can still allow the message to pass DMARC after forwarding, provided the message was not modified in a signature-breaking way.

Alignment: the DMARC requirement that ties it together

Alignment is the core distinction between basic authentication and DMARC authentication. For DMARC to pass, at least one of these must be true:

• SPF passes and the authenticated SPF domain aligns with the visible From: domain.
• DKIM passes and the DKIM d= domain aligns with the visible From: domain.

A message does not need both aligned SPF and aligned DKIM to pass DMARC. One aligned pass is enough. In production, though, configuring both creates redundancy and helps protect delivery when one authentication method encounters a forwarding or configuration issue.

DMARC supports two alignment modes:

• Relaxed alignment permits a related subdomain relationship. For example, mail.acme.com can align with acme.com.
• Strict alignment requires an exact domain match. In strict mode, mail.acme.com does not align with acme.com.

Relaxed alignment is the normal starting point for most organizations because it supports legitimate subdomain-based sending architectures. Strict alignment can be valuable for narrowly controlled domains, but it raises the chance of accidentally failing valid mail when platforms use subdomains for return paths or DKIM signing.

The DMARC pass and fail decision

A receiver first determines the domain in the RFC 5322 From: header: the human-visible From: address in the email message. That domain is sometimes called the author domain.

Then the receiver evaluates SPF and DKIM. DMARC passes when one valid authenticated identity aligns with the author domain. A simplified decision table makes the result easier to understand:

The third row is the common source of confusion. Both SPF and DKIM can technically pass, but DMARC can still fail if neither authenticated domain aligns with the visible From: domain. This is why checking only for spf=pass or dkim=pass in message headers is not enough.

For example, imagine a message with these identities:

From: Product Team <updates@acme.com>
Return-Path: bounce@mailer.vendor-example.net
DKIM d=vendor-example.net

If SPF passes for mailer.vendor-example.net and DKIM passes for vendor-example.net, but neither domain aligns with acme.com, DMARC fails. The message may be legitimate from a business perspective, but its authentication architecture does not prove that the sending vendor is authorized to use the visible acme.com identity.

The fix is usually to configure a custom sending domain, custom return-path domain, custom DKIM signing domain, or all three through the vendor. A transactional email provider should make it possible to authenticate the domain you actually place in the From: field. Review the provider’s email API reference and setup guides before changing a live sending domain, especially if your application sends password resets, receipts, alerts, or other time-sensitive mail.

DMARC policies: none, quarantine, and reject

A DMARC record contains a requested policy for messages that fail DMARC. The three familiar policy values are none, quarantine, and reject.

p=none: monitor without requesting enforcement

p=none asks receivers to take no specific DMARC-based enforcement action on failed mail. It is often described as a monitoring policy because it enables reporting while reducing the risk that an unknown legitimate sender is blocked during an initial rollout.

A monitoring policy does not mean DMARC is irrelevant to deliverability. Receiving providers may still use their own reputation, anti-abuse, and authentication systems when deciding whether to inbox, spam-folder, throttle, or reject a message. p=none simply means the domain owner is not yet asking receivers to quarantine or reject every DMARC failure based on that published policy.

p=quarantine: ask receivers to treat failures suspiciously

p=quarantine asks receivers to treat DMARC-failing messages as suspicious. A receiver may place such messages in spam, bulk, junk, or another less trusted category. The exact handling remains receiver-dependent.

Quarantine is a useful intermediate stage when reports show that most legitimate traffic is authenticated, but the organization wants a cautious transition before a rejection policy. It offers more protection than monitoring while still allowing some receiver discretion for questionable messages.

p=reject: ask receivers to refuse failed mail

p=reject asks receivers to reject messages that fail DMARC. This provides the strongest published anti-spoofing posture because a recipient is less likely to receive a message that falsely claims to be from the protected domain.

Reject is not a setting to add casually. If a payroll platform, support desk, CRM, billing provider, cloud application, or employee mail system sends as your domain without aligned SPF or DKIM, a reject policy can disrupt legitimate mail. The correct sequence is discovery, authentication, monitoring, remediation, staged enforcement, and ongoing monitoring.

It is also important to understand policy scope. The p= tag applies to the organizational domain’s policy. A domain can use sp= to define a different requested policy for subdomains, which is useful when a parent domain and its sending subdomains have different risk profiles.

What a DMARC DNS record looks like

DMARC is published as a DNS TXT record at the _dmarc subdomain. For acme.com, the record name is:

_dmarc.acme.com

A practical starter record might be:

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

The exact fields configured in a DNS provider interface vary, but the underlying record contains a host or name, a TXT type, and a value. Do not publish multiple DMARC TXT records at the same _dmarc name. Receivers can treat multiple records as an error, which can prevent reliable policy discovery.

Core DMARC tags

The following tags are the most important to understand:

The record below is a more mature example for an organization that has completed its inventory and wants full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@acme.com; adkim=r; aspf=r; pct=100

The rua tag requests aggregate reports. These reports are commonly compressed XML files sent by participating receivers, often daily. They contain counts and authentication results by source IP, sending domain, policy disposition, and other fields. They are operational data, not a convenient human-readable dashboard, so many teams use a reporting service or internal parser.

If the reporting address uses a different domain from the domain publishing the DMARC record, that external destination needs additional authorization in DNS. This protects report recipients from being unwillingly subscribed to high-volume report traffic. Use the relevant DMARC reporting specification or your reporting provider’s documented setup instructions rather than guessing the authorization record.

Why DMARC matters for deliverability and campaign performance

DMARC is first an authentication and anti-impersonation protocol, but it has direct practical implications for deliverability. Major mailbox providers expect senders to authenticate mail, and high-volume senders face explicit authentication requirements.

Google’s sender guidelines require all senders to Gmail accounts to set up SPF or DKIM, while senders delivering more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC. Google permits a DMARC policy of p=none for that requirement, but authentication must still be technically correct. Yahoo’s bulk-sender guidance similarly calls for SPF and DKIM, a valid DMARC policy, and DMARC alignment.

For a legitimate sender, DMARC improves the clarity of the identity signal your messages present to mailbox providers. It tells them that the From: domain is intentionally controlled, that authorized services are configured to use it, and that spoofed mail should not be treated as equivalent to your real mail.

Better identity consistency across email streams

Most established companies send mail through more systems than they initially realize. Common sources include:

• Application-triggered transactional messages, such as password resets and receipts
• Marketing campaigns and newsletters
• Customer support platforms
• Sales engagement tools
• Invoicing and subscription systems
• HR, recruiting, and employee communications platforms
• Google Workspace or Microsoft 365 mailbox sending
• Monitoring, security, and incident-alert tools

DMARC forces a useful question: “Which of these systems is authorized to use our From: domain?” That inventory work improves more than spoofing protection. It reduces accidental domain misuse, makes vendor ownership clearer, and exposes forgotten tools that might have poor sending practices or outdated credentials.

Fewer avoidable authentication failures

Authentication failures can contribute to spam placement, filtering, throttling, and delivery problems. They are not the only factor. Complaint rates, recipient engagement, content, sending consistency, list quality, and IP or domain reputation also matter.

Still, a sender should not treat DMARC as optional plumbing. A message with a broken authentication chain starts from a weaker position than a message that has aligned, valid SPF and DKIM. For campaign mail, that can mean less reliable inbox visibility. For transactional mail, it can mean a higher risk that important account, security, or purchase messages are filtered or questioned.

Protection against brand and customer harm

Spoofed messages can damage a sender even when the sender’s own infrastructure is working perfectly. A fraudster who impersonates your domain may send fake invoice requests, credential-harvesting links, fraudulent shipping notices, or executive-impersonation messages.

With p=reject correctly deployed, a receiver that honors the policy has a clear signal to reject unauthenticated mail claiming to be from your domain. That will not stop attacks that use lookalike domains such as acme-payments.example or visually confusable characters, but it materially improves protection for exact-domain impersonation.

DMARC is not a rate, but reports contain useful metrics

DMARC itself is not a performance metric like open rate, bounce rate, click-through rate, or complaint rate. It is a protocol and policy framework. However, its aggregate reports contain counts that let you calculate operational metrics, including DMARC pass rate and the volume of unauthorized mail observed using your domain.

A basic DMARC pass rate can be calculated as:

DMARC pass rate = aligned DMARC-passing messages ÷ total observed messages × 100

Worked numeric example

Suppose aggregate reports for acme.com show 1,200,000 messages during a seven-day period:

• 1,134,000 messages passed DMARC through aligned DKIM.
• 42,000 messages passed through aligned SPF only.
• 24,000 messages failed DMARC.

The total number of passing messages is:

1,134,000 + 42,000 = 1,176,000

The DMARC pass rate is:

1,176,000 ÷ 1,200,000 × 100 = 98%

A 98% pass rate is not automatically safe for p=reject. The unanswered question is what the remaining 24,000 failures represent. If they are phishing attempts, spoofed mail, or traffic from retired services, enforcement may be appropriate. If 20,000 are legitimate invoices from an unconfigured billing provider, moving to reject could block real customer mail.

This is why percentages alone are not enough. Review failures by source IP, sending platform, envelope domain, DKIM signing domain, message volume, and business purpose. A small percentage can still be business-critical if it contains password-reset or billing mail.

Common causes of DMARC failure

A DMARC failure generally means neither SPF nor DKIM both passed and aligned with the visible From: domain. The failure is often a configuration issue, not a sign that a message is malicious.

A third-party vendor sends with its own domains

This is one of the most common failures. A vendor sends mail showing From: updates@acme.com, but uses its own domain for both the return-path and DKIM signature. SPF and DKIM may pass, yet neither aligns with acme.com.

How to fix it: Configure the vendor’s custom domain or domain-authentication feature. Ideally, set up aligned DKIM signing for a subdomain you control, such as mail.acme.com or news.acme.com. If the platform supports a custom return-path domain, configure that too.

The From: domain and authenticated domain do not match

A company may authenticate mail.acme.com but send visible mail from acme.co, acmeapp.com, or another brand domain. Even small domain differences matter. DMARC evaluates domain relationships, not just brand intent.

How to fix it: Use the exact domain intended for customer-facing From: addresses, or deliberately select a subdomain that aligns under relaxed alignment. Document the approved From: domains for each message stream.

DKIM signatures break after the message is sent

DKIM can fail if an intermediary modifies signed content. Examples include gateways that append disclaimers, systems that rewrite MIME structure, mailing lists that alter message bodies, or security tools that change headers in ways covered by the signature.

How to fix it: Identify where the modification occurs. Configure the intermediary to avoid changing signed content where possible, sign after the final modification point, or use an architecture designed for that mail flow. Test real delivered messages rather than relying only on a platform’s setup screen.

SPF fails because of forwarding

Traditional forwarding can cause SPF to fail because the forwarder’s IP address is not authorized in the original sender’s SPF record. This is expected behavior in some forwarding paths and does not mean the original sender necessarily configured SPF incorrectly.

How to fix it: Ensure aligned DKIM is configured and survives forwarding. Do not rely solely on SPF for DMARC. This is one of the strongest practical reasons to deploy both authentication mechanisms.

SPF records exceed lookup limits or contain errors

SPF has a limit on DNS lookups during evaluation. Complex records with numerous include mechanisms can exceed the limit, producing an SPF permerror. Separate records, malformed syntax, unintended redirects, and old vendors left in the record can also cause trouble.

How to fix it: Audit the SPF record and every included provider. Remove unused services, consolidate sending architecture where possible, and verify that the published record reflects actual authorized senders. Do not blindly “flatten” SPF into static IP lists without understanding the maintenance and authorization consequences.

A sender uses an unapproved subdomain or departmental domain

A department may launch a tool using events.acme.com, while the security or deliverability team only monitors acme.com. The subdomain might lack an appropriate DMARC policy, aligned DKIM configuration, or a clear ownership model.

How to fix it: Build a domain inventory that includes parent domains and subdomains. Decide which domains are permitted to send email, which are defensive non-sending domains, and what subdomain policy should apply. Use sp= when the parent-domain policy needs to differ from the policy for subdomains.

There are multiple DMARC records

Publishing multiple TXT records at _dmarc.acme.com can cause policy discovery problems. This often happens when different teams each add a record or when a vendor-provided record is added without checking what already exists.

How to fix it: Publish one valid DMARC record per domain. Merge the required tags into a single record and preserve all legitimate reporting destinations during the transition.

How to set up and improve DMARC safely

A successful DMARC rollout is an email-program management project as much as a DNS change. The safe path is to understand your senders before raising enforcement.

1. Inventory every system that sends as your domain

Start with a complete sender inventory. Ask marketing, engineering, support, finance, IT, security, HR, and operations which tools send mail using your corporate domains. Include both high-volume providers and low-volume systems, because a low-volume stream may send highly important messages.

For each system, record:

• The visible From: domain
• The return-path or envelope-sender domain
• The DKIM signing domain
• Whether SPF passes
• Whether DKIM passes
• Whether either passing identity aligns with From:
• The business owner and message type
• Expected sending volume and destination audience

This turns DMARC from a vague security initiative into a manageable list of mail flows.

2. Configure aligned DKIM wherever possible

For most transactional and campaign streams, aligned DKIM should be the primary target. It is durable across many real-world routing conditions and clearly associates a signed message with your domain.

Use the DNS records supplied by your email provider and verify the provider signs with a domain that aligns with your visible From: domain. A sending setup that signs as mail.acme.com while displaying notifications@acme.com typically works under relaxed alignment because both share the organizational domain acme.com.

3. Configure SPF as a complementary control

Authorize the systems that use your envelope sender domain. Keep SPF records accurate and minimize unnecessary includes. SPF should support your mail architecture, not become an unmaintainable list of every vendor the company has ever tried.

Remember that SPF must align to satisfy DMARC through SPF. If a provider’s return-path cannot be customized, SPF may still authenticate that provider’s mail but may not contribute to DMARC alignment. In that case, aligned DKIM becomes essential.

4. Publish a monitoring record and collect reports

A typical initial policy is:

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

Use a dedicated mailbox or a reporting platform that can handle compressed XML reports. Do not send reports to an employee’s ordinary inbox. Report volume can become substantial, and ownership must survive personnel changes.

A monitoring policy is an observation stage, not a finish line. Review reports long enough to cover normal business cycles: monthly billing, quarterly campaigns, regional announcements, automated renewals, and low-frequency system notifications.

5. Classify failures before enforcing policy

Separate failures into categories:

• Known and legitimate senders that need authentication work
• Unknown but harmless sources, such as old test systems
• Forwarding-related behavior
• Suspicious or clearly unauthorized sources
• Misconfigured internal infrastructure
• Domains that should never send mail

Prioritize the failures by business impact and volume. A source responsible for 50 password resets per day may deserve attention before a large volume of obvious spoofing, because fixing the legitimate source is a prerequisite for safe enforcement.

6. Move gradually to quarantine and reject

After legitimate mail streams pass reliably, change to p=quarantine. Some organizations use pct= to apply their requested policy to only a portion of failing mail during a transition, although receiver behavior and reporting should be monitored carefully.

Once the remaining failures are understood and legitimate exceptions are fixed, move to p=reject. Continue monitoring after enforcement. New vendors, departmental tools, acquisitions, domain changes, and product launches can introduce new mail streams long after the original project is complete.

DMARC best practices for transactional and campaign email

Transactional and marketing mail often travel through different platforms, but both should follow the same identity principles. Recipients should see a consistent, recognizable From: domain, and the sending platform should produce aligned authentication.

Use distinct, purposeful subdomains when appropriate

A company might use:

• notify.acme.com for application notifications
• receipts.acme.com for purchase and payment mail
• news.acme.com for newsletters and campaigns
• support.acme.com for customer service communications

This approach can improve operational separation while preserving relaxed alignment with acme.com. It also makes ownership easier to understand: a DKIM signature from news.acme.com immediately signals which stream generated the message.

Subdomains are not a substitute for audience quality or sender reputation. They are an organizational tool. If campaign mail and critical password-reset messages share a parent brand, teams should still maintain permission, suppression, unsubscribe, complaint-management, and content-quality standards appropriate to each stream.

Keep the visible From: address stable

Changing From: domains frequently makes customer recognition and authentication management harder. Select a domain structure that reflects the brand and can be supported across all authorized platforms.

A stable From: domain also makes DMARC reports easier to interpret. When every vendor uses a different visible domain, it becomes harder to determine whether an unknown source is spoofing, a forgotten legitimate system, or a configuration error.

Test actual delivered headers

Do not assume a DNS record is correct because a provider dashboard says a domain is verified. Send test messages to mailbox providers, inspect the full message headers, and check the authentication summary. Look for SPF, DKIM, and DMARC results, then verify that the domains used in those results align with the visible From: address.

Testing should include different message types and sending paths. A production API message, a bulk campaign, a reply from a support platform, and a forwarded message may behave differently. A well-designed transactional platform lets you maintain authenticated domain settings consistently while sending through SMTP or an API.

Treat DMARC as part of ongoing deliverability operations

DMARC is not a one-time DNS task. Add it to change-management procedures whenever your organization:

• Adds a new email vendor
• Launches a new domain or subdomain
• Changes the visible From: address
• Moves marketing automation platforms
• Adds a support, billing, or CRM integration
• Changes outbound gateways or mail security tools
• Acquires another company or merges brand domains

For new projects, require authentication planning before the first production send. That is far easier than retrofitting aligned identity after a campaign is already live or after a strict DMARC policy begins blocking an overlooked system.

DMARC limitations and related technologies

DMARC is powerful, but it is not a complete email-security or deliverability strategy.

First, it protects the exact domain being evaluated, not every deceptive variation of your brand. Attackers may register lookalike domains, use unrelated compromised domains, or create messages with misleading display names. Brand monitoring, user education, secure payment processes, and anti-phishing controls remain important.

Second, a DMARC pass does not prove a message is wanted. A sender can have perfect authentication and still send irrelevant, excessive, or unwanted campaigns. Mailbox providers consider complaints, engagement, list quality, content, and reputation alongside authentication.

Third, DMARC can be complicated by indirect mail flows such as mailing lists and forwarding. DKIM is generally more resilient than SPF in these flows, but modifications can still break signatures. Test the flows your audience actually uses instead of assuming every recipient path behaves the same way.

Finally, DMARC does not eliminate the need for email-address hygiene. Sending to invalid, abandoned, mistyped, or risky addresses can still hurt campaign performance and reputation. Validate addresses at signup, suppress hard bounces promptly, and use an email address verification tool before importing older lists or launching a high-value campaign.

Conclusion

DMARC is the protocol that connects email authentication to the domain recipients actually see in the From: field. By requiring aligned SPF or DKIM, publishing a requested policy, and collecting reports, it gives domain owners a practical way to identify legitimate senders, reduce exact-domain spoofing, and strengthen the authentication foundation behind deliverability.

The safest implementation is deliberate: inventory all senders, configure aligned DKIM and SPF, publish p=none, analyze reports, fix legitimate failures, then move through quarantine to reject when the data supports it. Done well, DMARC protects customers and brand reputation without interrupting the transactional and campaign messages your business depends on.

FAQ

What does DMARC stand for?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol that uses SPF, DKIM, alignment, DNS policies, and reporting to help domain owners control unauthorized use of their visible From: domain.

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes when either SPF or DKIM passes and the passing domain aligns with the visible From: domain. Deploying both is strongly recommended because they provide redundancy across different mail flows.

What is the best DMARC policy to start with?

Most organizations start with p=none and a valid rua reporting destination. This allows the team to discover every legitimate sender and correct authentication issues before requesting quarantine or reject enforcement.

Does p=none mean DMARC is not working?

No. With p=none, receivers can still evaluate DMARC and send aggregate reports. The policy simply does not ask them to quarantine or reject mail that fails DMARC. It is a monitoring phase, not an enforcement phase.

Can DMARC improve inbox placement?

DMARC can support deliverability by establishing a consistent, aligned sender identity and meeting mailbox-provider authentication expectations. It does not guarantee inbox placement, because complaints, engagement, sending practices, reputation, and content still affect filtering decisions.