SPF Configuration: What Access Developers Need to Know for Reliable Email Delivery

The perfect VBA email code means nothing if your client's SPF records don't authorize your sending service to deliver those messages.

For years, Access developers could focus solely on writing good automation code, letting Outlook handle all the complex email authentication behind the scenes. But as we transition to services like Mailgun to replace Outlook automation, the technical responsibility extends beyond VBA.

In our previous articles, we explored how email infrastructure works, the security protocols that authenticate messages, and how these concepts apply to Access developers. Now it's time to dive deep into implementing your first authentication protocol: SPF.

What Is SPF and Why It's Your Critical First Step

SPF stands for Sender Policy Framework.

It's a simple DNS record that specifies which servers are authorized to send email on behalf of your domain. Think of it as the guest list for your domain's email servers—if a server isn't on the list, it shouldn't be sending mail claiming to be from your domain.

SPF is considered the critical first step in email authentication for several reasons:

• It's the most widely implemented authentication protocol
• It's checked first in the authentication sequence by most receiving mail servers
• It directly addresses the most common form of email spoofing
• It's relatively straightforward to implement (though with important caveats)

Without SPF, anyone can send email claiming to be from your domain. This isn't just a security risk—it's increasingly becoming a deliverability problem as major email providers like Gmail and Microsoft tighten their filtering algorithms.

For Access developers transitioning away from Outlook automation, implementing SPF is non-negotiable if you want your programmatically sent emails to reach their destination.

