What Is DMARC? How Email Authentication, Alignment, and Policies Work

DMARC—short for Domain-based Message Authentication, Reporting, and Conformance—is an email authentication protocol that helps stop criminals and spammers from sending messages that appear to come from your domain. If you are asking what is DMARC, the practical answer is: it connects SPF and DKIM results to the visible From: address, publishes a handling policy in DNS, and gives domain owners reports about mail claiming to be from them.

DMARC is not a sending service, a spam filter, or an encryption protocol. It is a standard that receiving mail systems can use when deciding whether a message that says From: billing@example.com is genuinely authorized to use example.com. It is especially important for transactional mail, such as password resets, receipts, account alerts, verification codes, and support notifications, because these are precisely the messages attackers like to impersonate.

DMARC in plain English

Email has several identities. The address a recipient sees in their inbox is usually the From: address. But SMTP also has an envelope sender, used for bounces, and a message may carry one or more DKIM signatures from domains that are not visible to the recipient. Before DMARC, SPF and DKIM could each pass while still offering limited assurance that the visible sender was the organization the reader believed they were hearing from.

DMARC fixes that gap with alignment. It asks: did SPF or DKIM pass for a domain that matches, or is organizationally related to, the domain in the visible From: header? If yes, DMARC passes. If neither passing authentication result aligns, DMARC fails.

A domain owner publishes a DNS TXT record declaring three broad things:

1. How receivers should treat messages that fail DMARC: monitor them, quarantine them, or reject them.
2. How strict alignment should be for SPF and DKIM.
3. Where aggregate reports should be sent so the domain owner can see legitimate and unauthorized use of the domain.

A compact mental model is:

DMARC = SPF or DKIM passes + that passing domain aligns with visible From

The word “or” matters. A message does not need both SPF and DKIM to pass DMARC. One aligned pass is enough. In real production email, however, configuring both is the safer and more resilient approach because forwarding, mailing lists, and infrastructure changes can affect one mechanism but not the other.

Why DMARC exists: spoofing the visible From address

The original SMTP protocol does not inherently prevent a sender from placing almost any address in a message’s visible From: header. An attacker can compose a message that looks like this:

From: Acme Billing <billing@acme.example>
To: customer@example.net
Subject: Your invoice is overdue

Without authentication and receiver filtering, the message can look convincing even if it was sent from unrelated infrastructure. That makes a familiar brand domain useful to phishing campaigns, business-email compromise attempts, fake invoices, account-takeover lures, and fraudulent password-reset messages.

SPF and DKIM address different pieces of this problem:

• SPF checks whether the server sending the message is authorized by a domain’s SPF record. It normally evaluates the SMTP envelope sender domain, also called the MAIL FROM or return-path domain, rather than the visible From: domain.
• DKIM verifies a cryptographic signature added to the message. It checks that a domain took responsibility for the signed content and that the signed portions were not altered after signing.
• DMARC checks whether a passing SPF or DKIM identity aligns with the visible From: domain, then applies the owner’s published policy if it does not.

That design is why DMARC is most useful for controlling direct spoofing of your domain. It gives a receiving system a domain-owner signal: “mail that claims to be from this visible domain must authenticate in this way, and here is my requested treatment when it does not.”

DMARC does not guarantee inbox placement. A message can pass DMARC and still be filtered for poor reputation, suspicious content, low engagement, malware, unusual sending patterns, or other receiver-specific reasons. Conversely, a receiver may make a local policy decision that differs from the domain owner’s requested DMARC action.

How a DMARC check works

When a receiver accepts an incoming message, it generally evaluates the message’s authentication information before deciding how to deliver it. The precise order and filtering logic vary by mailbox provider, but the core DMARC process is consistent.

1. Identify the author domain

DMARC starts with the domain in the RFC 5322 From: header—the address shown to users in common mail clients.

For example:

From: Product Alerts <alerts@notify.example.com>

The author domain is notify.example.com.

