In SPF, fallback mechanisms come into play when an email fails SPF checks, but the recipient’s server or policies offer ways to handle or mitigate the failure. They provide you the flexibility in handling emails that fail SPF checks while still being able to maintain security through other email authentication protocols. This ensures that email security is upheld, and phishing and spoofing attempts made by cybercriminals are averted. Let’s understand what these fallback mechanisms include.
Primary SPF fallback mechanisms
1. SPF alignment with DMARC
In situations where the SPF check for an email fails but the DMARC check passes, the recipient’s mailbox can choose to ignore the SPF results and accept the email. You can set the DMARC record to one of the policies:
- p=none: To instruct recipients’ mailboxes to take no action against illegitimate emails sent from your domain.
- p=quarantine: To instruct recipients’ mailboxes to mark illegitimate emails sent from your domain as spam.
- p=reject: To instruct recipients’ mailboxes not to accept illegitimate emails sent from your domain.
2. Soft fail (~all)
The SPF soft fail mechanism, represented by the ~all symbol, tells recipients’ mailboxes not to outright reject illegitimate emails but to treat them with suspicion. So, there is no strict rejection involved, and the server places them in junk or spam folders. It’s usually used during the testing phase when domain owners want to see how many emails would fail without disrupting legitimate email flows.
3. Neutral (?all)
This optional mechanism indicates that the domain owner is not asserting whether a specific IP address is authorized to send emails on behalf of the brand or not. This is the least restrictive SPF policy, typically used when a domain owner does not want to take a stand on whether emails coming from other sources are valid or invalid.
4. SPF hardfail (-all)
This is the strictest option as it tells receiving mail servers that only the IP addresses explicitly listed in the SPF record are authorized to send emails on behalf of the domain, and any emails from unauthorized sources should be rejected. This policy provides the highest level of protection against email spoofing, as unauthorized emails are not allowed to pass through.
5. Fallback to DKIM
DKIM performs authentication checks by generating a unique digital signature for the email using public-key cryptography. This signature is added to the email’s header to ensure that the contents of the email have not been modified in transit. The recipient’s server uses the public key to validate the signature. If the signature is valid, it confirms that the message was not tampered with and came from an authorized sender.
If an SPF check fails, but the email is signed with DKIM and passes that validation, the recipient server might still accept the email. This fallback ensures that emails passing other authentication methods can be trusted even if SPF fails.
6. Local policy overrides
Some receiving email systems allow administrators to set local policies that might override SPF failures. For example, if a specific sender domain frequently fails SPF but is otherwise trusted, the administrator can safelist the domain.
