How to Set Up SPF for PodPitch

SPF (Sender Policy Framework) tells receiving mail systems which services are allowed to send email for a domain. A correct SPF record helps prevent spoofing and improves authentication, but an incorrect record can cause legitimate email to fail.

Important: Do not copy an SPF record from this article, another company, or an online example. Your record must reflect every service that actually sends email for your domain.

How SPF relates to PodPitch

PodPitch send outreach through a mailbox you connect to the applicable workspace. In PodPitch, manage it under Email Addresses. Your mailbox provider and any other services that send as your domain determine what belongs in SPF.

Do not add a generic PodPitch SPF include. If Support gives you a domain-specific DNS instruction, use that exact instruction; otherwise, configure SPF only for the services that actually send your mail.

Before you change DNS

1. Confirm the domain used by your connected email address.
2. List every legitimate sender for that domain. This may include Google Workspace or Microsoft 365, a CRM, newsletters, support tools, website forms, and transactional email services.
3. Find the current DNS host for the domain. This may be your registrar, Cloudflare, or another DNS provider.
4. Get the exact SPF requirement from each sending service's admin console or official documentation.
5. If your company has an IT team or managed DNS, ask them to make the change.

1. Check for an existing SPF record

In your DNS settings, look for a TXT record at the sending domain that begins with v=spf1.

• If one already exists, update that record.
• If none exists, create one using the exact value required by your email provider and other legitimate senders.
• Never publish two SPF records for the same domain or subdomain. Multiple SPF records cause a permanent SPF error.

2. Use only provider-supplied values

Add only the mechanisms supplied by services that genuinely send email for your domain. Do not guess an include, copy another customer's record, or construct a record from a provider name.

Your DNS provider may display the root domain as @, a blank field, or the full domain name. Follow that provider's instructions so the record is created at the correct host.

3. Keep the record valid

• SPF allows no more than 10 DNS-based lookups during evaluation. Nested include records count too.
• The record must contain only one final all mechanism.
• Never use +all; it authorizes every sender.
• Do not change ~all to -all unless your email administrator has confirmed that every legitimate sender is covered and the stricter policy is appropriate.

4. Save and allow DNS to update

DNS changes can take time to become visible. The exact delay depends on your DNS provider and the record's TTL.

Verify SPF before tightening anything else

1. Use a DNS checker to confirm there is exactly one SPF record for the domain.
2. Send a test message from the connected mailbox to an external inbox.
3. Open the message's full headers and find Authentication-Results.
4. Confirm that SPF shows pass for the expected sending domain.
5. Repeat the test for every service that sends email for your domain.

An SPF pass can reference the envelope or Return-Path domain rather than the visible From address. DMARC checks whether the authenticated domain aligns with the visible From address.

Common SPF problems

• More than one SPF record: merge authorized senders into one record.
• A sender is missing: add only that service's official mechanism to the existing record.
• Too many DNS lookups: remove unused senders or ask your email administrator/provider to simplify the record.
• Wrong host or duplicated domain name: confirm how your DNS provider formats the root host.
• Forwarded mail fails SPF: forwarding can change the sending server; DKIM and DMARC provide additional protection.

Need help?

Because SPF affects all mail sent from a domain, contact your email administrator or DNS provider if you are unsure. You can also message Support through the chat in your dashboard and share:

• your sending domain;
• your email provider;
• the services that send email for the domain; and
• the authentication result from a failed test message.

Never send passwords, app passwords, recovery codes, or private DKIM keys in support chat.

Official provider guidance

• Microsoft 365: Set up SPF
• Google Workspace: Set up SPF

Updated on: 08/09/2026