This is not necessarily the same as the envelope sender shown in a Return-Path: header. That difference is normal. A transactional email platform may use a dedicated bounce subdomain while your application shows a branded From: address to the recipient.

2. Look up the DMARC DNS record

The receiver queries a TXT record at _dmarc. plus the author domain:

_dmarc.notify.example.com

If there is no record at that exact name, the receiver can determine whether a policy exists at the organizational domain, depending on the domain structure and applicable DMARC discovery rules. For a domain such as news.example.com, a record at _dmarc.example.com can therefore influence mail sent using the subdomain.

3. Evaluate SPF

SPF evaluates whether the SMTP client’s IP address is permitted to send for the envelope sender domain or, in certain situations, the HELO/EHLO identity. A result may be pass, fail, softfail, neutral, none, temperror, or permerror.

For DMARC, an SPF result is useful only if it passes and its authenticated SPF domain aligns with the visible author domain. A passing SPF check for bounce.vendor-mail.example does not automatically help a message with From: alerts@example.com.

4. Evaluate DKIM

DKIM validates one or more DKIM-Signature: headers. A typical header contains a signing domain in the d= tag:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

A valid signature using d=example.com can satisfy DMARC for a message whose visible address is alerts@example.com, assuming the alignment mode allows it. DKIM is often more durable than SPF through forwarding because a forwarder may change the SMTP sending path while leaving a valid signed message intact.

5. Check alignment and decide pass or fail

DMARC passes if at least one of these is true:

• SPF passed and the SPF-authenticated domain aligns with the visible From: domain.
• DKIM passed and the DKIM signing domain aligns with the visible From: domain.

If neither condition is met, DMARC fails. The receiving server then considers the domain’s policy along with its own local anti-abuse rules.

DMARC alignment: the part that causes most confusion

Alignment is the difference between “an email authenticated somehow” and “an email authenticated as the visible sender’s domain.” It is the central concept behind DMARC.

Suppose your application sends this message:

From: Acme <hello@acme.example>
Return-Path: bounces@mailer-provider.example
DKIM d=mailer-provider.example

The sending provider may have perfectly valid SPF authorization for mailer-provider.example, and its DKIM signature may pass for mailer-provider.example. But neither result aligns with acme.example. In that configuration, DMARC for the visible From: domain can fail.

A correct configuration typically makes one or both identities align:

From: Acme <hello@acme.example>
Return-Path: bounces@bounce.acme.example
DKIM d=acme.example

Now SPF can align through bounce.acme.example under relaxed alignment, and DKIM can align through acme.example directly.

Relaxed alignment

Relaxed alignment permits a subdomain relationship within the same organizational domain. For example, these can align under relaxed mode:

Visible From domain: acme.example
DKIM signing domain: mail.acme.example

Likewise, an envelope sender domain such as bounces.acme.example can align with acme.example in relaxed SPF alignment.

Relaxed mode is usually the practical default for organizations using separate subdomains for bounces, campaigns, notifications, or infrastructure. It permits operational flexibility while retaining control of the organizational domain.

Strict alignment

Strict alignment requires an exact domain match. For example, mail.acme.example does not strictly align with acme.example.

Strict alignment can be appropriate when an organization has a simple, tightly controlled email environment and wants the strongest exact-match rule. It can also create avoidable failures when separate systems legitimately use subdomains. Enabling strict mode before inventorying every sender is a common way to break mail that previously worked.

The DMARC tags adkim=s and aspf=s request strict DKIM and SPF alignment respectively. The r value requests relaxed alignment.

What a DMARC DNS record looks like

DMARC is published as a DNS TXT record. The hostname is always _dmarc followed by the domain you want to protect.

For example.com, the DNS record is:

Host/Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Some DNS dashboards automatically append your zone name. In that case, entering _dmarc as the host may create _dmarc.example.com. Check the resulting fully qualified record name rather than assuming how a particular DNS provider displays it.

The essential tags

The DMARC record is a semicolon-separated list of tag/value pairs.

The version tag must be v=DMARC1; do not substitute a product name, a generic v=1, or another protocol version. The p tag is required in a normal DMARC policy record and takes one of three principal values: none, quarantine, or reject.

