Table of Contents
SPF records can be added easily by just adding a new TXT record to DNS.
But how does the syntax for an SPF record work?
Let’s start at the back, where the words “all” always appear. The end bit could take in three possibilities:
~all = softfail -all = hardfail ?all = neutral
In today’s world of fraud over email, we always recommend hardfail, but see caveats below if you’re forwarding email…
Here is a sample hardfail record that adds an custom IPv4 address and default Outlook 365 settings:
"v=spf1 a mx ip4:a.b.c.d include:spf.protection.outlook.com -all"
Here is another explanation about the difference between the dash and the tilde is:
The tilde and dash identify they different types of failures. Consider a message that doesn’t match the parameters specified in the SPF record. Tilde is for a softfail, the message will be accepted and marked if it doesn’t match parameters specified. Dash is for a hardfail, the message will be rejected if it doesn’t match.
What does + or no + mean in front of records?
According to the official SPF syntax guide:
The default qualifier is “+“, i.e. “Pass”
That means, technically there really is no difference between
Caveats with SPF
“Yes, the consensus is to avoid hard fails on SPF records since it breaks email forwarding unless the forwarding server uses SRS. The “~all” entry is generally preferred since it gets messages from non-standard senders bumped up in spam detection systems, but doesn’t outright fail them.” – Reference
Don’t ever include more than one SPF TXT record.
SPF records can only have 10 entries. See here:
Can you forward email to Google from a non-Google domain and still have SPF pass?
It’s hard to forward email to to Google from a non-Google domain and still have SPF pass. This is due to security restrictions – how can Google be programmed to accept legitimate email from “any” domain and make it pass?
There is technology called SRS rewriting that can make it work reliably. Here is a guide based on Postfix to make it work:
Here is the background as to why this is hard:
A typically Google fail for SPF forwarding will look like this:
After an SRS implementation you have this:
Hard fail versus soft fail
Help prevent spoofing and spam with SPF: https://support.google.com/a/answer/33786?hl=en
DKIM uses a private and public key pair for signing, and the public key is stored in a TXT record in the DNS zone. When the email arrives at the other side, the remote system checks to see if the keys are valid.
If you are unsure if your DKIM is working, you can use this validator:
Send a test message as per their instructions to them, and then follow the link to see if DKIM is working good.
You could also send a test message to any Google account, and then “Show Original” will reveal DKIM status.
You might experience the error below caused by temporary network glitches. If you’re unsure if DKIM is valid, use the validator to test your DKIM configuration.
550-DKIM: encountered the following problem validating domain.com: 550 pubkey_unavailable
The DKIM guide below is quite intense but if you follow it, and the tip, then you will be good.
If you don’t have a listener on port 8891, then follow the last answer on this post, the one about ExecStart
Help prevent spoofing and spam with DKIM: https://support.google.com/a/answer/174124
Turn on DKIM for your domain: https://support.google.com/a/answer/180504