.png)
Set up SPF and DKIM in your DNS to prove Palisade is authorized to send mail for your domain and to pass DMARC alignment checks. These two records are required to improve deliverability, reduce spoofing, and give receiving servers the cryptographic proof they need that messages came from you.
SPF and DKIM are email authentication standards that tell receiving mail servers which senders are permitted and verify message integrity. SPF lists the servers allowed to send for your domain; DKIM adds a cryptographic signature that proves the message wasn’t altered. Together they make your messages harder to spoof and increase the chance inbox providers accept your mail. They are essential for passing DMARC checks and for improving deliverability. Implementing both reduces phishing risk and protects your brand.
Add a single TXT record to your DNS that includes Palisade’s sending mechanism. The record should combine any IPs and third-party services you use with an include for Palisade; for example: v=spf1 ip4:
No — a domain must only have a single SPF TXT record; multiple records cause SPF to fail with a permerror. If you send through several senders, merge them into one statement using include: and ip4: mechanisms. Keep the overall DNS lookup count under limits by using includes sparingly. If you hit lookup limits, use subrecords managed by your DNS provider or flattening services. After you publish, test to ensure no permerror is shown.
Start by listing every mail source: your servers’ IPs, any ESPs, and Palisade’s sending include. Combine them into a single v=spf1 record with ip4: and include: mechanisms and a final policy like ~all or -all. Use Palisade’s SPF tool to build and validate the record: https://www.palisade.email/tools/spf. Publish the TXT at your DNS provider and confirm there’s only one SPF TXT entry for the domain. Monitor delivery and adjust as you add or remove senders.
Create DKIM keys in your Palisade account and publish the public key(s) as DNS TXT records for the selectors provided. In Palisade’s admin settings, request or generate the DKIM selector and public key — you’ll get a host name like selector._domainkey.yourdomain and a long TXT value. Add each selector record at your DNS host exactly as given, save, and wait for propagation. Once Palisade detects the DNS entries, the DKIM status should show as verified. Use Palisade’s DKIM diagnostic page to confirm the signature and key: https://www.palisade.email/tools/dkim.
DKIM uses TXT records under the selector subdomain: selector._domainkey.yourdomain. The selector name is provided by Palisade and the TXT value contains the public key. Each outgoing signing domain can have multiple selectors for key rotation or different services. Ensure you paste the key exactly and keep the TTL reasonable for propagation. After publishing, verify the selector resolves and the key matches what Palisade expects.
DNS changes usually propagate within a few minutes to a few hours, but allow up to 72 hours in worst-case scenarios. Factors include your DNS provider’s TTL, intermediate caches, and receiver mail servers’ caching behavior. Lowering TTL before a planned change can speed up propagation, then raise it after things stabilize. Use DNS lookup tools to confirm the records are visible globally. Only after propagation will verification tools consistently report success.
SPF and DKIM are the signals DMARC uses to verify messages and enforce your policy. DMARC requires that at least one of SPF or DKIM aligns with the From: domain to pass; properly configured SPF and DKIM increase the chance of DMARC alignment. Publish a DMARC policy to monitor and then enforce once authentication is reliable. If you need a DMARC check, use Palisade’s email security score tool: https://www.palisade.email/tools/email-security-score. Remember, a domain may only have one DMARC TXT record.
First, verify the exact TXT values at your DNS host for typos or extra quotes. Check that you have only one SPF TXT record and that your DKIM selector is correct. Use Palisade’s validation tools to run a live test and identify mismatches: Palisade. If you use multiple services, confirm each is included in your SPF and that signing domains match your From: address for DMARC alignment. If problems persist, rotate DKIM keys and re-publish or consult Palisade support.
Rotate DKIM keys periodically — every 6–12 months is common — or immediately after a suspected compromise. Add a new selector and publish the new public key before removing the old one to avoid delivery gaps. Test the new selector thoroughly and confirm Palisade recognizes the key. Keep a record of active selectors so you can revoke old keys cleanly. Regular rotation strengthens security and limits the exposure window if a key is leaked.
A: You can, but -all enforces strict failure and may reject legitimate mail if not all senders are included. Start with ~all (softfail) while you validate sources, then move to -all once confident. Monitor logs to spot legitimate senders you missed. Update the SPF record and re-test. A staged approach avoids delivery disruptions.
A: Yes — selectors identify the key used for signing and should be unique when multiple services sign mail for the same domain. Use clear naming (e.g., palisade1, marketing1) to manage them. That makes rotation and troubleshooting easier. Remove obsolete selectors when they’re no longer in use. Keep documentation for audit trails.
A: If done carefully — publishing new records before removing old ones — changes should not interrupt delivery. Stagger updates and lower TTLs to reduce propagation time. Validate each change with Palisade’s checkers before decommissioning previous records. If you remove a required record early, expect delivery issues until it’s restored. Plan maintenance windows for major changes.
A: Keep only one DMARC TXT record; if you already have one, update it rather than adding another. Ensure SPF and DKIM are aligned with your From: domain so DMARC reports and policies work properly. Use Palisade’s email security score to review your current setup: https://www.palisade.email/tools/email-security-score. Transition policies from none to quarantine or reject gradually while monitoring reports.
A: If tests continue to fail, contact Palisade support or your DNS provider’s support team for help. Provide exact DNS records, screenshots of the Palisade admin pages, and sample message headers for diagnosis. Palisade can validate keys and lookup records from their side. Escalate to your infrastructure team if IPs or MX records need adjustment. Proper logs and tests speed resolution.
Need hands-on checks? Validate your SPF and DKIM now with Palisade tools:
.svg)