A monitoring record

A safe starting record is:

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

p=none asks receivers to monitor failures rather than apply a DMARC-based enforcement action requested by the domain owner. It is useful during discovery, but it does not stop spoofed messages on its own.

A quarantine record

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

p=quarantine asks receivers to treat DMARC-failing mail as suspicious, commonly by placing it in spam or junk. The final handling remains receiver-specific.

A reject record

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

p=reject asks receivers to reject mail that fails DMARC rather than accept it for normal delivery. This is the strongest common policy and is the destination after you have confirmed that all legitimate streams authenticate and align.

Older DMARC examples often include tags such as pct, rf, ri, ruf, or fo. Some are widely seen in existing records, but current DMARC specifications have deprecated several legacy policy and reporting controls, and receiver support has never been uniform. For a new deployment, start with the minimal, well-supported record above and add only tags you have a specific operational reason to use.

DMARC policies: none, quarantine, and reject

The policy is not a switch for “email works” versus “email does not work.” It is a request to receiving systems about messages that have already failed DMARC. It also does not override a receiver’s independent reputation and anti-abuse systems.

p=none: observe first

Monitoring mode is best understood as a reporting phase. It helps answer questions such as:

• Which services are sending as example.com?
• Does your help desk send through a separate provider?
• Are invoices sent by an accounting platform?
• Is a legacy application still using a direct SMTP server?
• Are suspicious IP addresses or countries attempting to spoof your domain?

A domain can remain at p=none indefinitely, but it has not instructed receivers to quarantine or reject failures. That may be appropriate for a newly acquired domain, a complex organization still mapping senders, or a domain that deliberately does not send email. It is not equivalent to meaningful spoofing protection.

p=quarantine: a cautious enforcement step

Quarantine is often used while validating the move to full enforcement. It signals that failing messages should receive suspicious handling. This can reduce successful spoofing while allowing a receiver to place questionable mail in junk rather than refuse it during SMTP delivery.

The tradeoff is that real mail which fails alignment can also be quarantined. If a legitimate password-reset email starts landing in spam after this change, the solution is not generally to remove DMARC. The solution is to identify the stream and configure aligned SPF and/or DKIM for it.

p=reject: the strongest anti-spoofing signal

Reject is normally the goal for a domain that sends important customer, employee, financial, or security mail. It tells participating receivers that a message purporting to be from your domain should not be accepted if it fails DMARC.

When a receiver rejects a message during SMTP, a sender may receive a permanent failure such as 550 5.7.26 or another receiver-specific enhanced status code. The text and code are not standardized as one universal DMARC rejection response, so do not build alerting around a single string. Instead, inspect the full delivery-status notification, authentication results, and the actual domains involved.

DMARC reports: your inventory of real and fraudulent mail

The “R” in DMARC is reporting. Reports are what make a cautious deployment possible: they reveal how mail claiming to use your domain is being evaluated across participating receivers.

Aggregate reports (rua)

The rua tag requests aggregate reports. They are typically compressed XML files sent on a periodic basis, often daily, from receiving organizations that choose to provide them.

A report can contain grouped information such as:

• The reporting receiver and reporting period.
• Source IP addresses observed sending mail.
• Message counts for each group.
• The evaluated DMARC policy and disposition.
• SPF and DKIM results.
• Whether SPF and DKIM identifiers aligned.
• The header-from domain involved.

An aggregate report is not a copy of every message. It is operational telemetry. It may tell you that 4,200 messages from a known sending provider passed aligned DKIM, while 17 messages from an unfamiliar IP failed both SPF and DKIM using your domain.

The XML format is useful to machines but inconvenient for manual reading. Many teams use a DMARC reporting service, SIEM pipeline, or internal parser to turn compressed XML attachments into dashboards and alerts. If you use rua=mailto: with a third-party reporting address outside your domain, DMARC includes an external-report authorization mechanism; configure it exactly as the reporting destination instructs.

