Examining SPF and DMARC Records - Part 4

Let's take a closer look at a few domains and assess whether their email protection mechanisms are properly deployed.

Disclaimer

It is worth noting that all of these records are readily accessible to the public and can be queried by anyone. However, I have made the decision not to disclose the names of these organizations. The purpose of this exercise is to learn and improve, not to fingerpoint and expose any shortcomings in their practices.

For the purposes of this examination, all queries were performed on May 1st, 2023. It is noteworthy that query results may differ in the future if domain owners make changes to their DNS records.

Also note that while a record may be syntactically correct, it may not be up-to-date. Consider a hypothetical scenario where a company had incorporated an SPF record for Survey Monkey in their email authentication process. Although the company ceased using Survey Monkey long ago, they failed to eliminate it from their SPF record. In such a scenario, the SPF record would still be syntactically correct, but it would not accurately represent the current email practices of the company.

Example 1 - Domain: w***r.ca (as of May 1st 2023)

dmarcian.com reports that this domain is well protected against abuse by spammers.

Their SPF record is as follows

v=spf1 include:spf.protection.outlook.com -all

This record specifies that the only authorized sender for the domain w***r.ca is spf.protection.outlook.com, and any other sender should be treated as unauthorized (-all).

spf.protection.outlook.com is a Microsoft service used for email security. We can conclude from this that w***r.ca is using Exhange Online for their email service.

Their DMARC record is as follows

v=DMARC1; p=reject; rua=mailto:dmarc@w***r.ca; ruf=mailto:dmarc-forensic@w***r.ca; sp=reject; fo=1; pct=100; ri=864000; adkim=s; aspf=s

This record can be analyzed as follows:

• "p=reject" means that any email messages that fail DMARC authentication should be rejected by the recipient's mail server.
• "rua=mailto:dmarc@w***r.ca" specifies the email address where aggregate DMARC reports should be sent.
• "ruf=mailto:dmarc-forensic@w***r.ca" specifies the email address where forensic DMARC reports should be sent.
• "sp=reject" indicates that the policy for subdomains should be the same as for the main domain.
• "fo=1" indicates that forensic reports should be generated for failed DMARC authentication messages.
• "pct=100" indicates that DMARC checks should be applied to all messages. This can be removed as pct=100 is the default if there is no pct tag in the record.
• "ri=864000" specifies the duration in seconds for which aggregate reports should be kept by the receiving mail server. In this case, the duration is set to 864,000 seconds (10 days).
• "adkim=s" specifies the alignment mode for the DKIM signature, indicating that strict alignment should be used.
• "aspf=s" specifies the alignment mode for the SPF check, also indicating that strict alignment should be used.

Example 2 - Domain: s**********h.org (as of May 1st 2023)

dmarcian.com reports that this domain is well protected against abuse by spammers.

Their SPF record is as follows

v=spf1 include:spf.constantcontact.com include:spf.protection.outlook.com -all

This record specifies that the only authorized senders for the domain s**********h.org are spf.protection.outlook.com and constantcontact.com, and any other sender should be treated as unauthorized (-all).

Their DMARC record is as follows

v=DMARC1; p=reject; rua=mailto:manager@s**********h.org

This DMARC record is relatively simple. It indicates that the domain has a DMARC policy of "reject", meaning that any emails that fail DMARC authentication should be rejected by the receiving server. The only DMARC reporting mechanism specified is the "rua" tag, which sends aggregate reports to the email address "manager@s**********h.org".

There are some other tags that could be specified in a DMARC record, such as "sp" to specify a policy for subdomains, and "adkim" and "aspf" to specify alignment requirements for DKIM and SPF, respectively. However, this record does not include any of those tags. When omitted, default values for aspf and adkim tags is Relaxed “r”.

Example 3 - Domain: l*****s.ca (as of May 1st 2023)

Dmarcian.com reports that this domain is not properly protected against abuse by spammers.

Their SPF record is as follows

v=spf1 mx a:mail.a************e.ca a:mail.e***************n.com a:mail.g************e.org include:spf.protection.outlook.com include:sf1.capris.net include:sf2.capris.net include:spf.mandrillapp.com -all

The mx mechanism, as specified in the SPF record, designates the MX record in the DNS as authorized. The DNS MX record identifies the server responsible for accepting email messages for the domain.

Therefore, this record specifies that the authorized senders for the domain l*****s.ca are spf.protection.outlook.com, mail.a************e.ca, mail.e***************n.com, mail.g************e.org, sf1.capris.net, sf2.capris.net, spf.mandrillapp.com, and any other sender should be treated as unauthorized (-all). However, sf1.capris.net and sf2.capris.net return SPF record NULL value which should be investigated to ensure SPF works as intended.

This domain has no DMARC record. Therefore, it is at risk to being abused by phishers and spammers. This will put their clients at risk of falling victim to email-based attacks, such as spoofing and phishing. It is recommended that the domain implement a DMARC record as soon as possible to ensure better email security.

Example 4 - Domain: e*******n.ca

