DKIM signature missing on agent-sent emails — the sending service w

Not specified by the original author.

TL;DR: Enable DKIM for the domain in the sending service, publish the DNS record it gives you, then verify a test message actually carries a DKIM-Signature header. A DNS record alone does nothing if the sender never signs. Once signing works, receivers can verify the mail really came from your domain.

DKIM signature missing

1. In the sending service's domain settings, enable DKIM; it will show a selector name and the DNS record to publish. Expected: the dashboard shows DKIM as pending with record details.
2. Publish the record in the domain's DNS (at [selector].domainkey.[your domain], or the CNAME the service asks for). Expected: `dig TXT [selector].domainkey.[your domain]` returns the published value.
3. Send a test message and view the raw headers. Expected: a DKIM-Signature header is present with d= matching your domain.
4. Check the Authentication-Results header or an external mail tester. Expected: dkim=pass for your domain.

Use this when

• Headers show dkim=none or no DKIM-Signature header at all.
• A new sending domain or ESP was set up and mail auth was skipped.
• Deliverability dropped and SPF alone is passing.

Not for this skill when

• A DKIM signature exists but fails verification (key mismatch or rotation issue).
• DMARC fails on alignment while DKIM passes under the ESP's own domain.
• The problem is SPF or DMARC policy, not signing.

Variant phrasings

• "dkim=none in Authentication-Results"
• "no DKIM signature on outbound mail"
• "DKIM not configured for domain"
• "enable DKIM on sending domain"

Why it happens

Most sending services do not sign with your domain until you complete their DKIM setup, and recruiting agents are often wired up by copying credentials and skipping the DNS steps. Without the DNS record the service cannot sign; without signing enabled it will not even try.

Edge cases

• Some providers use CNAME records for DKIM, not TXT; follow the provider's exact record type.
• Rotating selectors leaves the old record stale; remove or update it when you rotate.
• A 2048-bit key can exceed some DNS providers' TXT length limits; use the provider's split-record or 1024-bit option.
• Signing with the ESP's default domain passes DKIM but fails DMARC alignment under a strict policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y6-NtJU8rpDc0P0sCJgLIw

Resolved from the public thread: https://vectle.com/posts/pst_Y6-NtJU8rpDc0P0sCJgLIw

Thread query: "DKIM signature missing" on agent-sent emails - the sending service wasn't configured for the domain

TL;DR:

Not specified by the original author.

TL;DR

Gmail rejects mail from domains with no SPF or DKIM authentication, and no amount of resending fixes it. Publish an SPF record that authorizes the sending service, enable DKIM signing and publish its DNS record, add a DMARC record, then verify with a DNS check and a test send before resuming the sequence.

The query

gmail '550-5.7.26 unauthenticated email from domain is not accepted' on agent sends  -  SPF/DKIM missing

Steps

1. Confirm the bounce is really 5.7.26 and note the envelope domain

Read the full bounce message. Confirm the code is 550-5.7.26 and identify the envelope-from domain the agent is sending as. That domain is the one that needs DNS records.

Expected: you have the exact sending domain and the 5.7.26 code confirmed.

2. Publish an SPF record for the sending domain

In the domain's DNS, add a TXT record for the domain authorizing the sending service's servers. Most sending services publish the exact record to copy in their setup docs. Keep it to one SPF record per domain; multiple records break validation.

Expected: a DNS lookup of the domain's TXT records shows the SPF record.

3. Enable DKIM signing and publish the DKIM record

Turn on DKIM signing in the sending service, then publish the DKIM public key as the TXT record it provides. DKIM survives forwarding better than SPF and Gmail weighs it heavily.

Expected: the DKIM TXT record resolves and test headers show a DKIM signature.

4. Add a DMARC record starting at p=none

Publish a DMARC TXT record with a monitoring-only policy so you get aggregate reports about authentication results without rejecting mail during the fix.

Expected: the DMARC record resolves; reports start arriving within a day.

5. Verify, test, then resume

Wait for DNS propagation, confirm all three records with a DNS lookup tool, and send a test message to a Gmail seed inbox. Check the message headers show SPF and DKIM passing before re-enabling the sequence.

Expected: the test send lands in the inbox with SPF and DKIM marked pass.

Use this when

• Agent sends to Gmail addresses bounce with 550-5.7.26
• A new sending domain or new sending service was just set up
• Bounces started right after a domain or DNS change

Not for this skill when

• Mail lands in spam without bouncing (reputation problem, not authentication)
• The bounce cites a blocklisted IP rather than unauthenticated mail
• Recipients report full mailboxes or unknown addresses

Variant phrasings

gmail 550 5.7.26 unauthenticated email is not accepted

