How to Properly Configure SPF & DKIM for Your ESP — A Guide by AutoSPF

In today’s world, email remains the backbone of communication for businesses — marketing announcements, customer notifications, transactional receipts, transactional alerts, newsletters, and more. But with rising concerns around phishing, spoofing, and brand impersonation, it’s no longer good enough to simply send email from your domain and hope they land safely in your recipients’ inboxes.

That’s where email authentication protocols come in. By properly implementing authentication mechanisms such as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), and optionally layering on DMARC, you dramatically improve your deliverability, protect your brand reputation, and make it far harder for attackers to spoof your domain.

As AutoSPF — a service dedicated to simplifying SPF/DKIM setup — this guide walks you through why SPF and DKIM matter, how to configure them for your ESP setup, and what best practices to follow.

Why SPF & DKIM (and DMARC) matter

The problems: spoofing, phishing, and deliverability woes

• Without SPF or DKIM, any malicious actor can send email that appears to originate from your domain — tricking recipients into believing the emails are legitimate. This can lead to phishing, fraud, or brand damage.
• Emails from “unknown” or “unauthenticated” sources are often filtered into spam or rejected altogether by modern mail providers.
• Even well-intentioned senders — marketing platforms, newsletters, transactional systems — run the risk of ending up in spam or junk folders if authentication isn’t set up properly.
  

What SPF, DKIM, and DMARC do (in brief)

• SPF lets you publish a list of mail servers (IP addresses or hostnames) that are authorized to send email on behalf of your domain. When a receiving mail server gets a message, it checks whether the sending server is in that list. 
• DKIM attaches a cryptographic signature to each outgoing message. That way, the recipient can verify that the message indeed comes from your domain and — importantly — hasn’t been altered in transit.
  
• DMARC ties SPF and DKIM together with a policy: it tells receiving servers what to do if an email fails authentication (e.g. reject, quarantine, or just report). DMARC also enables reporting — so domain owners get feedback about who is sending mail on their behalf.
  

Used together, these protocols dramatically raise the bar for email security and deliverability. 

Planning your SPF & DKIM setup for an ESP

Before you touch your DNS or server settings — planning matters. Especially if you’re running or working with an Email Service Provider (ESP) or multiple senders (e.g. marketing, support, transactional systems).

Here’s what you should do first:

1. List all sources that send email on your domain’s behalf
   — This includes internal servers, marketing tools, CRM systems, support tools, third-party email platforms, etc. Every server or service that sends mail needs to be considered.
2. Decide on centralization vs. multiple senders
   — If all email goes through your ESP, configuration is simpler. If you have multiple services sending directly, you’ll need to account for all of them in SPF (and possibly DKIM) records.
3. Ensure you control your DNS
   — To set SPF and DKIM, you’ll need access to your domain’s DNS (or the DNS console of your registrar/hosting provider). Without that, you cannot publish the required TXT or CNAME records.
   
4. Generate DKIM keys (if needed)
   — If your ESP or mail server supports DKIM, generate a DKIM key-pair (public and private key). The public key goes into your DNS, private key stays on the sending server.
   
5. Plan for DMARC (optional but recommended)
   — Once SPF and DKIM are in place and you’re confident about all legitimate senders, you should plan a DMARC record to monitor — and later enforce — your domain’s email authentication policy.
   

Step-by-Step: Configuring SPF for your ESP

Here’s how to set up SPF:

1. Log in to your DNS provider’s dashboard (or the admin console of your domain registrar).
2. Navigate to the DNS management page — where you can add or edit.
3. Create or update the SPF record:
   
   • Record type: TXT
   • Host/Name: typically @ (or your root domain)
     

Value: starts with v=spf1, followed by mechanisms listing your authorized senders (e.g. include:, ip4:, ip6:), ending with an “all” mechanism. For example:

v=spf1 include:mail.esp-provider.com ip4:203.0.113.5 -all

• The ending -all (or ~all) tells receiving servers to reject (or “soft-fail”) mails not coming from the listed senders.
  

4. If you already have an SPF record, do not create a second one. SPF allows only a single record per domain. Instead, merge your existing record with new entries for your ESP or additional senders. 
5. Save the DNS record. Wait for propagation (DNS caching may take anywhere from minutes to a few hours, sometimes up to 48 hours) before testing. Many DNS providers have a default TTL (Time to Live) — but you can often leave it as default. 
6. Send a test email from your domain (through the ESP) to a mailbox (e.g. Gmail, Outlook) and check headers for spf=pass to verify that SPF is working.
   

