To protect email traffic against phishing and spam, organisations use various security standards. Well-known examples include SPF, DKIM and DMARC. These standards are configured by the domain owner via DNS settings. They determine how emails sent on behalf of that domain are checked.
As a domain owner, this reduces the risk of malicious parties misusing your domain name. For example, it helps prevent phishing emails from being sent falsely in the name of your organisation.
What do SPF, DKIM and DMARC mean?
Below, we briefly explain what SPF, DKIM and DMARC do and what impact these settings can have on receiving emails. You can read more in-depth information about the different policies here.
SPF stands for Sender Policy Framework. The SPF policy describes which servers are authorised to send email on behalf of this domain. Based on the SPF record, the receiving server will either allow the email to pass successfully, treat it as spam and place it in quarantine, or reject the email entirely.
One limitation of SPF alone is that this policy cannot distinguish between, for example, emails that are forwarded via automatic forwarding and genuinely fraudulent emails. The SPF policy is therefore further supplemented by DKIM and DMARC.
DKIM stands for DomainKeys Identified Mail. Sent emails contain an encrypted “signature” that allows the receiving server to determine whether the email actually originates from the sender’s domain. This encrypted signature can be read by a receiving server, but it cannot be forged by a sending party.
DMARC stands for Domain-based Message Authentication, Reporting and Conformance and describes how the receiving party should handle SPF and DKIM. For example, the policy may state that an email can be accepted by the receiving server if it complies with SPF and/or DKIM. Alternatively, it may state that emails that do not comply with DKIM must always be rejected by the receiving party.
The use of DMARC is only effective if both SPF and DKIM are configured correctly. For example, if SPF is set to “Fail” (“-”), emails that do not comply with the SPF policy will always be rejected, regardless of the DMARC settings.
An additional feature of DMARC is that reports can be requested from receiving mail servers, making the results of the configured policies transparent. These reports indicate, for example, how many emails sent to the receiving server were rejected and for what reason.
What does this mean for receiving emails in Blue10?
It may happen that an email sent to the Blue10 email address is not successfully delivered in Blue10. This may be an email sent directly by the supplier, or an email that you have automatically forwarded to Blue10 yourselves.
The sending party can determine whether or not the email was successfully delivered to the receiving email server. If the email was not delivered because it does not comply with the configured SPF, DKIM and DMARC policies, the owner of the domain from which the original email was sent must resolve this.
As a guide, we are sharing a number of examples in which the receiving server may reject an email:
- An email is forwarded to Blue10 via automatic forwarding. A “Fail” or hard fail has been configured in the SPF policy of the domain, and the server from which the email is forwarded does not comply with the SPF policy of the original sender’s domain.
- The configured SPF record has expired, meaning there is no valid SPF policy.
- The DMARC policy is set to “None”. The domain from which the original email was sent does not provide instructions to the receiving domain on what to do with an email if SPF and/or DKIM fails.
Using free online tools, you can view which SPF, DKIM and DMARC policies have been configured for a specific domain. Click here for an example tool.
