Email Authentication DMARC: Setup, Alignment, Reports, and Fixes

Email authentication DMARC is the control that connects your visible From address to SPF and DKIM, tells receiving systems how to handle failures, and gives you evidence about who is sending as your domain. The hard part is not adding one TXT record: it is discovering every legitimate sender, making its authentication align, and only then enforcing a policy.

What email authentication DMARC actually does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email-authentication protocol published in DNS that lets the owner of a domain state a requested handling policy for messages that claim to be from that domain and fail DMARC evaluation.

A receiving mail system evaluates DMARC against the domain in the visible From: header—the address a person sees in an email client. It then checks whether either SPF or DKIM both passes and is aligned with that visible From domain. If neither authenticated identifier aligns, the message fails DMARC.

That distinction explains why DMARC matters. SPF by itself evaluates the SMTP envelope sender, commonly shown as Return-Path; DKIM evaluates the domain in a cryptographic signature. Either can pass while an attacker displays a completely different brand in the From header. DMARC closes that identity gap by requiring a passing result to correspond to the From domain.

DMARC has three jobs:

1. Authentication policy: it asks receivers to apply none, quarantine, or reject when DMARC fails.
2. Domain alignment: it ties the visible From domain to a passing SPF or DKIM domain.
3. Reporting: it can request aggregate reports that show authentication results and sending sources using your domain.

DMARC is not a spam filter, a guarantee of inbox placement, or a universal blocking command. A receiver still makes the final delivery decision using its own security and reputation systems. It is, however, a foundational anti-spoofing control and a practical requirement for many high-volume senders.

Why DMARC is important for senders, marketers, and product teams

For a business, the most immediate DMARC benefit is reducing direct impersonation. Without enforcement, an attacker can often send mail with a visible From address such as billing@example.com even though the message did not originate from your mail systems.

DMARC also forces operational clarity. Most organizations send email from more systems than they initially remember: Google Workspace or Microsoft 365, a marketing platform, a CRM, a support desk, invoice software, transactional-email infrastructure, a form plugin, an applicant-tracking system, and a monitoring service. Every system that uses your domain in the visible From header must be accounted for before you safely enforce DMARC.

For marketing teams, this makes domain governance a deliverability issue rather than just an IT task. A newsletter platform may have a valid SPF include and still fail DMARC if it signs DKIM with the platform's own domain while your campaign uses From: news@yourbrand.com. The recipient sees your brand, but the authentication identity does not align with it.

Major mailbox providers also publish sender requirements that make the practical case for DMARC. Google requires bulk senders—defined in its guidelines as senders of more than 5,000 messages per day to personal Gmail accounts—to use SPF, DKIM, and DMARC. Google allows a p=none DMARC policy for that baseline requirement, but authentication and alignment still have to work. Yahoo likewise requires bulk senders to authenticate with SPF and DKIM and have a DMARC policy in place.

How DMARC, SPF, and DKIM work together

DMARC depends on SPF and DKIM, but it does not replace either one. Think of the three controls as separate layers with different evidence.

SPF: which servers may use an envelope domain

Sender Policy Framework (SPF) is a DNS TXT record that authorizes hosts or services to send mail using a domain in the SMTP envelope sender or MAIL FROM identity. A simplified record might look like this:

example.com. IN TXT "v=spf1 include:_spf.google.com -all"

The recipient compares the connecting sender to the published SPF policy and returns a result such as pass, fail, softfail, neutral, or permerror. SPF is useful, but forwarding can legitimately break it: a forwarding server often sends the message from its own IP address, which is not listed in the original sender's SPF record.

SPF also has a meaningful implementation limit. The SPF specification limits DNS-querying terms during evaluation, so repeatedly adding include: mechanisms for every vendor can create a permerror. Use one SPF record per domain, consolidate providers carefully, and check the resulting lookup count with a capable SPF analysis tool.

DKIM: a verifiable signature on the message

