How to Fix DMARC Policy Bounces: A Technical Guide

DMARC policy bounces are usually permanent delivery failures, not temporary mail delays. To fix DMARC policy bounces, identify which identity failed—visible From, SMTP envelope sender, or DKIM signing domain—then correct the DNS and sending configuration that prevents an aligned authentication pass.

What a DMARC policy bounce means

A DMARC policy bounce means the receiving mail system decided that a message claiming to be from a domain did not meet that domain’s published DMARC requirements. The recipient server may reject the message during SMTP delivery, route it to spam, or accept it with a warning depending on the domain’s DMARC policy and the receiver’s local rules.

The important point is that DMARC is not a standalone cryptographic check. It evaluates the domain in the visible RFC 5322 From: header—the address people see in their mail client—and asks whether either SPF or DKIM authenticated a domain that aligns with it.

A typical hard failure might look like this:

550 5.7.26 This mail has been blocked because the sender is unauthenticated.

Or it may be expressed less specifically:

550 5.7.1 Message rejected due to DMARC policy
554 5.7.5 Permanent authentication failure

The exact wording is receiver-specific. The key diagnostic signals are usually:

• A 5xx SMTP reply, which indicates a permanent failure for that delivery attempt.
• A reference to DMARC, unauthenticated mail, spoofing, policy, SPF, or DKIM.
• A failure concentrated at a particular mailbox provider or recipient domain.
• Authentication results in a delivered test message showing dmarc=fail.

Do not treat a 5xx DMARC rejection as a retry problem. Retrying the same unauthenticated message rarely changes the outcome. Fix the identity or DNS issue first, then resend the message after verification.

The DMARC pass condition you actually need

DMARC passes when at least one of the following is true:

1. SPF passes and the SPF-authenticated envelope sender domain aligns with the visible From: domain.
2. DKIM passes and the DKIM signing domain, shown in the d= tag, aligns with the visible From: domain.

You do not need both SPF and DKIM to pass DMARC, although operating with both is strongly recommended. Having two aligned authentication paths provides resilience when forwarding breaks SPF, a provider changes sending infrastructure, or a temporary DNS problem affects one mechanism.

Consider this message:

From: Billing <receipts@example.com>
Return-Path: bounce@mailer.example.net
DKIM-Signature: d=mailer.example.net; s=mail2026; ...

Even if SPF passes for mailer.example.net and DKIM passes for mailer.example.net, DMARC can still fail for example.com. The user-visible author domain is example.com, while both authenticated domains are mailer.example.net. Authentication passed, but neither result aligned.

Now compare it with this message:

From: Billing <receipts@example.com>
Return-Path: bounce@bounces.example.com
DKIM-Signature: d=example.com; s=mail2026; ...

Here, an SPF pass for bounces.example.com normally aligns with example.com under relaxed alignment, and a DKIM pass for d=example.com aligns directly. Either result can satisfy DMARC.

This distinction explains a large share of troubleshooting cases: the sender sees spf=pass or dkim=pass and assumes the message is compliant, but the recipient sees dmarc=fail because the authenticated domain is unrelated to the From: address.

Read the bounce before changing DNS

Do not start by changing a DMARC record. First, capture the evidence from a failed message and work backward. DNS changes without a clear diagnosis can create new failures, especially when a domain uses several tools for transactional mail, support mail, marketing campaigns, employee mail, invoices, and automated alerts.

For an SMTP relay, save the full relay response, recipient domain, timestamp, sending IP, envelope sender, and message identifier. For a REST email API, the initial HTTP response might only mean that the provider accepted the message for processing. The eventual downstream rejection may instead appear in an event feed, webhook payload, suppression log, delivery report, or bounce notification.

Collect these facts for one failed message:

If the message was accepted by one recipient but rejected by another, send a controlled test to a mailbox you can inspect. Open the raw message source and locate an Authentication-Results: header. It commonly resembles this:

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

A failed version may show the mismatch directly:

Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=provider-mail.example;
  dkim=pass header.d=provider-mail.example;
  dmarc=fail (p=reject dis=none) header.from=example.com

