Domains with Lax DMARC Policies

Lax DMARC policies do not explicitly advertise to mail servers that fraudulent emails should be either quarantined or rejected, guarding your domain's reputation and allowing for spoofing reports

Details ¶

DMARC policies are TXT records hosted on your DNS servers that instruct receiving email servers on how to handle emails claiming to originate from your domain, especially those that fail SPF or DKIM tests. SPF and DKIM failures are described below and DMARC provides a policy with how email servers should handle emails that fail one or both checks.

As an example, if SkySiege publishes a DMARC policy, it could specify that emails failing both SPF and DKIM should be rejected because SkySiege only sends emails which pass both DKIM and SPF checks. Therefore an email claiming to be from skysiege.net but fails either check is not legitimate and can be either quarantined or rejected.

Without a DMARC policy email servers can choose what to do with failing emails, including simply ignoring the failed checks. This means that spoofed emails can be be presented as legitimate emails from your organisation simply because there’s no confirmation via the DMARC policy that spoof emails should be rejected or quarantined.

Adding a DMARC policy adds explicit guidance on how to deal with emails that fail validation and can advertise an endpoint for receiving reports for any spoofed emails discovered in the wild.

SPF Failures ¶

SPF (Sender Policy Framework) is a straightforward mechanism where you, as the owner of a domain, use a TXT record in your DNS records to specify which email servers are authorized to send email on your behalf. For example, if you own the domain example.com and your emails are hosted on mailserver.com, you can configure an SPF TXT record to state that only mailserver.com is authorized to send emails for example.com. This allows receiving email servers to verify whether emails claiming to be from your domain originate from legitimate sources based on the email server sending the email.

DKIM Failures ¶

DKIM (DomainKeys Identified Mail) adds a layer of security by associating your emails with a cryptographic signature. When setting up your email server a private key and a public key is generated. The public key for your email server is then published via DNS TXT record, and your email server is configured so that every email sent for your domain is signed with the corresponding private key.

When receiving emails for your domain other email servers can verify the email’s signature against the public key to confirm its authenticity as only the private key can sign emails that match the public key. Any emails whose signatures do not match the public key adverised via the DKIM DNS TXT record are to be treated as compromised in that either the email itself has changed or that the sending email server is not using or has access to the private key that corresponds to the advertised public key.

Remediation ¶

Firstly determine that your DKIM and SPF records exist and are accurate. It’s important to ensure that your legitimate emails are configured appropriately so that they are not negatively affected by your DMARC policy.

Once that is complete and your legitimate emails are signed appropriately, a DMARC record is ready to be published by creating a TXT record at the subdomain _dmarc such as _dmarc.example.com. This policy should reflect your organisation’s risk appetite, however, we prefer a strict reject policy for failed emails which can be implemented via a record such as:

"v=DMARC1;p=reject;adkim=s;aspf=s;sp=reject;pct=100;"

This policy rejects all email for the domains and any subdomains which fail either DKIM or SPF checks.