DomainKeys Identified Mail (DKIM) adds a DKIM-Signature header when a system sends a message. The signature includes a signing domain, written as d=, and a selector, written as s=. The receiver retrieves the public key from DNS at:

selector._domainkey.signing-domain

For example, a sender that signs with d=example.com; s=mktg2026 needs a DNS record at:

mktg2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

DKIM commonly survives ordinary forwarding better than SPF because the signature is attached to the message. It can still fail if a later system alters a signed header or body content in a way that breaks the signature. Mailing lists, footers, content scanners, and message rewriters are common sources of that behavior.

DMARC: does a passing identity match the From domain?

DMARC checks the From: domain and asks two questions:

• Did SPF pass for an envelope domain that aligns with the From domain?
• Did DKIM pass for a signing domain that aligns with the From domain?

Only one aligned pass is needed for DMARC to pass. In a resilient configuration, both SPF and DKIM pass and align. That gives your mail a second route to success when forwarding, a vendor problem, or a configuration change affects one mechanism.

Here is a concrete example. Suppose the visible message header is:

From: Acme Updates <news@acme.example>

These outcomes are possible:

DMARC alignment: relaxed versus strict

Alignment is the setting that causes most “SPF passed but DMARC failed” surprises.

Relaxed alignment allows the authenticated domain to be the same organizational domain as the visible From domain. In practical terms, mail.example.com can align with example.com. Strict alignment requires an exact domain match.

DMARC controls alignment with two optional tags:

• adkim=r or adkim=s for DKIM alignment
• aspf=r or aspf=s for SPF alignment

r means relaxed and is the default when the tag is omitted. s means strict.

A relaxed-alignment record can look like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; adkim=r; aspf=r"

A strict-alignment record can look like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; adkim=s; aspf=s"

Do not choose strict alignment only because it sounds more secure. It is appropriate when you deliberately control exact signing and envelope domains, but it can expose overlooked third-party senders. Many organizations begin with relaxed alignment, get all authorized mail passing, and make a deliberate decision about strict alignment later.

A useful operational pattern is to use a dedicated sending subdomain. For example, send marketing from news.example.com and transactional mail from notify.example.com, while keeping employee mail on example.com. This does not eliminate the need for alignment, but it reduces blast radius, makes vendor ownership clearer, and separates reputation streams.

The DMARC DNS record: syntax and important tags

Publish a DMARC record as a DNS TXT record at _dmarc.your-domain. For example.com, the host/name is:

_dmarc.example.com

The record must begin with v=DMARC1. A safe monitoring-stage record is:

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

This says: evaluate DMARC, request aggregate reports at the designated mailbox, and request no special disposition for failures. p=none is not enforcement, but it is the correct first production policy for most domains because it produces visibility without deliberately quarantining or rejecting legitimate mail.

Core DMARC tags

A more complete monitoring record could be:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

An enforcement record might be:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Use semicolons between tag-value pairs. In a DNS control panel, enter the value exactly as your provider expects; many interfaces add quotation marks automatically. Do not create several competing DMARC TXT records at the same _dmarc hostname. Receivers can treat multiple DMARC records as an error rather than choose one for you.

What p=none, p=quarantine, and p=reject mean

• p=none requests monitoring only. The receiver can still filter a message independently.
• p=quarantine requests that DMARC-failing mail be treated suspiciously, often sent to spam or junk.
• p=reject requests that DMARC-failing mail be rejected during delivery.

The policy is a request, not a contractual guarantee. Receivers can apply local policy, and the exact behavior of quarantine varies by recipient system. That is why the success criterion is not “every test message behaved identically everywhere”; it is that your legitimate mail authenticates and aligns while unauthorized mail is increasingly unable to impersonate your From domain.

A step-by-step email authentication DMARC rollout

The safest implementation is an inventory-and-enforcement project, not a one-click DNS edit.

1. Inventory every sender that uses your domain

Build a list of all services that can send an email with your domain in the visible From field. Include systems that send rarely, such as a website contact form, an annual tax platform, security alerts, recruiting software, and ERP-generated invoices.

