“Message rejected due to DMARC policy”

The bounce message "550 5.7.26: Message rejected due to DMARC policy" indicates that the recipient’s mail server refused to accept your email because the message failed DMARC authentication and your domain’s published DMARC record specifies an enforcement policy of p=reject. This error means the receiving system detected an unaligned sender pretending to be your domain, or a legitimate outbound service was misconfigured.

Quick Answer

To resolve this bounce, ensure your email passes either SPF or DKIM with domain alignment. The domain found in the visible From: header must match the domain in the d= tag of the DKIM signature or the SPF Return-Path. Fix misaligned third-party tools or missing DKIM keys immediately.

---

What the Error Means

Domain-based Message Authentication, Reporting, and Conformance (DMARC) protects your domain against spoofing and phishing. When an email server receives a message claiming to come from your domain:

1. It checks whether the message passes SPF authentication against the envelope sender address.
2. It checks whether the message contains a valid DKIM cryptographic signature.
3. It evaluates DMARC Identifier Alignment: does the domain in the visible From: address header match the domain authenticated by SPF, DKIM, or both?

If neither SPF nor DKIM passes and aligns with the header From: domain, DMARC evaluation fails. If your DNS publishes a DMARC policy of v=DMARC1; p=reject;, the receiving server follows your instructions and rejects the incoming message outright during the SMTP connection.

       [Incoming Email Received]
                   │
      ┌────────────┴────────────┐
      ▼                         ▼
   [SPF Check]             [DKIM Check]
Does envelope IP pass?   Is signature valid?
Does Return-Path align?  Does d= domain align?
      │                         │
      └────────────┬────────────┘
                   ▼
     Did at least ONE pass & align?
        ┌──────────┴──────────┐
       YES                    NO
        │                     │
   DMARC Passes        DMARC Fails
Message Delivered      Check p= policy:
                       • p=none: Deliver
                       • p=quarantine: Spam
                       • p=reject: Bounce (550)

Common Causes of DMARC Policy Rejection

A DMARC policy rejection rarely happens without an underlying mismatch between what your users send and what your DNS authorizes:

• Third-Party Platform Misalignment: Tools like Mailchimp, Zendesk, or Salesforce send mail using their own domain in the envelope sender (bounces.sendgrid.net) and your domain in the header From:. Because the envelope domain does not match the header domain, SPF alignment fails. If DKIM is not custom-configured with your domain, DMARC fails completely.
• Missing or Inactive DKIM Key: The domain has a strict DMARC policy, but outbound mail is missing a DKIM signature, or the public key in your DNS is missing or malformed. For setup guidance, refer to How to Generate 2048-bit DKIM Key in Admin Console.
• Automated Email Forwarding: A recipient configured their mailbox to auto-forward incoming mail to an external provider (such as forwarding work mail to a personal Gmail account). Forwarding alters the sending IP, which breaks SPF. If the message did not have a robust DKIM signature, or if the forwarding server modified the message body (breaking the DKIM cryptographic hash), DMARC fails at the final destination.
• Subdomain Policy Inheritance: An automated notification system sends from billing.example.com, but only the apex domain example.com has authentication configured. If the apex DMARC policy includes sp=reject (or defaults to p=reject), the subdomain mail is rejected.

Diagnostic Steps: Pinpointing the Failure

To find out why your message was rejected, you need the Non-Delivery Report (NDR) or access to the sending configuration.

Step 1: Read the Non-Delivery Report

Review the diagnostic text in the bounce notification. Look for the exact status code and server remarks:

550-5.7.26 This message does not pass authentication checks (DMARC policy
550-5.7.26 requires that the sender's message pass either SPF or DKIM
550-5.7.26 with alignment). Please visit <https://support.google.com/mail/?p=RfcDmarc>

If the error code points specifically to missing or invalid SPF records prior to DMARC evaluation, see How to Fix Gmail Error 550 5.7.26: SPF Missing/Invalid.

Step 2: Audit the Header From: vs. Authenticated Domains

Inspect an outbound test email sent from the problematic source:

1. Verify the visible From: address: marketing@yourcompany.com.
2. Check the DKIM-Signature header: Look for d=yourcompany.com. If d= points to a third-party vendor (e.g., d=sharedservice.net), DKIM is unaligned.
3. Check the Return-Path header: If it reads bounces@vendor.com, SPF cannot provide DMARC alignment unless customized.

Step-by-Step Fixes

Fix 1: Configure Custom DKIM on the Sending Service

Because SPF frequently breaks during email forwarding, DKIM is the most resilient path to DMARC compliance.

1. Navigate to the admin settings of the third-party sending application (e.g., Salesforce, SendGrid, Zendesk).
2. Locate the “Domain Authentication” or “Sender Authentication” section.
3. Generate a dedicated DKIM key pair. The service will supply two CNAME or TXT records.
4. Add these records to your domain’s DNS zone.
5. Return to the application and complete the verification step. Future outbound messages will now sign with d=yourcompany.com, achieving full DMARC alignment.

Fix 2: Set Up Custom Return-Path for SPF Alignment

If the application allows, configure a custom bounce domain (such as mail.yourcompany.com).

1. Create a CNAME record in your DNS pointing mail.yourcompany.com to the tracking server designated by the provider.
2. The service will now generate envelope Return-Path addresses matching your subdomain.
3. Under relaxed DMARC alignment rules (the default adkim=r; aspf=r;), mail.yourcompany.com aligns successfully with yourcompany.com.

Fix 3: Temporarily Relax Your DMARC Policy (Emergency Triage)

If critical business operations are halted because multiple legitimate systems are bouncing, downgrade your DMARC policy while fixing the underlying streams:

1. Open your domain’s DNS manager.
2. Edit the TXT record at _dmarc.yourcompany.com.
3. Change p=reject to p=quarantine or p=none: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com;
4. Important: A policy of p=none stops all rejections and allows you to collect aggregate reports (rua) to audit all sending sources without impacting delivery. Once all streams align, step back up to p=quarantine and then p=reject.

For an exhaustive operational guide on choosing policy thresholds, see How to Resolve DMARC Policy Rejects: Reject vs. Quarantine.