@Mail Domain Check

Resend | DKIM | strict DMARC

Resend DKIM Public Key Is Empty while DMARC Is p=reject

A TXT record such as v=DKIM1; p= is not a waiting placeholder. It revokes that selector. Verify the current Resend-generated DKIM and Return-Path records, then require one fresh message to pass aligned DKIM and DMARC.

The public scan is free. A complete prioritized report is 1 USDC on Base and is delivered automatically without an account or email address.

Decision: treat an empty p= as a revoked key

Resend sending status
Use the sending capability shown on the current domain details page. An API request returning an ID does not prove that the domain still has valid public authentication records.
DKIM public key
RFC 6376 defines an empty p= value as a revoked key. A receiver must treat a signature using that selector as a permanent verification failure.
Return-Path records
Resend uses send as the default Return-Path subdomain and supplies exact SPF TXT and MX values. Check that subdomain or the configured custom Return-Path instead of rewriting the apex SPF record.
Strict DMARC
With adkim=s or aspf=s, an authenticated identifier must exactly equal the visible From domain. A related subdomain is not enough for strict alignment.

Do not post an API key, private DKIM key, complete DNS-zone export, recipient address, full message header, legal notice, login link, provider log, or dashboard screenshot. The planner uses categorical states only. The optional scan form sends only a public domain.

Browser-local evidence planner

Find the first broken authentication boundary

No domain, address, DNS value, key, message, provider response, configuration, or log is requested or transmitted by this planner.

Why apex SPF can look intentionally closed

An apex record such as v=spf1 -all can intentionally say that no server uses that domain as the SPF identity. Resend normally authenticates a separate send.example.com Return-Path. The relevant evidence is the exact TXT and MX pair generated for that Return-Path, not whether the apex authorizes Resend.

That distinction becomes critical under strict DMARC. If the visible From is example.com and SPF authenticates send.example.com, strict aspf=s does not align those two names. A valid DKIM signature whose d= exactly matches the visible From domain must then carry the DMARC pass.

One bounded recovery

  1. Open the current Resend domain details and record only its sending status plus the exact generated DKIM owner/value and Return-Path TXT/MX owner/values. Do not copy secrets or screenshots into a public issue.
  2. Query authoritative public DNS for those exact owners. Replace an empty p= DKIM value with the current non-empty public key generated by Resend. Publish the exact Return-Path TXT and MX values at send or the configured custom label.
  3. Remove stale conflicting values at the same owner, wait for authoritative DNS to serve one current answer, then use Resend's Restart verification action. Require the sending capability to become verified.
  4. Send one fresh controlled message. In the topmost trusted Authentication-Results, require dkim=pass for the selector you just published and dmarc=pass for the visible From domain.
  5. Only after authentication passes, record Gmail, Outlook, and iCloud placement plus Resend delivery events. Authentication success is necessary evidence, not an inbox guarantee.
nslookup -type=TXT resend._domainkey.example.com
nslookup -type=TXT send.example.com
nslookup -type=MX send.example.com

Use the exact selector and custom Return-Path shown by the current dashboard when they differ from these defaults.

Do not weaken DMARC to hide an authentication failure

Changing p=reject to p=none can reduce receiver enforcement while the underlying sender remains unauthenticated. It does not repair DKIM, SPF, or alignment. For login and legally significant messages, first restore the current sender records and prove aligned authentication on a fresh message; then choose policy from aggregate evidence and a documented rollback plan.

Public field case

A public launch-readiness issue describes a Resend integration used for magic links, legal notices, and operator alerts. The current source sends from the apex domain. A public DNS observation on 24 July 2026 returned an apex v=spf1 -all, strict p=reject; adkim=s; aspf=s, an empty p= value at the common Resend selector, and no TXT or MX answer at the default send Return-Path.

Public DNS is mutable, and those observations do not prove the private Resend dashboard state or the result of a current message. They do identify the exact boundaries that must be rechecked before the project treats a provider request ID as delivery evidence.

Run the public domain, SPF, DMARC, DKIM-selector, PTR and policy checks before changing multiple records at once.

Primary sources