For each sender, record:

• The visible From domain it uses.
• The envelope-from or return-path domain, if the vendor exposes it.
• The DKIM signing domain and selector.
• The vendor's required SPF and DKIM DNS records.
• The system owner inside your organization.
• Whether the sender can use a dedicated subdomain.

Do not assume an SPF include authorizes every workflow from a vendor. A platform may use different sending paths for campaigns, transactional messages, support notifications, and link-tracking domains.

2. Configure DKIM for every legitimate source

For each sending platform, enable custom-domain DKIM and publish the CNAME or TXT records it supplies. Vendor instructions vary: some ask you to publish two or three CNAME records that point to vendor-managed DKIM keys; others provide a DKIM TXT public key directly.

The important verification point is not merely that a DNS record exists. Send a real message and inspect the received headers. You want to see a DKIM pass whose d= domain aligns with the visible From domain.

3. Build one correct SPF record per sending domain

Combine the authorized mechanisms into a single SPF TXT record rather than creating separate SPF records for each vendor. A conceptual record might be:

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.transactional-vendor.example -all"

That is only an example: copy the precise include domain, IP mechanism, and recommended syntax from each vendor's documentation. Review the cumulative DNS lookup count, avoid obsolete senders, and make sure the record ends in a policy consistent with your intended authorization.

4. Publish DMARC at p=none

Create one DMARC record at the root domain. Add an rua address that you can actually receive and process. Aggregate reports are machine-readable XML and can arrive compressed, so a normal shared inbox quickly becomes impractical for an active domain.

You can receive them directly and parse them with internal tooling, or use a DMARC-reporting service. If reports go to a different domain, DMARC includes an external-reporting authorization mechanism; follow the report processor's setup instructions rather than assuming that a mailbox forwarding rule alone is sufficient.

5. Monitor reports and fix unknown sources

Keep p=none while you classify every meaningful report source. Match source IPs and authentication domains to known vendors. Investigate any source you cannot identify, especially sources that generate mail with a From domain you own but fail both aligned SPF and aligned DKIM.

A DMARC report tells you about mail receivers chose to report; it is valuable telemetry, not a complete global log of every message ever sent. Combine it with vendor logs, sent-message samples, and recipient-side tests.

6. Move to enforcement in stages

When legitimate traffic consistently passes, change to p=quarantine. Some teams use pct for a staged increase, for example:

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

After reviewing results, raise the percentage and eventually move to p=reject. A typical final record is:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Do not use pct as a substitute for fixing a known broken source. It only limits the requested application of the policy; it does not make the underlying configuration correct.

Worked example: protecting a small business domain

Assume a company owns northstar.example. Employees send from Google Workspace, marketing campaigns go through a newsletter vendor, and product receipts go through a transactional-email vendor.

The company wants all mail to display a From address at northstar.example and wants to reach a reject policy safely.

Step 1: Set up Google Workspace authentication

The team enables DKIM signing in Google Workspace and publishes the DKIM DNS record generated by the Google Admin console. It also creates the SPF record Google documents, then plans to merge additional authorized senders into that same SPF record.

Step 2: Set up the marketing vendor correctly

Instead of accepting the vendor's default signing domain, the team configures branded DKIM for northstar.example or a controlled subdomain such as news.northstar.example. It adds the vendor-supplied CNAME records and confirms that a campaign test message contains a DKIM signature whose d= domain is aligned with the address in From:.

If the vendor's default behavior produces d=vendor.example while the campaign says From: Northstar <hello@northstar.example>, a DKIM pass alone will not make DMARC pass. The team must enable custom DKIM, use an aligned subdomain, or make aligned SPF work through a custom return-path domain.

Step 3: Add transactional mail

The product team adds the transactional provider's custom DKIM records and configures a branded return-path where supported. They send a password-reset test, an invoice test, and an account-alert test because different message types can travel through different infrastructure.

Step 4: Publish monitoring DMARC