The first record says exactly what to preserve. The second says exactly what to fix: use an aligned custom return-path, an aligned DKIM signing domain, or both.

Check the published DMARC record first

The DMARC record is a DNS TXT record located at _dmarc beneath the domain being evaluated. For example.com, query:

_dmarc.example.com

A basic monitoring record is:

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

A more explicit example is:

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

The important tags are:

• v=DMARC1: identifies the record as DMARC and must come first.
• p=: requested policy for mail that fails DMARC: none, quarantine, or reject.
• rua=: destination for aggregate XML reports.
• adkim=: DKIM alignment mode, either relaxed (r) or strict (s).
• aspf=: SPF alignment mode, either relaxed (r) or strict (s).
• pct=: percentage of failing messages to which the requested policy applies.
• sp=: requested policy for subdomains when no more-specific subdomain DMARC record exists.

Use DNS query tools rather than trusting a DNS control panel’s display. Useful commands include:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

MXToolbox and similar DNS inspection tools can identify malformed syntax, duplicate DMARC records, missing policy tags, and common reporting-address issues. For a quick end-to-end deliverability test, mail-tester.com can expose visible authentication outcomes, though it should complement—not replace—testing at the recipient domains where your mail is actually failing.

Avoid multiple DMARC records

A domain should publish one DMARC TXT record at a given _dmarc name. Multiple separate DMARC records can cause DMARC evaluation problems. Combine tags into one valid record instead of creating one record for a policy and another for reporting.

Incorrect:

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

Correct:

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

Understand inherited subdomain policy

A message sent as alerts@notify.example.com may be evaluated against _dmarc.notify.example.com first. If that record does not exist, receivers can fall back to the organizational domain’s DMARC policy, and the parent record’s sp= tag can apply to subdomains.

This often surprises teams that have secured example.com but launch mail from updates.example.com, notify.example.com, or mail.example.com without checking their authentication alignment. Treat every domain and subdomain used in visible From: addresses as a separate sending identity to inventory and test.

Fix SPF failures and SPF alignment

SPF authorizes servers to send using the SMTP envelope sender domain, often visible in a Return-Path header after delivery. It does not authenticate the visible From: header directly.

A simple SPF record with a documentation-only example address looks like this:

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 -all"

The 192.0.2.0/24 range is reserved for documentation, so do not publish it in production. Your live record must use the IP ranges and include: mechanisms supplied by the services that actually send mail for your domain.

A production-shaped pattern might be:

example.com. IN TXT "v=spf1 include:spf.your-mail-provider.example include:_spf.workspace.example -all"

The provider hostnames above are placeholders. Copy only the precise SPF include value provided by the service you use.

Verify the right SPF domain

A common mistake is to inspect example.com when the message uses this envelope sender:

MAIL FROM:<bounce@bounces.example.com>

In that case, SPF is evaluated against bounces.example.com, not necessarily example.com. Query that exact domain and verify that its SPF record authorizes the actual transmitting infrastructure.

For DMARC under relaxed alignment, bounces.example.com can align with example.com because they share the same organizational domain. Under strict SPF alignment, the envelope sender domain must match the visible From: domain exactly. If your DMARC record contains aspf=s, a subdomain return-path may no longer align.

Keep one SPF record and stay below the lookup limit

Only one SPF policy should exist for a domain. Multiple TXT records beginning with v=spf1 can result in an SPF permanent error.

SPF evaluation also has a limit of 10 DNS-triggering lookups. Mechanisms such as include, a, mx, exists, redirect, and ptr can consume that budget. Nested include: records count too, which means a record that looks short can still exceed the limit after expansion.

Symptoms include:

spf=permerror
spf=fail
DMARC fail because no aligned DKIM pass was available

To fix this safely:

1. List every platform that sends with the relevant envelope domain.
2. Remove services that no longer send mail.
3. Merge valid authorization mechanisms into a single SPF record.
4. Check the expanded lookup count, not just the number of mechanisms in your visible record.
5. Prefer aligned DKIM as a durable second authentication path rather than relying solely on SPF.

