Use our free SPF checker to validate your record in seconds
Sender Policy Framework, or SPF, is an email authentication technique that helps protect senders and recipients from spam, phishing and spoofing. SPF enables your email server(s) to authenticate whether an incoming message was sent from an authorized mail server – but only when your SPF record is valid.
With Mimecast SPF record check, you can validate an SPF record with just your business domain name. The check identifies any problems with your record and validates updates you’ve applied (glossary below for terminology). DMARC Analyzer SPF Checker can also pre-validate updates you intend to apply. It is strongly recommended to carefully test updates with an SPF record check before applying them to a DNS record.
Use this glossary to understand the results from Mimecast SPF Record Check
- SPF record existence: Logically we require a SPF record in your DNS so we can validate it.
- Multiple SPF records in DNS: You can only have 1 SPF record in DNS for each SPF version. If you publish multiple SPF records (v=spf1), this will invalidate your SPF record. Therefore, you should always update your SPF record rather than entering a new record beside the existing one.
- Maximum Lookups: When using SPF, you can only perform 10 DNS lookups (nested).
- PTR Mechanism Used: We recommend not to use PTR as this is a deprecated mechanism and several senders may (completely) ignore your SPF record if you use this.The function of a PTR record is the opposite of an A record. Instead of resolving a domain name to an IP address, the PTR record resolves an IP address to a domain name. The PTR mechanism validates if the DNS reverse-mapping for an <ip> exists and if it’s able to point to a domain name within a particular domain. The PTR mechanism is slow and not as reliable in comparison with other mechanisms in case of DNS errors therefore we strongly recommend to not use the PTR mechanism.
- Unknown Parts Found: We have detected content which is not in the SPF specification.
- +All Mechanism Used: If you use the SPF mechanism ’all’ with a ”+” qualifier this means you essentially allow anybody to send email on your behalf. The record will first try to match the sending source to another mechanism. If this fails, the default behaviour is to still allow this source. Therefore, this setup is discouraged.
- Invalid Macro: Our SPF record checker will try to validate SPF macros you use. Using some example data, we will give examples of the lookups receivers may perform based on your macro setup.
- Record Termination Missing: An SPF record should always have a ’default’ fall back mechanism. This can either be an ’all’ mechanism or a ’redirect’ modifier. We check if you end your SPF record with either of these.
- Multiple Fall back Scenarios: A SPF record should have 1 fall-back scenario. You have defined multiple.
- DNS Type ”SPF” Used: You have published your SPF record in a DNS type SPF. This DNS type ’SPF’ (/99) was introduced in RFC 4408 in 2006. However, this type became obsolete following RFC 7208 which states: SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR)
- Uppercase SPF: You used uppercase characters in your SPF record. Although it is not a requirement, it is a best practice to publish your SPF records in lowercase.
After running your SPF record through all these checks, you can safely update your SPF record in your DNS!