The DNS record is:

_dmarc.northstar.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r"

Step 5: Validate DNS and message headers

From a terminal, the team checks the published DMARC record:

dig +short TXT _dmarc.northstar.example

They also check a known DKIM selector when the vendor exposes it:

dig +short TXT selector1._domainkey.northstar.example

Then they send a test to a mailbox they control. In the full message headers, they look for an Authentication-Results line similar to:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.northstar.example;
  dkim=pass header.d=northstar.example;
  dmarc=pass header.from=northstar.example

The exact header formatting differs by receiver. The meaningful result is dmarc=pass and at least one aligned SPF or DKIM pass.

Step 6: Enforce after the evidence is clean

After reports show that the three legitimate systems pass DMARC and unknown failures have been investigated, the company changes to p=quarantine, then ultimately to p=reject. It continues monitoring reports because new SaaS tools, acquisitions, agencies, and website changes can introduce new senders later.

How to read DMARC aggregate reports

Aggregate reports are XML documents, often compressed, generated by participating receivers. They summarize observed mail using your From domain over a reporting period.

The important fields generally answer four questions:

1. Which source IP sent mail?
2. How many messages did the receiver see from that source?
3. What was the visible From domain and the DMARC policy?
4. Did SPF and DKIM pass, and did their domains align?

A report record may reveal a source IP that belongs to your newsletter tool and has a high message count. If SPF says pass but DKIM says fail and the reported disposition is none under your monitoring policy, you still need to check alignment. A passing SPF identity at vendor.example is not enough for a visible From address at example.com.

Prioritize report findings in this order:

• High-volume legitimate failures: likely to affect customers or campaigns when you enforce.
• Unknown high-volume traffic: possible active spoofing or a forgotten vendor.
• Known vendor with unaligned DKIM: usually fixable through branded DKIM or a custom sending domain.
• Low-volume unexpected traffic: investigate before dismissing it; it may be a rare but business-critical system.

Do not mistake a DMARC report count for a count of messages your platform sent. It is an observation from one reporting receiver, and different receivers may report different subsets or formats.

Common DMARC failures and how to fix them

“SPF passes, but DMARC fails”

This almost always means SPF passed for a domain that does not align with the visible From domain. Inspect smtp.mailfrom= in the authentication results. Configure a custom bounce/return-path domain with the vendor if available, or make sure aligned DKIM passes.

“DKIM passes, but DMARC fails”

Look at header.d=. If it is the vendor's domain rather than your domain or an aligned subdomain, turn on custom DKIM for the From domain. Also confirm that the message's From header has not been rewritten by an intermediary.

“Our DMARC record exists, but tools say it is invalid”

Check the record hostname first: it must be _dmarc.example.com, not example.com and not dmarc.example.com. Then check that there is one DMARC TXT record, it begins with v=DMARC1, and your DNS interface did not create unintended nested names such as _dmarc.example.com.example.com.

“Adding DMARC broke a legitimate sender”

A monitoring policy should not be the cause of a DMARC rejection request, so first verify the published policy and the exact domain being used. If you have moved to quarantine or reject, temporarily correct the sender configuration or move that workflow to a dedicated subdomain with its own properly aligned SPF and DKIM. Avoid permanently weakening the parent domain's policy to accommodate one unmanaged vendor.

“Forwarded mail fails SPF”

That is expected in many forwarding paths because the forwarder is not an IP address authorized by the original sender's SPF policy. Aligned DKIM is the durable fallback, so ensure you sign outbound mail and avoid unnecessary modifications that break signatures.

“Our marketing platform added an SPF record for us”

Check whether it created a second SPF record at the same domain. SPF should be published as one coherent record. Merge the vendor's required mechanism into your existing record after confirming the syntax and lookup impact.

How to tell your DMARC implementation worked

A successful implementation is not just a green DNS checker result. It has technical, operational, and security evidence.

Technical checks