Do not solve SPF lookup limits by casually replacing -all with ~all or ?all. Those suffixes change authorization policy but do not remove excessive DNS lookups. Likewise, do not add a second SPF record to “split” providers; that can make SPF fail entirely.

Fix third-party return-path misalignment

Many email services use their own bounce domain by default, such as bounces.provider.example. SPF may pass for that domain but fail DMARC alignment with example.com.

The usual fix is to configure a custom return-path or custom MAIL FROM subdomain, such as bounces.example.com, and publish the CNAME or TXT records that the provider requires. The exact DNS hostname and record type are provider-specific; never guess them. Use the provider’s authentication instructions or your email API setup documentation to obtain the exact values.

If a provider cannot offer an aligned envelope sender, make sure it signs mail with aligned DKIM. A valid aligned DKIM signature can still produce a DMARC pass when SPF is unaligned.

Fix DKIM failures and DKIM alignment

DKIM adds a cryptographic signature to the message. The recipient retrieves the public key from DNS using the selector in s= and the signing domain in d=.

For example:

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

The receiving server looks up:

tx2026._domainkey.example.com

A DKIM DNS record normally has a structure like this:

tx2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_MATERIAL"

The public key must match the private key used by the outbound signer. Do not manually invent the p= value, selector, or record type. Obtain the exact record from your mail provider or signing system.

The most common DKIM breakpoints

DKIM can fail for several different reasons:

• The selector record does not exist at selector._domainkey.domain.
• The DNS record is published under the wrong hostname.
• A copied key was truncated, corrupted, or wrapped incorrectly by the DNS interface.
• The message is signed with a domain that does not align with From:.
• The signing key was rotated, but DNS still contains the old public key.
• A mailing list, forwarding service, gateway, or downstream system modified signed headers or body content.
• The sending application bypassed the provider or relay that normally applies DKIM.
• The provider signs only its own domain because custom-domain authentication was not completed.

A particularly common configuration is this:

From: notifications@example.com
DKIM-Signature: d=provider.example; s=default; ...

That signature may be cryptographically valid but unaligned. For DMARC, configure the service to sign as example.com or an aligned subdomain such as mail.example.com, subject to your alignment mode.

Test DKIM with a delivered message

DNS validation alone is not enough. A correct DKIM record does not prove your production messages are signed with the corresponding key.

Send a fresh message through the exact path that is failing. If your application uses both REST sending and an SMTP relay, test each path separately. A backend service may use one provider configuration while a legacy app, job worker, CRM integration, or command-line script sends through another.

Inspect the received headers for:

dkim=pass header.d=example.com

Also confirm the header.d= domain aligns with the visible header.from= domain. If you see dkim=none, the sending path did not apply a DKIM signature at all. If you see dkim=fail, inspect the selector and record. If you see dkim=pass but dmarc=fail, focus on alignment.

Understand relaxed versus strict alignment

Alignment determines how closely the SPF or DKIM authenticated domain must match the visible From: domain.

With relaxed alignment, related subdomains usually align:

From domain: example.com
SPF domain:  bounces.example.com
DKIM domain: mail.example.com

With strict alignment, the domains must match exactly:

From domain: example.com
SPF domain:  example.com        -> aligned
DKIM domain: example.com        -> aligned

From domain: example.com
SPF domain:  bounces.example.com -> not aligned
DKIM domain: mail.example.com    -> not aligned

Relaxed alignment is the normal operational choice for many organizations because it supports distinct subdomains for bounce handling, product mail, and provider-specific signing. Strict alignment can be appropriate for tightly controlled domains, but it increases the chance that a previously working mail stream fails after a provider or subdomain change.

Check for these tags in the DMARC policy:

adkim=s
aspf=s

If either exists, evaluate whether strict alignment is intentional. Do not weaken alignment merely to hide an unknown sender. First identify the mail stream, validate that it is legitimate, and configure it properly. If a legitimate service needs a subdomain, an aligned DKIM domain or custom return-path is usually safer than broadly relaxing controls without an inventory.

Find the hidden sender that is breaking DMARC

Organizations rarely have only one email source. The transactional email service may be correctly authenticated while forgotten systems continue to send mail using the same visible From: domain.

