SendGrid says the domain is verified, but is your mail actually aligned with your From address?

What the DNS records are doing

Domain authentication publishes records so receiving servers can check that SendGrid may send as your domain. With SendGrid's automated security switched on, the documentation describes CNAME records: one for the return-path host used for SPF, two for the DKIM keys, and a DMARC TXT record at the underscore-dmarc name. With it switched off you enter MX and TXT records yourself and must update them when your set-up changes. Follow the exact list your own dashboard generates rather than a generic example, because the host names are specific to your account.

• Automated security needs a DNS host that accepts underscores in CNAME names.
• SendGrid applies the authentication when your From domain matches the authenticated domain.
• A subdomain does not inherit a parent domain's authentication permissions.

Pass and aligned are different results

DMARC does not ask only whether SPF or DKIM passed; it asks whether the passing identifier matches the domain in the From header. The DMARC specification defines relaxed alignment, where both share the same organisational domain, and strict alignment, where they must match exactly. In relaxed mode a signature for example.com aligns with a From address at news.example.com; in strict mode it does not. A message satisfies DMARC if either an aligned SPF result or an aligned DKIM result passes, so one aligned pass is enough, though having both is safer.

• DKIM alignment compares the signing domain (d=) with the From domain.
• SPF alignment compares the envelope sender domain with the From domain.
• A signature for the provider's own domain passes DKIM but does not align with yours.

Common reasons the result is wrong

The commonest causes are mundane. The app sends from a domain or subdomain that was never authenticated. A DNS host appends your domain to a host name you typed in full, producing a name such as em123.example.com.example.com that fails. Records were added minutes ago and verification, which the documentation says can take up to 48 hours, has not finished. A custom return-path CNAME overwrote an existing record with the same host. Or an existing DMARC record already sits on the domain and nobody has read it.

• Look up each record publicly rather than trusting the dashboard alone.
• Check the From address against the authenticated domain character by character.
• Read the existing DMARC record before anything is added.

A safe first investigation

Send one message from the app to a mailbox you control, open the full original headers and find the authentication results. Note the domain next to the DKIM result, the domain next to the SPF result and the DMARC result, then compare each with the From domain. This needs no API key, no DNS login and no customer data. If the DKIM domain is the provider's own, your domain is not aligned for this sender. If everything aligns but junk filing continues, the cause is reputation or content, which authentication cannot fix.

• Do the check at both Gmail and Outlook.com if you can.
• Record the date and time; DNS changes take time to spread.
• Change nothing in DNS until the existing records are written down.

What fixes it and what does not

The fix is to add the records the dashboard lists, wait for verification, send from the authenticated domain and re-read the headers. It does not fix a domain where several different services send as you, which is a domain-wide review, and it does not promise inbox placement. Changing a DMARC policy from monitoring to enforcement is a business decision with consequences for every sender on the domain and should be made deliberately.

How the paid outcome is accepted

The SendGrid outcome for up to three app message types is accepted when public DNS shows the agreed records, a test message of each type shows a DKIM pass on a domain that matches the From address at Gmail and Outlook.com, and a deliberately bad recipient produces exactly one stored bounce record. The fixed £395 price is an untested test price and payment follows sign-off. Send the sending domain name and the app stack, never keys or DNS logins.