Why Google's push for DMARC is flawed
14/01/25 19:03
OK - I'll start this off with some admiration for Google & Yahoo pretty much mandating that mail sent to them (including GWS hosted domains) has a DMARC policy configured.
For the uninitiated, DMARC is a policy configured in a DNS record for your domain that instructs receivers of email claiming to be from your domain on what to do if the message fails validation from Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).
SPF validates which servers are allowed to send mail from your domain, and DKIM validates the message with a digital signature.
By default, a failure of either or both of these validations (depending on the recipient's mail provider) doesn't mean that the message won't be delivered to the recipient, and the recipient may not be warned about these failures either, as neither of these validations are included in the SMTP mail standard.
Your DMARC policy tells the recipient's mail provider what to do if validation of the message via SPF & DKIM fails. There are three actins that can be defined in the policy:
In reality, Quarantine and Reject policies are essentially the same thing - the (fake) message from you isn't delivered to the recipient.
The None policy tells the recipient's mail provider "even though you know the message is fake, send it to the recipient's mailbox anyway, as if there is nothing wrong with it"
The None policy is intended only for short term testing (along with monitoring enabled by the RUA & RUF parameters in the DMARC policy) so that you can see if you've not configured your SPF & DKIM records correctly (it's common that people forget about their web server that sends messages on their behalf, or forgetting about a mass-mailing service that they use for marketing) or if your sending server isn't signing the outbound messages with a valid DomainKey.
Here's where we get to the root of the problem with Google/Yahoo's recommendation. Their recommendation is to set the DMARC policy to None, and they don't recommend configuring any of the other essential parameters, such as RUA or RUF.
If you're going to set your DMARC policy to None and leave it at that, then you have next to zero protection against Spoofing, where threat actors send emails that claim to be from you to (for example) your customers and suppliers with fake invoices, or notification of a change in bank details. They often also send malware via attachments or links to the same people as part of a targeted phishing campaign (remember that the recipient thinks the message from you, so trusts it). This is a supply chain attack.
Another scenario is that the attacker uses spoofing to gain access to a legitimate email account by tricking your internal IT support to reset a password (it's trivial to set a different reply-to address in a spoofed email - in fact, many marketing mass mailers use this technique)
So what should you do?
There are a number of recommendations:
Remember that email is the key to your kingdom - you need to protect it at all costs.
Here's the good news - we at Cyber Warden can do all this (and much more!) with our Mail Aegis service quickly, inexpensively, and with minimal hassle.
cyberwarden.io/services/aegis
For the uninitiated, DMARC is a policy configured in a DNS record for your domain that instructs receivers of email claiming to be from your domain on what to do if the message fails validation from Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).
SPF validates which servers are allowed to send mail from your domain, and DKIM validates the message with a digital signature.
By default, a failure of either or both of these validations (depending on the recipient's mail provider) doesn't mean that the message won't be delivered to the recipient, and the recipient may not be warned about these failures either, as neither of these validations are included in the SMTP mail standard.
Your DMARC policy tells the recipient's mail provider what to do if validation of the message via SPF & DKIM fails. There are three actins that can be defined in the policy:
- None - Do nothing and let the message pass
- Quarantine - Quarantine the message, and don't forward it to the recipient
- Reject - Reject the message outright
In reality, Quarantine and Reject policies are essentially the same thing - the (fake) message from you isn't delivered to the recipient.
The None policy tells the recipient's mail provider "even though you know the message is fake, send it to the recipient's mailbox anyway, as if there is nothing wrong with it"
The None policy is intended only for short term testing (along with monitoring enabled by the RUA & RUF parameters in the DMARC policy) so that you can see if you've not configured your SPF & DKIM records correctly (it's common that people forget about their web server that sends messages on their behalf, or forgetting about a mass-mailing service that they use for marketing) or if your sending server isn't signing the outbound messages with a valid DomainKey.
Here's where we get to the root of the problem with Google/Yahoo's recommendation. Their recommendation is to set the DMARC policy to None, and they don't recommend configuring any of the other essential parameters, such as RUA or RUF.
If you're going to set your DMARC policy to None and leave it at that, then you have next to zero protection against Spoofing, where threat actors send emails that claim to be from you to (for example) your customers and suppliers with fake invoices, or notification of a change in bank details. They often also send malware via attachments or links to the same people as part of a targeted phishing campaign (remember that the recipient thinks the message from you, so trusts it). This is a supply chain attack.
Another scenario is that the attacker uses spoofing to gain access to a legitimate email account by tricking your internal IT support to reset a password (it's trivial to set a different reply-to address in a spoofed email - in fact, many marketing mass mailers use this technique)
So what should you do?
There are a number of recommendations:
- Correctly configure your DMARC record with a reject policy and appropriate RUA and RUF parameters
- Do some reconnaissance on your supply chain, checking that your suppliers in particular have a robust DMARC configuration
- Educate your end-users on Spoofing & Phishing
- Have a comprehensive set of policies regarding what to do when a
- Implement strong authentication, such as an MFA authenticator app or better still, implement phishing resistant authentication like PassKeys, which don't use passwords at all (your users will thank you).
- Utilize a good inbound mail filtering service
Remember that email is the key to your kingdom - you need to protect it at all costs.
Here's the good news - we at Cyber Warden can do all this (and much more!) with our Mail Aegis service quickly, inexpensively, and with minimal hassle.
cyberwarden.io/services/aegis