Common hidden senders include:

• A website contact form using the visitor’s address as From:.
• A support desk or CRM sending from a default provider domain.
• A billing platform generating invoices and payment receipts.
• Monitoring, incident-response, or error-tracking alerts.
• A recruitment, survey, scheduling, or e-signature service.
• A legacy SMTP script on a server or printer.
• A marketing platform using a separate dedicated sending configuration.
• A forwarding rule that relays mail without preserving an aligned DKIM signature.

The website contact-form problem deserves special attention. If a user enters person@gmail.com and the form sends:

From: person@gmail.com

your server is effectively spoofing Gmail. Gmail’s DMARC policy protects that domain, so recipient systems may reject the message. The fix is not to add Gmail to your SPF record. Instead, send from an address you control and put the visitor’s address in Reply-To::

From: Website Form <forms@example.com>
Reply-To: person@gmail.com

This makes the visible author domain one that your mail system can authenticate.

Aggregate DMARC reports are useful for discovering unknown sources. They summarize which IP addresses sent mail claiming to be from your domain, the SPF and DKIM results, the evaluated DMARC policy, and receiver disposition. Review them before moving to a stronger policy or after introducing a new sending platform.

Use a safe remediation workflow

A DMARC bounce can tempt teams to make an immediate policy change such as p=none. That may reduce rejections for unauthenticated mail, but it does not repair the underlying identity problem and can weaken anti-spoofing protection. Use a controlled workflow instead.

Step 1: Freeze unnecessary changes

Avoid changing SPF, DKIM, DMARC, sender domains, and mail providers simultaneously. If multiple variables move at once, you will not know which change fixed or worsened delivery.

Step 2: Map the exact message identity

Record the visible From domain, envelope sender domain, DKIM d= domain, DKIM selector, sending IP, sending application, and recipient domain. This becomes the baseline for every test.

Step 3: Correct the failed mechanism

Use the evidence to select the smallest appropriate repair:

• spf=fail: authorize the actual sender for the exact envelope domain.
• spf=permerror: merge SPF records and reduce DNS-triggering lookups.
• dkim=none: enable signing on that mail path.
• dkim=fail: correct the selector, DNS record, key, or message-altering intermediary.
• SPF and DKIM pass but dmarc=fail: configure aligned domains.
• Authentication passes in one path but not another: authenticate the overlooked sender or route it through the approved outbound service.

Step 4: Wait for DNS publication, then query authoritative results

DNS propagation timing depends on TTLs, resolver caches, and how the prior record was published. Do not validate only from the DNS editor where you made the change. Query public DNS and, when possible, multiple resolvers.

For example:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT tx2026._domainkey.example.com

Step 5: Send a new test message

A message signed before a DKIM correction will not become valid retroactively. Generate a fresh test after DNS is visible. Inspect the received headers rather than relying solely on the provider’s “sent” status.

Step 6: Confirm both authentication and alignment

Your target result is not merely SPF or DKIM success. It is:

spf=pass and aligned
or
dkim=pass and aligned
therefore
dmarc=pass

Step 7: Re-enable normal sending and monitor bounces

Once a controlled test passes, send a small production batch and watch bounce events by recipient domain. If only one mailbox provider continues to reject mail, compare its returned message and received headers carefully before making broad DNS changes.

When the recipient domain has p=reject

Sometimes the domain with the strict DMARC policy is not yours. For example, your application may be trying to send mail with a customer’s, employee’s, or visitor’s address in the visible From: header. If that external domain publishes p=reject, a receiving server can reject your message because you are not authorized to send as that domain.

You cannot fix this by editing your own DMARC record. You do not control the external domain’s SPF, DKIM keys, or policy.

Use one of these patterns instead:

• Send from a domain you own, such as support@example.com, and use Reply-To for the external address.
• Ask the domain owner to authorize your sending infrastructure and configure an aligned signing path, if you have a legitimate managed-service relationship.
• Use a per-customer subdomain only when you control its DNS and can authenticate it correctly.
• Avoid allowing arbitrary user input to populate the From: header.