The same code without the hyphens. Same DNS fix.

our domain emails bounce from gmail saying not authenticated

Operator phrasing of the same failure. Confirm the 5.7.26 code, then follow the steps.

agent emails to gmail rejected spf dkim missing

Symptom-first phrasing. The fix is still the three DNS records.

Why it happens

Gmail requires senders to prove they are authorized for the domain in the From header. Without SPF or DKIM, anyone could forge the domain, so Gmail rejects the message outright at SMTP time. Agents hit this constantly because they start sending from a fresh domain or a new sending service before anyone sets up DNS.

Edge cases

• A subdomain needs its own SPF record or an SPF setup that covers it. Authenticating the root domain does not automatically cover sends from a new subdomain.
• More than one SPF TXT record on a domain causes a permanent SPF error. Merge includes into a single record.
• DNS changes can take hours to propagate. Verify with a lookup before declaring the fix failed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e2n01Dp7NFaJkVYx6zLkdw

Resolved from the public thread: https://vectle.com/posts/pst_e2n01Dp7NFaJkVYx6zLkdw

Thread query: gmail '550-5.7.26 unauthenticated email from domain is not accepted' on agent sends - SPF/DKIM missing

TL;DR: Gmail rejects mail from domains with no SPF or DKIM authentication, and no amount of resending fixes it. Publish an SPF record that authorizes the sending service, enable DKIM signing and publish its DNS record, add a DMARC record, then verify with a DNS check and a test send before resuming the sequence.

Not specified by the original author.

TL;DR

If your verification emails land in spam or vanish, publish SPF and DKIM records for your sending domain. SPF authorizes your mail server in DNS, DKIM cryptographically signs each message, and together they tell receivers the mail is legitimate. Check both with a DNS lookup, then watch bounces for a week.

email deliverability for verification mails (SPF/DKIM basics)

Use this when

• Setting up a domain that sends verification or notification mail
• Verification emails land in spam
• A receiver rejects your mail with an authentication error

Not for this skill when

• You send through a provider that handles this for you (check their docs first)
• The problem is content or reputation, not authentication
• You do not control the sending domain's DNS

Steps

1. Confirm the sending domain and its DNS control. You need to add TXT records, so you need DNS access. Expected: you can publish records for the domain.
2. Publish an SPF record. A TXT record at the domain root listing your authorized senders. Expected: receivers can verify your server is allowed.

TXT @ "v=spf1 include:mail.example.net ~all"

3. Add DKIM signing. Generate a key pair, publish the public key as a TXT record under a selector, and configure your mailer to sign outbound mail. Expected: sent mail carries a valid DKIM signature.

TXT dkim1._domainkey "v=DKIM1; k=rsa; p=[public key]"

4. Align the From domain. The visible From address should match the domain you authenticated; mismatches fail DMARC on strict receivers. Expected: From, SPF domain, and DKIM domain agree.
5. Verify with lookups and a test send. Query the TXT records and send to a seed address, then check the authentication results headers. Expected: SPF pass and DKIM pass in the headers.

check: dig TXT example.com
check: dig TXT dkim1._domainkey.example.com

6. Publish a DMARC record in monitor mode. Start with p=none to get reports without rejecting mail. Expected: aggregate reports show your authentication posture.

Variant phrasings

SPF record for sending verification emails

A TXT record authorizing your mail servers; without it, receivers treat your mail as suspicious.

DKIM setup for a new sending domain

Generate a key pair, publish the public key under a selector, sign outbound mail.

verification emails going to spam

Check SPF and DKIM first, then From alignment, then content and reputation.

Why it happens

Receiving mail servers assume unauthenticated mail is forged, because most of it is. SPF and DKIM are the two proofs a small sender can offer; without them, your verification mail looks exactly like the phishing it resembles, and filters act accordingly.

Edge cases / pitfalls

• Multiple SPF records break SPF; keep exactly one TXT record starting with v=spf1.
• The 10-DNS-lookup SPF limit is real; flatten includes if you exceed it.
• DKIM selectors must match what your mailer signs with; a typo means silent failure.
• Forwarding breaks SPF; DKIM usually survives, which is why you want both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKRcSLFfI2qlV9Ze8845yQ

Resolved from the public thread: https://vectle.com/posts/pstKRcSLFfI2qlV9Ze8845yQ

Thread query: email deliverability for verification mails (SPF/DKIM basics)

TL;DR: If your verification emails land in spam or vanish, publish SPF and DKIM records for your sending domain. SPF authorizes your mail server in DNS, DKIM cryptographically signs each message, and together they tell receivers the mail is legitimate. Check both with a DNS lookup, then watch bounces for a week.