Add a domain you own
In your SendPanda project, open Domains and add your sending domain. You can use your root domain or a subdomain such as notifications.example.com. Copy the exact DNS names and values from its setup screen; keys and selectors are generated for your domain claim.
Publish the sending records
New sending domains use three records. Existing domains can keep their original verification records, so follow the records shown in your dashboard.
- DKIM TXT: publishes the signing public key at the generated selector. This also proves ownership of the current domain claim.
- Bounce MX: configures the MAIL FROM / return-path subdomain used for bounce handling.
- SPF TXT: authorizes sending on that MAIL FROM subdomain. Publish it at the exact name shown, which may differ from the root domain.
The sending return-path MX is separate from the MX records for your normal inbox. Do not replace your root-domain mailbox provider's MX records to set up sending. Receiving email in SendPanda is a separate setup.
Check your DNS host's name format
Some DNS hosts append the zone name automatically. If the full name is mail.example.com, the host field may need only mail. Check the resulting full name to avoid mail.example.com.example.com. Keep DNS records unproxied where your provider offers a proxy option.
For a long DKIM key, a DNS host may split one TXT record into quoted string fragments. That is different from creating multiple separate TXT records: the fragments of one record are joined for verification.
Verify in SendPanda
Save the records at your DNS host, then use Verify in the domain screen. DNS caches can take time to update. SendPanda checks the exact signing key, provider readiness and return-path configuration before enabling the domain. A temporary DNS error can be retried; it is different from a record that is definitely missing.
Add a DMARC policy
DMARC checks alignment with the visible From domain. To pass DMARC, either SPF or DKIM must pass and align. Start with monitoring to identify legitimate senders, then review reports before moving to an enforcing policy.
The DMARC checker and generator can inspect your current policy or generate a p=none record. Publish it as a TXT record at _dmarc for the relevant domain, updating any existing policy rather than adding a second one. Add a report address you control if you want aggregate reports.
Troubleshoot verification
- SPF not found: check the MAIL FROM hostname rather than assuming the root-domain record is used. Inspect it with the SPF checker.
- Duplicate SPF: use one policy at each hostname and combine authorized senders. Two separate v=spf1 policies at one name are invalid.
- DKIM mismatch: compare the full selector name and key to the current dashboard record. A previous claim's key will not verify a new claim.
- Pending DNS: check the name, type and value, wait for caches to update, then retry verification.
- DMARC failures despite SPF passing: the authenticated MAIL FROM domain may not align with the visible From domain. Inspect the message's actual authentication results; DNS publication alone cannot prove alignment.
Successful domain verification establishes sending readiness. It does not guarantee inbox placement. When your domain is ready, follow the quickstart to send your first email.