This is especially relevant for multi-tenant applications. Letting every customer type any arbitrary sender address may look flexible, but it creates a high probability of DMARC bounces and impersonation risk. A verified-domain workflow is more reliable: users prove control of a domain, publish the required DNS records, and only then send with that domain in From:.

Forwarding, mailing lists, and message modification

Not every DMARC failure originates with the original sender. Forwarding commonly breaks SPF because the forwarding server’s IP is not authorized by the original sender’s SPF record. DKIM may preserve DMARC compliance if the message remains unchanged and the DKIM signature is still valid.

Mailing lists and gateways can create a tougher case. They may add a subject prefix, footer, disclaimer, or other content that breaks the original DKIM body signature. If forwarding also breaks SPF, there may be no aligned authentication pass left.

As a sender, the practical defense is to ensure that your mail has a valid, aligned DKIM signature before it enters the ecosystem. As an operator of a forwarding or list system, avoid unnecessary modification, use modern authentication-preserving practices where available, and understand that receiver handling can vary.

Do not assume that a DMARC failure observed after forwarding means your original SPF record is wrong. Compare a direct-delivery test with a forwarded-message test. If direct mail passes and forwarded mail fails SPF, that behavior can be expected. The question becomes whether aligned DKIM survives the forwarding path.

Prevent future DMARC policy bounces

The long-term fix is operational discipline, not a one-time DNS change. Email identity should be part of application release and vendor-management processes.

Build these checks into your workflow:

• Maintain an inventory of every system allowed to use each From: domain.
• Require domain verification before a product, team, or customer can send as a domain.
• Standardize on aligned DKIM for all outbound mail streams.
• Use aligned custom return-path domains where your providers support them.
• Review SPF whenever a new sending vendor is added or removed.
• Keep SPF below its DNS lookup limit and remove retired includes.
• Monitor aggregate DMARC reports for unknown IPs, failing sources, and unexpected subdomains.
• Test transactional, campaign, support, and infrastructure-alert mail separately.
• Preserve raw message headers from routine deliverability tests.
• Treat changes to From:, DKIM selectors, sending providers, and bounce domains as deliverability changes requiring QA.

DMARC does not grant a deliverability bonus by itself. A DMARC pass cannot compensate for poor list quality, spam complaints, broken unsubscribe handling, suspicious content, or a poor sending reputation. But without DMARC alignment, messages may never reach the stage where those other factors matter.

Conclusion

To fix DMARC policy bounces, start with the failed message—not with guesswork. Read the SMTP response or delivery event, identify the visible From: domain, inspect SPF’s envelope domain and DKIM’s d= domain, and verify that at least one authenticated result aligns.

The durable solution is usually straightforward: publish one valid SPF record, enable valid DKIM signing, use domains you control in From:, and configure a custom aligned return-path or DKIM signing domain for third-party senders. Validate with fresh test messages and received headers, then use DMARC reporting to catch the next overlooked sender before it causes production bounces.

FAQ

Does a DMARC policy bounce mean both SPF and DKIM failed?

Not necessarily. DMARC fails when neither SPF nor DKIM produces an aligned pass. SPF and DKIM can both show pass for a provider domain while DMARC fails because the visible From: domain is different.

Can I fix a DMARC bounce by changing p=reject to p=none?

You can reduce enforcement for mail claiming to be from your own domain, but that does not repair the broken sender configuration. Use p=none for monitoring during a controlled rollout, not as a permanent substitute for aligned SPF or DKIM.

Why does mail work for some recipients but bounce for Gmail or another provider?

Receiving systems apply their own enforcement, reputation, and filtering policies. A weak or unaligned configuration may be tolerated by one receiver and rejected by another. Test the exact recipient domain that is bouncing your messages.

What is the fastest way to confirm a fix?

Send a new message through the same production path to a mailbox you control, view the full headers, and confirm dmarc=pass. Also verify that the passing SPF or DKIM domain aligns with the visible From: domain.

Should I rely on SPF or DKIM for DMARC?

Use both. SPF is useful but can break during forwarding and is tied to the envelope sender. DKIM is often more resilient when it remains intact, and aligned DKIM provides a strong fallback when SPF is unaligned or fails.