That covers SPF. But SPF alone is not enough — especially for organizations sending lots of mail or concerned with security. That’s where DKIM comes in.

Step-by-Step: Configuring DKIM for your ESP

DKIM setup is slightly more involved since it involves cryptographic keys — but it’s worth it. Here’s how to do it:

1. On your ESP (or mail server), generate a DKIM key-pair (public + private). Many ESPs or mail-server platforms offer built-in DKIM key generators. If using a managed service (e.g. cloud-based email, hosted workspace), the service may generate keys for you.
   
2. Once generated:
   
   • Private key stays secure on your sending server — used to sign outgoing emails.
   • Public key needs to go into your domain’s DNS. How exactly depends on the instructions from the ESP, but typically:
     
     • Record type: TXT (some providers may use CNAME, depending on how they delegate DKIM) 
     • Name/Host: usually something like selector._domainkey — “selector” is a string chosen during key generation (e.g. mail, esp1, etc.). Example: esp1._domainkey.example.com. 
     • Value: the public key data supplied by the ESP (a long string).
       
3. Save the DNS record and wait for DNS propagation.
4. Enable DKIM signing on the ESP / sending server. Many ESP dashboards have a toggle or “Enable DKIM” option once the DNS record is in place.
5. Send a test email. Then check mail headers (or use an external mail-verification tool) to confirm that the DKIM signature is present and passes verification (dkim=pass).
   

Once both SPF and DKIM are configured and passing, your domain’s emails are much more likely to be trusted by recipient mail providers.

Optionally: Adding DMARC for Policy & Reporting

After you have SPF and DKIM correctly configured, you should strongly consider adding a DMARC record. DMARC lets you define a policy — what to do when messages fail: log them, quarantine, or reject. It also enables reporting. That means you (or your security / IT team) get feedback about which emails passed or failed, from which IPs, helping you spot unauthorized senders or misconfigurations. 

Here’s how to add a basic DMARC record:

• DNS Record Type: TXT
• Host/Name: _dmarc (for example _dmarc.example.com)
  

Value: something like:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; pct=100;

• p=none means “monitor only, don’t reject yet.” Good as a first step for observing traffic.
• rua is where aggregate DMARC reports will be sent (choose an inbox or reporting address you monitor).
• Once you’re confident legitimate email is passing SPF or DKIM (and aligned), you can move to stricter policies like p=quarantine or p=reject.
  

DMARC helps enforce that only properly authenticated emails are accepted — strengthening your domain’s security posture and significantly lowering chances of phishing or domain spoofing.

Common Pitfalls & How to Avoid Them

Even with the best intentions, misconfigurations happen. Here are some common mistakes — and how to avoid them.

• Multiple SPF records for the same domain — this causes SPF validation failures. Always maintain only one SPF record per domain. Merge entries if needed.
• Using weak/misleading SPF items (e.g. +all) — this lets any server send email for your domain, defeating the purpose of SPF entirely. Avoid +all. Use -all or ~all only after listing authorized senders. 
• Forgetting to list all legitimate senders — if you add a new email source (another ESP, marketing tool, CRM), don’t forget to update your SPF (and if needed, DKIM) setup. Otherwise, mail from those sources may be rejected.
• Not waiting for DNS propagation or TTL refresh — changes in DNS can take time to propagate globally. After updating SPF/DKIM, wait and confirm with test emails before assuming setup is complete.
• Jumping to strict DMARC policy too soon — if you set p=reject while legitimate sources are still misconfigured, you risk blocking valid email. Always start with p=none, monitor reports, fix issues, then gradually move to stricter enforcement.

Why Using AutoSPF (or Similar) Makes a Difference

As a tool/service dedicated to simplifying SPF (and by extension DKIM) setup, AutoSPF aims to reduce manual errors — especially for organizations with multiple senders. Here’s how:

• Automatically generate correct SPF strings, merging multiple senders without duplication.
• Clearly identify all authorized email sources, reducing risk of missing one (a common reason for failures).
• Provide validation/testing tools — before and after deployment — so you can ensure SPF (and DKIM) records work.
• Help plan and guide DMARC adoption, moving from monitoring to enforcement with minimal disruption.
  

With such automation and oversight, you minimize human error, and ensure your email infrastructure remains robust, scalable, and secure.