Troubleshoot DMARC failures for outgoing email in Adobe Commerce on Cloud infrastructure with SendGrid

If outgoing emails from your store (order confirmations, password resets, and similar transactional email sent through Adobe’s built-in SendGrid integration) are failing DMARC checks, being marked as spam, or getting rejected by recipient mail servers, there are two distinct possible causes. Check which one applies to you before making any DNS changes.

Description description

Environment

Issue/Symptoms

Before you start: Confirm this is actually an authentication problem.

Not every delivery failure reported alongside DMARC monitoring is caused by DMARC/DKIM/SPF - recipient-side bounces (full mailbox, greylisting, IP throttling) look similar in reports but have nothing to do with domain authentication. Check the specific bounce/block reason in your SendGrid activity feed before assuming this guide applies.

How to confirm each symptom

Bouncing or rejected with DMARC-related errors: Open the raw source of the bounced or rejected message in your mail client and check the Authentication-Results header.

Example:

Authentication-Results: mx.google.com;
       dkim=fail;
       spf=fail (google.com: domain of bounce@mail.adobe.com does not designate XXX.XXX.XXX.XXX as permitted sender);
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=adobe.com

What to look for: A dmarc=fail result in this header confirms the rejection is DMARC-related, not an unrelated bounce (full mailbox, greylisting, IP throttling).

Resolution resolution

Follow these steps to resolve the issue:

Step 1: Check whether your domain already publishes a DMARC record

Run this to see if a policy already exists:

dig TXT _dmarc.yourdomain.com +short

What to look for: If a policy exists, this returns a quoted TXT value starting with v=DMARC1; (For example: "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"). If the command returns nothing, no DMARC record is published for that domain. Validated example: querying _dmarc.adobe.com currently returns nothing, meaning adobe.com has no DMARC record published.

Scenario A: A DMARC record already exists (most common)

If a record is returned, your domain already has a DMARC policy - typically set independently by your organization’s IT or security team, unrelated to Adobe Commerce. In this case, DMARC failures almost always mean SendGrid’s domain authentication (DKIM and SPF) isn’t yet set up or aligned for your sending domain, not that anything is wrong with your DMARC record itself.

Resolution: Follow the existing SendGrid email service documentation to request DKIM and SPF domain authentication via a Support case. Once SendGrid’s DKIM/SPF records are correctly added to your DNS and aligned to your sending domain, your existing DMARC policy will start passing - no changes to the DMARC record itself are needed.

DNS record values can change over time: Don’t reuse CNAME/TXT values from an old Support case or an internal document. SendGrid sub-account assignments can be reissued, so a record that was correct in the past may no longer match your current SendGrid configuration. Always request current values via a new Support case rather than reapplying historical ones.

If this is a Staging or non-production environment: SendGrid is enabled by default for Staging and Production, but DKIM/SPF domain authentication is commonly requested for Production only and never followed up for Staging. It can appear to work for months (riding on a lenient or absent DMARC policy) and then fail as soon as your organization tightens DMARC enforcement. If you’re only seeing failures in Staging while Production is fine, request DKIM/SPF authentication for the Staging environment specifically - don’t assume it was already covered by the Production request.

Verify DKIM/SPF records have propagated

Once DKIM/SPF domain authentication has been requested and applied, confirm the records have actually propagated in DNS before re-testing DMARC alignment or reopening a case. SendGrid’s domain authentication publishes three CNAME records for your sending subdomain: one for link branding (em) and two for the DKIM signing keys (s1._domainkey, s2._domainkey).

dig CNAME em.yourdomain.com +short
dig CNAME s1._domainkey.yourdomain.com +short
dig CNAME s2._domainkey.yourdomain.com +short

What to look for: Each command should return a CNAME target ending in .sendgrid.net. If a command returns nothing, that record either hasn’t been added yet or hasn’t propagated. Validated example: querying s1._domainkey.adobe.com and s2._domainkey.adobe.com returns:

s1.domainkey.uXXXXXXX.wlXXX.sendgrid.net.
s2.domainkey.uXXXXXXX.wlXXX.sendgrid.net.

An empty result, as returned by the same check against em.adobe.com in this example, means that particular record isn’t configured. Request it explicitly, rather than assuming it was included with a prior DKIM/SPF request. If a record still isn’t resolving 24-48 hours after being added, follow up on the existing Support case rather than opening a new one.

Scenario B: No DMARC record exists

If the command above returns nothing, your domain has no DMARC policy at all. In this case, in addition to setting up DKIM/SPF per Scenario A, you should also publish a DMARC record. Start in monitoring mode, not enforcement:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Don’t jump straight to p=quarantine or p=reject before confirming your own legitimate mail passes, because doing so can cause your own transactional email to be silently rejected by recipient servers.

Related reading