• dig or a DNS lookup returns exactly one valid TXT record at _dmarc.your-domain.
• Each legitimate mail stream shows dmarc=pass in received-message authentication results.
• For every important sender, SPF or DKIM passes and aligns with the visible From domain.
• DKIM public-key records resolve at the selector hostnames your senders use.
• The published SPF record is singular, valid, and within SPF evaluation limits.

Operational checks

• DMARC aggregate reports arrive at the configured destination and are reviewed on a recurring schedule.
• Every report source is mapped to a known internal system, an approved vendor, or an investigated unknown source.
• New email vendors have an authentication checklist before launch.
• Marketing, product, support, finance, and IT know who owns each sending domain.

Security checks

• Your policy advances from p=none to enforcement after legitimate sources are fixed.
• A controlled unauthorized spoofing test is handled according to the policy at receivers that honor it.
• Lookalike domains, parked domains, and unused subdomains have a documented email policy rather than being ignored.

Remember that an externally spoofed message can be blocked, quarantined, accepted, or categorized differently by different mailbox providers. The measurable objective is that legitimate mail authenticates and that your published policy asks receivers to stop unauthenticated, unaligned use of your domain.

DMARC strategy for subdomains, parked domains, and multiple brands

A parent-domain policy can affect subdomains when they do not publish their own DMARC record. The sp= tag lets you specify a distinct requested policy for subdomains.

For example:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com"

In this example, the organizational domain requests rejection, while subdomains without their own record receive a quarantine policy. Whether that is the right configuration depends on how your organization delegates subdomains and whether they are used for mail.

For high-risk or high-volume streams, publish explicit records on the sending subdomains and assign clear ownership. For example, news.example.com can have its own DMARC policy, report address, SPF record, and DKIM selectors. This makes it easier to change vendors without altering employee mail or core transactional traffic.

Parked domains deserve attention too. If a domain is registered only to protect a brand and should never send mail, publish a DMARC policy that reflects that intent after confirming no legitimate service uses it. Do not copy a record blindly across all brands: first verify the actual mail flows for each domain.

Practical tools and workflow choices

You can implement DMARC without buying a platform if your volume is small and your team can parse DNS and XML reports. In practice, a reporting tool is often useful once reports arrive from multiple receivers or multiple domains are involved.

Choose tooling based on the job it must perform:

• DNS lookup tools: verify that a DMARC, SPF, or DKIM record is publicly resolvable and syntactically plausible.
• Header analyzers: inspect a real received message to see SPF, DKIM, and DMARC results.
• DMARC-report processors: aggregate XML reports, identify sending services, and show alignment failures.
• Email-platform dashboards: verify that a particular vendor is signing with your configured domain and selector.
• Mailbox-provider dashboards: help high-volume senders observe provider-specific compliance or delivery signals.

No tool can replace a sending inventory. A dashboard can reveal an unknown IP address, but only your organization can decide whether it belongs to an approved payroll vendor, an abandoned web form, an agency campaign, or an attacker.

FAQ

What is the minimum DMARC record I can publish?

The smallest useful monitoring record is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none"

Add rua=mailto:... if you want aggregate reports, which is strongly recommended for a real rollout.

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. Operating both is still best practice because one mechanism can fail in situations where the other succeeds.

Should I start with p=reject?

Usually no. Start with p=none, collect reports, identify every legitimate sender, fix alignment, and then progress to quarantine and reject. Publishing reject before inventorying vendors can cause legitimate business mail to be treated as fraudulent.

Why does a vendor's SPF setup not automatically make DMARC pass?

SPF validates the envelope sender domain, not necessarily the visible From domain. If the vendor uses its own return-path domain, SPF may pass but not align. Configure an aligned custom return-path or aligned DKIM.

Can DMARC stop phishing that uses a lookalike domain?

DMARC protects the domain you own, such as example.com. It does not prevent an attacker from registering a different-looking domain such as examp1e.com. Brand monitoring, user education, mailbox-provider filtering, and defensive domain registration may still be necessary.