Failure reports

Failure or forensic reporting has historically been discussed alongside DMARC, but availability is inconsistent and privacy considerations are significant. Do not assume every receiver will send failure reports or that they will include message-level detail. Aggregate reporting is the dependable foundation for implementation and ongoing monitoring.

What reports cannot tell you

Reports are valuable, but they are not a complete ledger of every message sent or received. Not every mailbox provider sends reports, report timing varies, and the report records represent the receiving organization’s observations and policy decisions. Use reports alongside your application logs, email platform event webhooks, SMTP logs, bounce data, and DNS change history.

How to set up DMARC without breaking transactional email

A careful rollout matters because modern organizations rarely have only one mail sender. You may use a REST API or SMTP relay for product mail, a hosted mailbox provider for employee mail, a support tool, a billing platform, a CRM, a form provider, and possibly old systems that no one remembers.

Step 1: inventory every legitimate sender

List every system that can send a message using your root domain or any subdomain. Include both obvious and indirect senders.

A practical inventory should include:

1. Product emails: verification, password reset, receipts, alerts, and notifications.
2. Employee mail: Microsoft 365, Google Workspace, or another mailbox host.
3. Marketing and lifecycle campaigns.
4. Customer-support and ticketing tools.
5. Billing, procurement, HR, e-signature, and survey tools.
6. Monitoring, CI/CD, incident-management, and server-generated alerts.
7. Legacy applications, printers, scanners, and on-premises relays.

For each stream, record the visible From: domain, envelope sender domain, DKIM d= domain, provider, sending IPs if applicable, and business owner. This turns DMARC from a vague DNS task into a controlled deployment project.

Step 2: configure SPF and DKIM at each sender

Ask each platform how it supports custom-domain authentication. A provider might give you one or more DNS records for DKIM public keys, a custom return-path or bounce domain for SPF alignment, or both.

Avoid treating an SPF include as the whole solution. SPF has a DNS lookup limit and can fail after too many nested mechanisms or includes. It is also sensitive to forwarding because the final forwarder’s IP may not be authorized by the original envelope sender domain. DKIM should be enabled wherever the sender supports it.

For REST API and SMTP relay email, authenticate the domain before you send production mail. Your application’s API request being accepted does not establish DMARC compliance. An HTTP 202 Accepted, where a provider uses that response, means the provider accepted the request for processing; it does not mean the recipient mailbox later accepted the message or that DMARC passed. Similarly, an SMTP 250 response from your outbound relay means that relay accepted the message, not necessarily that the destination mailbox placed it in the inbox.

Step 3: publish p=none with aggregate reporting

Start with a record such as:

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

Use a mailbox or reporting service that can safely receive large volumes of zipped XML attachments. Do not send reports to an employee’s normal inbox. Create an address with a clear purpose, retention rules, and ownership.

DNS propagation depends on the record’s TTL and resolver caching. After publishing, query authoritative and public DNS to confirm there is one valid TXT record at the expected hostname. Multiple DMARC records at the same name can produce an invalid result.

Step 4: analyze real traffic, then fix alignment

Give reports enough time to cover normal business cycles. A quiet weekend can hide a monthly billing run; a week may miss a quarterly procurement system; a marketing team may schedule an infrequent campaign.

For every legitimate failing stream, determine whether the problem is:

• SPF does not pass.
• DKIM does not pass.
• SPF passes but the envelope domain does not align.
• DKIM passes but the d= domain does not align.
• A mailing list or forwarding workflow modified the message.
• A system is using an unauthorized or obsolete sender identity.

Fix the sending configuration rather than weakening the visible From: domain. Often that means enabling provider-managed DKIM for your domain, setting a branded return-path subdomain, changing the application’s From: address to a verified domain, or moving a forgotten sender to a supported delivery method.

Step 5: enforce gradually and keep monitoring

Once legitimate streams pass, move to p=quarantine, continue reviewing reports, and ultimately use p=reject when you are confident in the inventory. Enforcement is not a one-time operation. New SaaS tools, acquisitions, developers, and marketing integrations can introduce unauthenticated senders later.

