SPF, DKIM, DMARC are all tools and various techniques use my email servers such as Google, Yahoo and others to determine the validity of an email that is sent to it. These have evolved over the course of the last few decades as the internet has evolved as well.
SPF
SPF stands for Sender Policy Framework and was the first attempt at putting in any kind of validation to emails that were sent around the world. The SPF is a text record that is attached to the domain name of the from email address. Such SPFs are like the following:
v=spf1 a mx ip4:74.50.55.0/24 ip4:192.99.28.88/29 ip4:192.99.122.140/30 ip4:198.27.75.12 ip6:2607:5300:0060:260c::/64 include:_spf.google.com
This specifies the known 'valid' locations for which emails that are from this specific domain are sent from. This can include reference to other records e.g. A or mx or a specific ipv4 or ipv6 range or includes the SPF of another domain. This is a fairly simplistic check and for most email providers they don't do too much if this fails but fails can hurt your email server reputation.
DKIM
DKIM stands for Domain Keys Identified Mail. It is a technique which involves having a public key stored as a text record on the domain and having the email server doing the sending 'sign' the email using a private key that is matched to the public key that is stored on the domain record. Email servers when they receive the email will detect that it has been signed with a DKIM key and then try and validate that against the public key that is stored in for that From Domain using the specified parameters. A domain can have multiple DKIM keys but the private key used must match the selected public key (by reference to the selector and the version and algorithm that has been used).If this fails it is more likely than not that the email would be then put into the spam folder of the recipient because DKIM is considered a much more stringent test than DMARC.
DMARC
DMARC also known as Domain-Based Message Authentication, Reporting and Conformance, is the most recent of the 3 validation techniques. It surfaced around 2015. DMARC is designed so that domains can specific which of the other validation mechanisms should be used by recipient mail servers and also what action should the recipient server do with an email that doesn't pass the validation. It also specifies where any validation reports should be sent. Domains can specify 3 different policies for when an email fails validation:
* none - Do not do anything special allow for it to be delivered into the Inbox
* quarantine - Deliver the email into the spam folder i.e. Quarantine it from all other emails
* reject - Do not accept the email at all send it back to the original server.
The most well known examples are that Yahoo has set their policy to be reject which means that if you were to send from your sever an email saying that it had a from email of joe.blogs@yahoo.com and tried to send it to a GMail address Google will reject the email as yahoo is saying on accept emails from our servers.
CiviCRM Implications
For CiviCRM, it does not generally worry about SPF, DKIM, DMARC at all. It generally leaves that responsibly to the SMTP server. This maybe the same server as hosts CiviCRM especially if you use the mail() option in your outbound email configuration. Otherwise it is generally a commercial SMTP server that will add in the DKIM signing as appropriate. It is on you or your partner to ensure that the DNS records are set correctly for SPF, DKIM etc as specified by your SMTP server. However CiviCRM does need to care about DMARC especially in one specific case which is when the "Track replies" option is enabled within CiviCRM. In this case what happens is that CiviCRM then essentially becomes a 'relay' I.e it receives the original reply records it got the reply and then has to forward it on. CiviCRM has code to try to add headers into the email to specify that it is re-sending it but it may not work all the time.
Promotions Tab/Other inbox
Certain mail servers such as GMail and Outlook have specific folders or tabs set up to capture 'promotional' email. At present there is no easy work around to prevent CiviCRM emails from landing in those tabs. No matter even if DKIM, SPF, DMARC all pass they can still land there because of the tools deployed by those servers to determine what is promotional material and what isn't.
Comments
Interesting around DMARC and track replies which I hadn't realised, not something our clients use much though.
Matt Wire did a blog a few years ago which I found useful for getting my head around how things work: https://civicrm.org/blog/mattwire/email-authentication-%E2%80%93-spf-dkim-dmarc
Great article!
> ...because DKIM is considered a much more stringent test than DMARC.
I think you meant much more stringent test than **SPF**?
Also, I think we need to explain a key difference between SPF and DKIM which is what they mean by the "from" address.
When you send an email there's normally at least two email addresses that describe where the email is "from".
1. There's the **From** header. This is the one that's visible to everyone that you're probably aware of. It can be a simple email - your email address - but it also allows us to include a "friendly name" part, like "Local BLM campaign", or "Wilma Flintstone".
2. There's the **Return-Path** header. This is a normally-hidden-from-view header and it will be an email address that can be used to receive bounces. Often this address is not your email address, but something that looks a bit nonsense. If you use a commercial SMTP gateway then this will be an address they control and will have either their domain name or a subdomain of yours set up for the purpose. CiviCRM can use this to identify which emails are bouncing and can put them on hold automatially.
3. (There can also be a Sender header, but this is less often used and not discussed here.)
SPF is all about the Return-Path email address. When your server sends mail, a receiving server capable of checking SPF says "ah, server 1.2.3.4 is trying to send mail with a return path domain of email.your.org - let's see if this is allowed by the SPF record found for email.your.org...". If your server's IP address is valid for the SPF record, it's valid. It cares not for your From header. You can send an email with a From header of: "The Prime Minister" if you like, SPF won't stop you and will say your email is valid as far as it is concerned, as long as you have a valid Return-Path. Obviously it's not good to do anything like this. You'll have seen this employed by spammers, especially when it's your own email address you see there in one of those "I've hacked your account, gimme Bitcoin" emails!
DKIM on the other hand is all about the domain of the email address in the visible From header. So here's where your pm@gov.uk email is revealed to be spammy. It's also why email forwarding breaks (the Yahoo policy initially broke a lot of mailing lists like mailman and many convenience alias-based forwarders too).
DMARC can be used to say "let it through if SPF or DKIM is valid", or "only let it through if SPF and DKIM are valid".
None of these techniques will get your email to come up in lights at the top of somone's inbox. As Seamus explains, get these things right and you just won't get marked down. Anti spam techniques go way beyond these policies and are completely out of the control of the sender. In some cases (here's to you, Microsoft) they're also out of the control to the companies themselves because they're usually algorithm based and adapt from day to day with policy tweaks but also the type and volume of mail being sent.