dmarcian.com reports that this domain is not properly protected against abuse by spammers.

Their SPF record is as follows

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:turbo-smtp.com ptr:mail.sharepointonline.com -all

This record specifies that the authorized senders for the domain e*******n.ca are spf.protection.outlook.com, servers.mcsv.net, turbo-smtp.com, mail.sharepointonline.com and any other sender should be treated as unauthorized (-all). 

However, this record includes PTR tag. The PTR tag was a mechanism used in SPF records to authorize the IP address of the SMTP server that is sending email on behalf of a domain. It checks the reverse DNS (PTR) record of the IP address to ensure it matches the domain name in the "MAIL FROM" field of the email header. If it doesn't match, the email may be considered suspicious or rejected. The PTR mechanism has been DEPRECATED. Most importantly some large receivers will skip the mechanism or worse they’ll skip the entire SPF record.

Their DMARC record as follows:

v=DMARC1; p=none; pct=100

e*******n.ca has a valid DMARC record but the DMARC policy does not prevent abuse of its domain by phishers and spammers as p tag is set to none. p tag applied to emails that fail the DMARC check. Authorized values: "none", "quarantine", or "reject". "none" is used to collect feedback and gain visibility into email streams without impacting existing flows. "quarantine" allows Mail Receivers to treat email that fails the DMARC check as suspicious. Most of the time, they will end up in your SPAM folder. "reject" outright rejects all emails that fail the DMARC check.

Example 4 - Domain: a********s.com (as of May 1st 2023)

dmarcian.com reports that this domain is not properly protected against abuse by spammers.

Their SPF record is as follows

v=spf1 include:eu._netblocks.mimecast.com include:spf.protection.outlook.com include:_spf.psm.knowbe4.com include:spf-ca.emailsignatures365.com ip4:38.116.196.138 ~all

This record specifies that the authorized senders for the domain a*******s.com are eu._netblocks.mimecast.com, spf.protection.outlook.com, _spf.psm.knowbe4.com, spf-ca.emailsignatures365.com and 38.116.196.138. The tilde (~) before "all" indicates that any email that does not match the criteria specified in the SPF record should be marked as a "soft fail". When an SPF record includes ~all (softfail qualifier), receiving servers typically accept messages from senders that aren't in your SPF record, but mark them as suspicious.

Their DMARC record is as follows

v=DMARC1; p=none; rua=mailto:3f4e32b49bfa521@rep.dmarcanalyzer.com; ruf=mailto:3f4e32b49bfa521@for.dmarcanalyzer.com; fo=1;

This domain has a valid DMARC record but the DMARC policy does not prevent abuse of this domain by phishers and spammers as p tag is set to none. fo tag is used for forensic reporting options. Authorized values: "0", "1", "d", or "s". "0" generates reports if all underlying authentication mechanisms fail to produce a DMARC pass result, "1" generates reports if any mechanisms fail, "d" generates reports if DKIM signature failed to verify, "s" generates reports if SPF failed.

Relaxed vs Strict alignment

We used these terms a few times above and you may be wondering what exactly they mean and which one you should use, so let's dive in!

The default alignment setting for DMARC authentication is called "relaxed alignment." This means that the domain used in the Return-Path or DKIM signature can be a subdomain of the "From" address. For example, if the "From" address is "user@example.com," the Return-Path domain could be "notfound.example.com" or the DKIM signature could use "email.example.com." However, DMARC requires that the domains in the Return-Path and From headers match exactly for the SPF check to pass.

In contrast, "strict alignment" means that the domain used in the Return-Path or DKIM signature must exactly match the domain in the "From" address. For example, if the "From" address is "user@example.com," the Return-Path domain and the DKIM signature must also use "example.com."

In general, it is best to use the strictest DMARC policy possible for all domains and subdomains to ensure maximum security. However, the possibility of using strict alignment may depend on the email service providers and recipients you are dealing with. For instance, if your email provider requires a subdomain for authentication, setting the DMARC policy to strict alignment may not be possible.

Overall, the default relaxed alignment is usually sufficient to prevent unauthorized emails from being delivered. But if you allocate subdomains to clients or third-party services, it may be a good idea to require strict alignment for those specific subdomains to ensure that each entity can only send emails from their assigned subdomain.

This concludes our article series on Email Domain Protection mechanisms.

And here are some useful links for further reading:

1. DMARC.org - https://dmarc.org/
2. SPF Record Syntax - https://tools.ietf.org/html/rfc7208#section-3.1
3. Understanding DMARC - https://www.sparkpost.com/resources/email-explained/dmarc/
4. How to Implement SPF - https://www.dmarcanalyzer.com/spf/how-to-implement-spf/
5. DKIM Explained - https://www.dmarcanalyzer.com/dkim/dkim-explained/
6. Microsoft Office 365 Email Authentication
7. SPF/DKIM/DMARC Setup Guide for Google Workspace
8. Can I Set Up DMARC without DKIM?
9. DMARC Identifier Alignments

These resources will help you better understand and implement email domain protection mechanisms to secure your organization's emails.