SPF is the email authentication protocol that allows domain owners to specify which mail servers they officially allow to be used to send emails on behalf of a domain. Wildcarding in SPF is done using the ‘*’ mechanism. It matches any domain or IP that doesn’t explicitly match other mechanisms in the record. Wildcarding usually simplifies SPF records; however, at times, it introduces risks.
Here is a list of the pros and cons of wildcarding in SPF. It’s up to you to decide which one weighs more for your situation. You can accordingly decide whether to use or avoid wildcarding.
Pros of using wildcarding in SPF
1. Ease of configuration
With wildcarding, it becomes a lot easier to configure SPF records with the correct set of mechanisms, modifiers, and qualifiers. This is more useful for domains that have many subdomains linked to them or for companies that frequently add new subdomains. So, with wildcarding, you don’t have to explicitly list each subdomain or IP. In such scenarios, wildcarding behaves as a catch-all.
For example, v=spf1 * ~all allows all servers to send emails on behalf of a domain.
2. Handles unforeseen subdomains
If a new subdomain is created, wildcarding ensures that emails from these subdomains will pass SPF checks without requiring updates to the SPF record.
3. Minimizes maintenance overhead
If you run a company with multiple employees, you will know how difficult it is to deal with dynamic IPs or third-party services. Maintaining a well-updated list of authorized senders becomes cumbersome. However, by introducing wildcarding, you can reduce the need for constant updates.
4. Compatibility with dynamic environments
Organizations using ephemeral IPs or frequently changing infrastructure (e.g., cloud services) benefit from wildcarding since it accommodates changes without requiring immediate SPF updates.
5. Fallback mechanisms for legitimate but unexpected senders
If legitimate emails are sent from an unlisted IP or subdomain, wildcarding prevents these emails from failing SPF checks, reducing the chances of email delivery issues.
Cons of using wildcarding in SPF
1. Increased security risks
Wildcarding allows any server to be used to send emails from your domain. Threat actors leverage this to send phishing and spoofing emails in the name of your organization. This ultimately defies the purpose of implementing SPF in the first place.
Example Scenario:
If you use v=spf1 * ~all, a malicious actor can spoof your domain to send phishing emails, and those emails will pass SPF checks.
2. Difficulty in tracing issues
It will get really difficult to trace the source of a malicious or unauthorized email if you have used a wildcard in your SPF record. This happens because SPF is designed to compare the sending server’s IP address or domain against the mechanisms in the SPF record. However, the ‘*’ mechanism matches any domain or IP address that doesn’t explicitly match another mechanism in the record.
3. Degrades email authentication standards
Wildcarding conflicts with best practices for email authentication, especially when used alongside DMARC. It creates ambiguity, making DMARC enforcement less effective.
Wildcarding can simplify SPF management, but it isn’t considered a best practice because of the significant risks associated with it. The convenience it offers comes at the cost of compromised email security and domain reputation. To mitigate risks and enhance security, we suggest striving for precise SPF configurations and regularly auditing your email authentication protocols.