Keep DMARC review in your vendor-procurement and application-release process. Any team that wants to send as your domain should have to prove how its SPF and DKIM identities will align before launch.

Common DMARC failures and how to diagnose them

Most DMARC incidents fall into a small number of patterns. The fastest way to troubleshoot is to inspect a message’s raw headers, not just the visible sender name or a dashboard summary.

SPF passes, but DMARC still fails

This usually means SPF passed for the wrong domain. For example:

From: notices@example.com
Return-Path: bounce@provider-mail.example
Authentication-Results: spf=pass smtp.mailfrom=provider-mail.example

The SPF authentication is valid for provider-mail.example, but it does not align with example.com. Configure a custom envelope sender or return-path under a subdomain you control, or rely on aligned DKIM if the provider supports signing with your domain.

DKIM passes, but DMARC still fails

This usually means the valid DKIM signature has a non-aligned d= value:

From: notices@example.com
DKIM-Signature: d=provider-mail.example; s=default; ...
Authentication-Results: dkim=pass header.d=provider-mail.example

The provider signed the message correctly, but not as example.com or an aligned subdomain. Enable custom DKIM through that provider’s domain-authentication process.

SPF and DKIM both pass, but an intermediary changed the message

Forwarders and mailing lists can complicate authentication. A forwarder may cause SPF to fail because the forwarding server is not in the original sender’s SPF record. A list can modify the subject line, footer, or body in ways that invalidate a DKIM signature. ARC, or Authenticated Received Chain, can help receivers understand authentication results across intermediaries, but it does not eliminate the need for a correct DMARC setup.

A domain has more than one DMARC record

Publishing two TXT records at _dmarc.example.com is not a way to combine policies. A receiver can treat multiple DMARC policy records as an error, preventing normal policy application. Combine needed tags into one record.

The DNS name is wrong

These are common mistakes:

example.com                    TXT  v=DMARC1; p=none
_dmarc.example.com.example.com TXT  v=DMARC1; p=none
_dmarc                         CNAME to an unrelated target

The intended record name for the root domain is _dmarc.example.com. Some DNS interfaces display only the relative host label; others show the full name. Always verify the resolved FQDN with a DNS lookup.

The sender uses a domain you do not control

If an application sends From: yourbrand@gmail.com or another third-party mailbox domain, you cannot publish or manage DMARC for that visible domain. Use a domain or subdomain you control for production application mail.

Testing DMARC records and real messages

DNS syntax checks are necessary, but they are not enough. A valid DMARC record does not prove that your provider signs mail correctly or that alignment succeeds for every message type.

Start with a DNS lookup:

dig +short TXT _dmarc.example.com

You should see one record containing v=DMARC1 and a policy. DNS tools such as MXToolbox can provide a quick lookup and surface common formatting issues. They are useful for discovery, but the authoritative answer remains what public DNS resolves to and what actual recipient systems observe.

Then send a real message through each production route. Use a test inbox where you can view original headers and inspect lines similar to:

Authentication-Results: mx.example.net;
  dkim=pass header.d=example.com;
  spf=pass smtp.mailfrom=bounces.example.com;
  dmarc=pass header.from=example.com

The exact header formatting differs by receiver. What matters is the result and domains: look for dmarc=pass, then confirm that either the DKIM header.d or SPF smtp.mailfrom identity matches your visible author domain according to your chosen alignment mode.

mail-tester.com can also be helpful for sending a test message to a generated address and reviewing a broad deliverability and authentication summary. Treat it as a diagnostic aid rather than a prediction that every mailbox provider will make the same delivery decision. Test your transactional email routes separately: a password reset may use a different template, sender address, subdomain, or infrastructure than a receipt.

DMARC and deliverability: important, but not magic

DMARC is a trust and identity control. It prevents many forms of direct domain spoofing and gives receivers a consistent policy signal, but it is not a reputation repair tool.

