AutoSPF’s Guide to Configuring SPF & DKIM for Avanan: A Detailed Walk-through

As AutoSPF, my mission is simple: to help you lock down your email infrastructure so your domain only sends legitimate mail, and to make spam, impersonation, and spoofing attacks nearly impossible. In this guide, I’ll walk you through — step by step — how to configure your domain for use with Avanan, using the powerful email-authentication standards Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). By the end, your domain will be able to send mail via Avanan while passing authentication checks and aligning with DMARC — maximizing your deliverability and minimizing risk.

Why SPF and DKIM Matter (And Where Avanan Fits In)

Before diving into records and DNS consoles, it’s worth understanding why SPF and DKIM are critical — and how Avanan interacts with them.

• SPF (Sender Policy Framework) defines which mail servers are authorized to send mail on behalf of your domain. In essence, you publish in DNS a list of allowed senders. When someone receives an email from your domain, their mail server checks the SPF record to see if the sending server is listed. If not — blocked. 
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email, enabling recipients to verify the message truly came from your domain and hasn’t been tampered with. The public key is stored in DNS; the sending server uses a private key to sign messages. 
• Combined with DMARC — which adds a policy layer and alignment checks — SPF + DKIM + DMARC form the modern standard for email authentication. This matters for deliverability, reputation, and preventing phishing/spoofing attacks.
  

Now, what does Avanan do in this context? Avanan is a comprehensive email security gateway — a “security layer” placed in your sending or receiving path to detect spam, malware, harmful attachments, threats, and more. 

When configured properly, Avanan can act without breaking your SPF or DKIM setup — meaning mail still authenticates correctly, passes DMARC alignment, and reaches recipients without being flagged. 

In short: SPF and DKIM ensure your domain is trusted; Avanan ensures the content you send is safe. Together — maximum security + maximum deliverability.

Step-by-Step: Configuring SPF for Avanan

If you want Avanan to handle outgoing mail for your domain, the following SPF setup is required.

1. Log in to your DNS Zone provider
   
   • Use the control panel of wherever your DNS is hosted (e.g. Cloudflare, GoDaddy, AWS Route 53, etc.)
     
2. Create (or update) a TXT record
   
   • For the DNS name, use @ (or your root domain name) depending on your provider’s notation.
     

For the value, use:

v=spf1 include:spfa.cpmails.com ~all

• Save the record.
  

3. Wait for DNS propagation
   
   • Changes may take up to 72 hours to propagate globally.
     
4. Important — only one SPF TXT record per domain
   
   • If you already have an SPF record (because you use other mailing services, IP-based sending, or third-party tools), you must not create a second SPF record. Multiple SPF records will cause SPF to fail with a “PermError”.
     

Instead, merge entries: e.g.

v=spf1 ip4:18.57.156.221 include:spfa.cpmails.com include:thirdpartyservice.com ~all

•  This way, all your valid senders (IPs, ESPs, third-party) are covered under one unified SPF record.
  

Why this matters: when you include Avanan via include:spfa.cpmails.com, you are telling recipient mail servers that mail sent through Avanan’s infrastructure is authorized — so SPF passes even though Avanan routes/inspects the mail. 

Special case — if you use Microsoft 365:

• If you enable certain features (e.g. “Protect (Inline) Outgoing Traffic” in policies like DLP or Threat Detection), Avanan may get inserted into the mail delivery chain (internal → Microsoft 365 → Avanan → Microsoft 365 → external recipient). 
• In such a scenario, due to the double-hop, recipient mail servers may see Avanan’s IP as the sending IP. Including Avanan in SPF ensures these messages still pass SPF checks.
  

Step-by-Step: Configuring DKIM (with Avanan in Mind)

DKIM setup with Avanan is a bit different — because Avanan itself does not generate DKIM signatures for you. Instead, DKIM is handled by your email provider (for example Microsoft 365, Google Workspace, etc.). Avanan respects that existing DKIM configuration and will scan the mail after it’s been signed. 

Here’s what you need to do:

1. Enable DKIM signing in your email provider
   
   • If you’re using Microsoft 365 or Google Workspace, enable DKIM signing via their admin settings.
   • When you enable DKIM, your provider will give you a selector and one or more DNS records (typically CNAME or TXT) to publish.

2. Publish the DKIM public key in DNS
   
   • For example, if the selector is selector1, you might create a DNS record at selector1._domainkey.yourdomain.com, with the value provided by your email provider (public key). This record allows recipients (or email gateways) to verify the DKIM signature. This is standard DKIM setup.
     
3. Confirm DKIM is functioning
   
   • Send a test email and verify that the DKIM-signature header appears and passes. Many email-security tools or online checkers can help you confirm.
   • Once DKIM signing is active and DNS is propagated, Avanan — in its capacity as an email-security gateway — will inspect inbound or outbound mail but will not interfere with the DKIM signature itself. Thus your DKIM integrity remains intact.
     

Important note (from Avanan’s documentation): Avanan does not itself act as a DKIM-signing service. So your DKIM must come from your email provider (Microsoft 365, Google Workspace, etc.). Avanan’s role is to scan mail for threats, not to manage or generate DKIM keys. 

Ensuring DMARC Alignment & Deliverability: Why This Setup Matters

With both SPF and DKIM configured correctly — and with Avanan included in SPF — you set yourself up for a clean pass through DMARC.

Here’s how they work together:

• DMARC evaluates whether the sending domain (in the email’s From: header) aligns with either the SPF-verified envelope sender or the DKIM-verified signature. If one passes and aligns, the email passes DMARC. 
• By having a single SPF record that includes Avanan, and a valid DKIM signature from your email provider, you maximize the chances of passing DMARC checks — even when Avanan is inserted into your mail flow.
• This improves deliverability (fewer emails sent to spam), preserves your domain reputation, and prevents abuse (spoofing, impersonation).
  

Additionally, because Avanan acts as a security gateway — scanning for malware, phishing, suspicious attachments or links — you add a second layer of protection: authentication (SPF/DKIM) + content security (Avanan).

Common Pitfalls & How to Avoid Them

When configuring SPF, DKIM, and Avanan together, there are a few common mistakes that can sabotage your efforts. I call these “gotchas.”

Multiple SPF Records

As noted earlier: having more than one SPF TXT record for a domain causes SPF to fail with a “PermError.” That means all mail from your domain could be blocked. To avoid: merge all authorized senders into one SPF record.

Not Including Avanan in SPF (when using Inline/Outgoing Routing)

If you route outbound mail through Avanan (especially in scenarios like Microsoft 365 + Inline Outgoing Traffic), but forget to include Avanan in SPF — mail will appear to come from Avanan’s IP and may fail SPF, or be flagged as suspicious.

Relying on Avanan for DKIM Signing

Remember: Avanan does not sign mail with DKIM on your behalf. DKIM must be set up by your email provider (Microsoft 365, Google Workspace, etc.). If you skip that step, DKIM will be absent or invalid — hurting deliverability and trust.

DNS Propagation Delays

After publishing new SPF or DKIM records, DNS changes might take up to 72 hours (or more, depending on TTL settings) to propagate. During that window, some recipients might not be able to verify the records properly — leading to temporary failures. It’s wise to wait at least 24–48 hours before sending bulk mail or expecting consistent behavior.

Not Testing Before Going Live

Always send test emails (to different external mail services) to verify:

• SPF passes (check “Received-SPF” header)
• DKIM signature is present and valid
• DMARC passes (if you have a DMARC policy enabled)
  

Only after positive confirmation should you consider your setup “live.”

Recommended Deployment Options with Avanan

Depending on how you use Avanan — and what your mail ecosystem looks like — you can choose different deployment models. Each has trade-offs.

✅ API-Based Integration (Preferred, If Available)

• With API integration (available for Microsoft 365 or Google Workspace), emails are sent directly by your original mail server. SPF and DKIM remain untouched. Avanan watches mail after it’s sent (via API), scanning for threats before delivery. 
• Pros: No need to change MX or routing records; minimal risk of breaking authentication; sender reputation and deliverability stay intact.
• Cons: Some advanced outbound security features (like full inline scanning before send) may not be available; less control over mail routing compared to inline.
  

🔄 Inline Gateway Integration (MX-Based)

• In this model, you route outbound mail through Avanan by updating your MX records (or mail routing) — so all outbound traffic passes through Avanan’s gateway. 
• Pros: Full control — threat detection, DLP, inline encryption, policy enforcement; consistent security for both inbound and outbound mail.
• Cons: More risk of authentication issues (especially if SPF/DKIM not configured correctly), complexity in setup, and possible latency.
  

If using inline routing or outbound traffic protection with Microsoft 365, make sure to include Avanan in SPF (as shown above) — otherwise authentication failures will be common.

After Setup: Monitoring, Verification & Ongoing Maintenance

Once your SPF and DKIM are configured and live, and Avanan is integrated — there are a few ongoing practices to keep your email hygiene high.

• Monitor DMARC reports (if you have a DMARC policy with reporting enabled). This helps you see how many emails pass/fail SPF, DKIM, alignment; from which sources; whether any misconfigured third-party senders exist. DMARC is powerful when used alongside SPF + DKIM. 
• Use a DKIM management tool if your provider supports it. For example, Avanan’s “DKIM Management” feature allows administration of selectors and monitors DKIM signing status for multiple domains — helpful if you manage several domains/subdomains. 
• Periodically audit your SPF record — if you start using new third-party services (email marketing tools, CRM, notification systems), make sure to include them in the SPF record (don’t add a new record). Consolidate all senders in a single record.
• Test after major changes — whether you rotate IPs, change mailing platforms, or update DNS providers, send test emails to external accounts to confirm SPF, DKIM, and DMARC still pass.
• Beware of mail forwarding or mailing lists — these can break SPF or DKIM (or alignment) and thus cause DMARC failures. Understand how forwarded mail or mailing-list software interacts with your authentication setup.
  

TL;DR — The AutoSPF Checklist for Avanan

Here’s a quick reference summary of what you need to do if you’re using Avanan and want to ensure proper SPF, DKIM, and DMARC compliance:

• Use a single SPF TXT record per domain.
• If routing mail through Avanan — include include:spfa.cpmails.com in that SPF record.
• If using other sending sources / IPs / third-party services — merge all under the same SPF record.
• Enable DKIM signing at your email provider (Microsoft 365 / Google Workspace / etc.), and publish the public key via DNS.
• Wait for DNS propagation before heavy email usage (up to 72 hours).
• Send test emails to confirm SPF, DKIM, and DMARC pass.
• Use DMARC reporting + DKIM-management (if available) to monitor continued compliance. 
• Audit SPF/DKIM whenever you add new sending services or change infrastructure.