When SPF Updates Are Necessary (and When They're Not)

It's important to understand that updating SPF records is only necessary when you're introducing a new SMTP delivery service for your (or your client's) domain.

Existing Email Infrastructure

If your client already uses Microsoft 365 as their email platform and you're transitioning from Outlook automation to the Microsoft Graph API, you likely won't need to modify their SPF records. Microsoft 365 domains typically already have the necessary SPF entries:

v=spf1 include:spf.protection.outlook.com -all

This existing record already authorizes Microsoft's servers to send email on behalf of the domain, so Graph API-based sending would be covered under this authorization.

New Sending Services Require SPF Updates

However, if you're introducing a third-party sending service like Mailgun, SendGrid, or Amazon SES, you will need to update the domain's SPF records to include these new sending sources:

v=spf1 include:spf.protection.outlook.com include:mailgun.org -all

Balancing Complexity

While navigating the complex security and authentication requirements of Graph API presents its own set of challenges (OAuth authentication, permission scopes, token management), a one-time configuration of SPF records for a service like Mailgun is often a worthwhile tradeoff for significantly simpler email sending automation.

Microsoft Graph API with Maria Barnes

Working with the Microsoft Graph API from VBA: Preparing for the New Outlook (an Access User Group talk with Maria Barnes).

No Longer SetMike Wolfe

Consider these factors when deciding between Graph API and a dedicated email service:

1. Development complexity: Graph API requires OAuth authentication and token management
2. Maintenance overhead: Graph API tokens expire and need renewal logic
3. Rate limiting: Microsoft imposes stricter rate limits on Graph API than dedicated email services
4. Feature set: Dedicated email services often provide more detailed delivery analytics

For many Access developers, the one-time DNS configuration required by Mailgun is a small price to pay for the ongoing simplicity it provides in your VBA code.

The Technical Fundamentals of SPF Records

An SPF record is a specific type of DNS TXT record that follows a standardized format. Here's what a basic SPF record looks like:

v=spf1 ip4:192.168.1.1 -all

The components include:

• v=spf1: Indicates the SPF version
• ip4:192.168.1.1: Authorizes this IPv4 address to send mail
• -all: Tells receiving servers to reject mail from all other sources

SPF records always start with v=spf1 and end with some form of the all mechanism. In between, you list the servers authorized to send email on behalf of your domain.

An important technical detail: a domain can only have one SPF record. If you publish multiple TXT records containing v=spf1, receiving mail servers will either use the first one they find or consider your SPF configuration invalid.

SPF Mechanisms and Qualifiers: The Building Blocks

SPF records consist of mechanisms and qualifiers that work together to define your email sending policy.

Mechanisms: Defining Who Can Send

Mechanisms specify which servers are authorized to send email. The most common include ip4, ip6, a (domain A records), mx (mail exchangers), and include (other domains' SPF records).

While direct IP authorization offers more precision, Access developers working with email service providers will typically use the include mechanism:

v=spf1 include:mailgun.org -all

This approach delegates the maintenance of sending IPs to your provider, who can update their SPF record as their infrastructure changes.

Qualifiers: Defining the Policy

Each mechanism can have a qualifier that specifies what should happen if the mechanism matches. There are four possible qualifiers:

• + (Pass): The server is authorized to send (default if no qualifier is specified)
• - (Fail): The server is not authorized, and messages should be rejected
• ~ (SoftFail): The server is not authorized, but messages should be accepted with caution
• ? (Neutral): No policy statement, neither authorized nor unauthorized

For example:

v=spf1 +ip4:192.168.1.1 -ip4:192.168.2.1 ~all

This record authorizes 192.168.1.1, explicitly denies 192.168.2.1, and suggests caution for all other servers.

The 10-DNS Lookup Limit

One of the most important technical limitations of SPF is the 10 DNS lookup limit.

When a receiving mail server evaluates your SPF record, it's allowed to perform a maximum of 10 DNS lookups. If your record requires more than 10 lookups, the evaluation fails, and your authentication may be considered invalid.

These lookups include each include mechanism, each a mechanism, each mx mechanism, and any redirects. This limit is particularly relevant when using services like Mailgun alongside other email services, as each include statement counts against your limit.

To avoid exceeding the 10 lookup limit:

• Use IP mechanisms where possible
• Consolidate services
• Create a flattened record that directly lists IP addresses
• Count the total lookups before implementing changes

Working with Client IT Departments on SPF Implementation

As Access developers, our clients typically fall into one of two categories: those with internal IT departments and those without.

For clients without IT resources, the responsibility of updating SPF records often falls directly to us. However, for clients with established IT departments, we should generally defer to their expertise and processes for DNS changes.

Ultimately, we usually won't have a choice in who implements these changes—the gatekeeper is whoever has access to the DNS records.

Prepare Clear Documentation

Before approaching IT, prepare:

1. The exact SPF record changes needed
2. Why these changes are necessary
3. The potential impact on email deliverability
4. A timeline for implementation

Address Common IT Concerns

Be prepared to address these common concerns:

1. Security implications: Explain that properly implemented SPF enhances security
2. Impact on existing email: Assure them that existing services will continue to work
3. Maintenance burden: Clarify that email service providers maintain their own SPF records
4. DNS lookup limit: Acknowledge the 10 lookup limit and confirm your changes won't exceed it

The Risks of SPF Misconfiguration: Proceed with Caution

SPF misconfiguration can have serious consequences, with two primary risks standing out:

Risk #1: Breaking All Email from the Domain

The most severe risk is inadvertently blocking legitimate email by using -all with incomplete server authorization. This can affect not just your Access application's emails but all email from the domain.

Mitigation:

• Start with ~all (SoftFail) instead of -all (Fail)
• Thoroughly inventory all legitimate email-sending sources
• Test extensively before implementing strict policies

Risk #2: DNS Propagation Delays

DNS changes can take 24-48 hours to propagate globally. This means that mistakes cannot be instantly rolled back, creating a window where email authentication may be inconsistent or broken.

Mitigation:

• Implement changes during low-email-volume periods
• Use shorter TTL values temporarily during changes
• Monitor closely during the propagation period
• Consider using a dedicated subdomain for automated emails to isolate risks

Conclusion

SPF configuration is a critical first step in ensuring reliable email delivery for Access applications transitioning away from Outlook automation. While it involves technical complexity and potential risks, proper implementation significantly improves both security and deliverability.

Remember that SPF is just one part of a comprehensive email authentication strategy. In our next article, we'll explore implementing DKIM—the cryptographic signature system that complements SPF and addresses some of its limitations.

By following the guidelines in this article, you'll be well-equipped to implement SPF correctly, whether working with client IT departments or handling the configuration yourself for smaller organizations.

The era of "email just works" is ending, but with proper authentication, your Access applications can continue to deliver reliable email communication in this new landscape.

Acknowledgements

• Article title generated with the help of Claude-3.7-Sonnet
• Article excerpt generated with the help of Claude-3.7-Sonnet
• Initial draft generated with the help of Claude-3.7-Sonnet
• Cover image generated by Imagen3