A message can pass DMARC and still be filtered because the IP has a poor reputation, the domain is newly active, recipients do not engage, complaint rates are high, links look risky, content resembles phishing, or sending volume changes abruptly. DMARC does not authorize unsolicited mail, bypass spam controls, or guarantee inbox placement.

The reverse is also operationally important: a message can be accepted by a recipient server without appearing in the primary inbox. “Delivered,” “accepted,” “in spam,” and “in inbox” are different outcomes. When diagnosing a sending issue, identify which outcome actually occurred before changing DNS or application code.

For developers, DMARC should be part of a broader email-infrastructure checklist:

• Use a verified domain for visible sender addresses.
• Enable domain-aligned DKIM.
• Configure an aligned custom envelope or bounce domain where available.
• Keep SPF records within their lookup constraints.
• Separate transactional and promotional traffic where appropriate.
• Monitor bounces, complaints, deferrals, authentication results, and DMARC reports.
• Avoid changing sender domains casually between environments.

DMARC for domains that do not send email

A domain that never sends mail is still vulnerable to spoofing. In fact, attackers may choose an unused corporate domain because there are fewer legitimate messages to create confusion.

After confirming that a domain truly has no legitimate email streams—not even employee forwarding, web-form notifications, or third-party services—you can publish a strict policy such as:

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

Do not publish this blindly. “We do not send email” is often disproved by a forgotten contact form, an old application server, or a cloud service configured years earlier. Aggregate reports can help validate the assumption before enforcement.

For a parked or defensive domain, DMARC does not replace other controls. You may also need to consider whether the domain has MX records, whether it should accept inbound mail, how related domains are registered, and how your brand-protection process handles lookalike domains.

The current DMARC standard and what to use in practice

DMARC originated as an industry protocol and later became an IETF standards-track specification. RFC 9989, published in May 2026, defines the current DMARC core protocol and obsoletes the older RFC 7489 specification. Aggregate reporting is specified separately in RFC 9990.

That standards evolution matters because many blog posts and vendor guides still quote the older RFC 7489 terminology and tag recommendations. Existing records based on older guidance may continue to work in practice, but new deployments should prefer a minimal, modern configuration and avoid adding legacy tags merely because a generator includes them.

The practical implementation advice has not changed: publish one syntactically valid record, authenticate every legitimate sender with aligned SPF and/or DKIM, read reports, and increase enforcement only after evidence supports it. The underlying protocol is technical, but success is mostly an operational discipline problem: know who sends as your domain and make their identities match what recipients see.

Conclusion

DMARC is the policy and alignment layer that makes SPF and DKIM meaningful for the visible From: address. It lets a domain owner see who is sending mail in its name and request that receivers monitor, quarantine, or reject messages that cannot prove they are authorized.

The best path is deliberate: inventory senders, configure aligned authentication, publish p=none with aggregate reports, investigate every legitimate failure, then progress to quarantine and reject. Once enforced, DMARC protects customers and employees from direct domain impersonation while making your transactional email infrastructure easier to understand and operate.

FAQ

What is DMARC in one sentence?

DMARC is a DNS-based email authentication protocol that requires an aligned SPF or DKIM pass for the visible From: domain and publishes a policy for mail that fails.

Does DMARC require both SPF and DKIM?

No. DMARC passes when either SPF or DKIM passes and the passing identity aligns with the visible From: domain. Configure both whenever possible because they fail in different real-world scenarios.

What DMARC policy should I start with?

Start with p=none and an rua aggregate-report address, then move to p=quarantine and p=reject after you have identified and fixed legitimate senders that fail alignment.

Does p=none protect my domain from spoofing?

Not by itself. It requests monitoring and reporting rather than DMARC-based enforcement. It is a deployment phase, not the final anti-spoofing posture for a domain that needs protection.

Why does my email API say accepted but the recipient rejects the message?

An API success such as HTTP 202 Accepted or an SMTP 250 generally means your outbound provider accepted the message for processing. Recipient-side authentication, reputation, and policy checks happen later and can still lead to a bounce, spam placement, or rejection.