Categories


Authors

How to set up restrictive email anti-spoofing policies

Ben Hooper
IT, how-to, InfoSec

Intro

Back in November 2018, I wrote https://astrix.co.uk/news/2018/11/26/how-to-mitigate-email-spoofing - a holistic guide to email security covering many different controls. Since then, my knowledge on and approach to specifically email anti-spoofing policies has improved quite a bit because:

  1. Back in January 2021, I moved to a company that came with new challenges because it’s significantly larger. The core of this blog post is actually a (sanctioned) public version of one of my internal Standard Operating Procedures (SOPs).

  2. In this new company, I’ve been regularly working with a Professional Services consultant (referred to as “Industry SME” from this point onwards) who knows way more about this stuff than me - especially the real-world practices of different email service providers - because it’s literally their full-time job. Industry SME has actually peer reviewed this SOP.

So, I decided to share my new-and-improved, higher-level advice on how to safely and effectively deploy strong SPF, DKIM, and DMARC. (My old blog post is still valid in the other areas.)

↑ Back to Index

Terms and definitions

Terminology is usually confusing, but particularly so with this topic because it’s ridiculously complex and inconsistent in real life, the latter because “there’s a lot of SHOULDs in the RFCs“, in Industry SME’s words. As a result, there’s lots of incorrect / contradictory information out there that you may have seen before, so it’s important to ensure we’re all on the same page before we start any work.

In case you’re tempted to skip this section, to be clear, I’ve detailed here a lot of crucial information on how these technologies work that you need to understand - it’s not just what acronyms stand for.

Term Definition
Web Domain A domain that has been registered via a public registrar and is accessible via the public web, as opposed to other types of domains such as Active Directory or Tor / Onion.

Refer to https://astrix.co.uk/news/2020/01/20/how-to-secure-internet-domains#DNS
Email Domain A term I made up to mean what is after the @ symbol in an email address.
Spoofing The act of abusing email technology to send an email as someone or something without their authorisation.

A prominent and very damaging example of an email spoofing and social engineering attack is spear phishing - an email sent as a known or trusted entity in order to trick the recipient into performing actions or revealing sensitive / confidential information. For example, an email sent as the external accounting firm to the internal finance manager asking for a bank transfer or an email sent as the IT department to the CEO asking for their password.
SMTP Simple Mail Transfer Protocol

Used to relay / transfer emails from one computer to another. In this context, only server-to-server communication is relevant.

Refer to https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
MTA Mail Transfer Agent

Sometimes known as a Mail Exchanger (MX), a server that uses SMTP to relay / transfer emails. In this context, only border / edge MTAs are relevant to authentication.

Refer to https://en.wikipedia.org/wiki/Message_transfer_agent
DNS RR Domain Name System Resource Record

Refer to https://en.wikipedia.org/wiki/Domain_Name_System and https://en.wikipedia.org/wiki/Domain_Name_System#Resource_records
FQDN Fully-Qualified Domain Name

Refer to https://en.wikipedia.org/wiki/Fully_qualified_domain_name
5321.MailFrom & 5322.From Every email has two from addresses:
1. 5321.MailFrom: Also known as the Return-Path, this one is at the transit / SMTP / "envelope" level used by MTAs.
2. 5322.From: This one is at the content / MIME / "header" level used by email clients and is, therefore, the one that is visible to users. This email address' email domain is also where DMARC looks for a policy.

Refer to:
• https://www.easy365manager.com/rfc-5321-and-rfc-5322/
• https://dmarc.org/2016/07/how-many-from-addresses-are-there/
• https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/how-office-365-validates-the-from-address?view=o365-worldwide#an-overview-of-email-message-standards

Below is an example of how you specify these email from addresses when manually sending an email:
SPF Sender Policy Framework

An email security control that is applied to a domain and is very effective at mitigating spoofing of the 5321.MailFrom address.

This essentially achieved by receiving MTAs comparing an email's sending public IP address to the email domain's (public) SPF policy which includes:
1. A list of explicitly-approved public IP addresses or subnets for sending email services, - either defined directly or via DNS names or other SPF policies.
2. Instructions on what to do with anything unlisted.

Refer to https://en.wikipedia.org/wiki/Sender_Policy_Framework
DKIM DomainKeys Identified Mail

An email security control that is applied to a domain and a sending email service, and mitigates:
• Man-in-the-Middle (MITM) attacks - modification of content in transit.
• Broken SPF checks due to automatic forwarding / Sender Rewriting Scheme (SRS).

(DKIM does not necessarily mitigate spoofing of the 5322.From address because d=<domain> isn’t always automatically derived from the 5322.From address - it's simply a location set by the sending email service where the key can be retrieved.)

This is essentially achieved by a sending MTA using a private RSA key to cryptographically / digitally sign attributes of email data (usually including the 5322.From address) and then inserting the result as a header. Receiving MTAs can then use the public RSA key to decrypt the embedded signature / hash and compare the original values to the actual / current values.

Refer to https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
Organisational Domain A DMARC term that means an organisation's "root" domain name (Second-Level Domain + Top-Level Domain). For example, even if I send emails as example.mythofechelon.co.uk, my Organisational Domain is still mythofechelon.co.uk (mythofechelon + .co.uk).

Refer to https://dmarcly.com/blog/how-dmarc-works-with-subdomains-dmarc-sp-tag
Identifier Alignment A DMARC term which means that:
1. For SPF alignment to pass, the 5322.From and the 5321.MailFrom email domain names must be the same (aspf=s - strict, not default) or at least share a common Organisational Domain (aspf=r - relaxed, default). However, Industry SME has advised that, if you're using any modern large-scale sending email service / platform, it's practically impossible to use strict alignment for SPF because they enforce usage of a subdomain for handling automated bouncebacks, etc.
2. For DKIM alignment to pass, the 5322.From and the DKIM header.d domain names must be the same (adkim=s - strict, not default) or at least share a common Organisational Domain (adkim=r - relaxed, default).

So, for example, example.mythofechelon.co.uk and mythofechelon.co.uk would pass relaxed alignment but would fail strict alignment, and example.mythofechelon.co.uk and mythofechelon.com would fail both.

Refer to:
• https://dmarcian.com/alignment/
• https://help.returnpath.com/hc/en-us/articles/220564567-What-is-DomainKeys-Identified-Mail-DKIM-alignment-for-DMARC-
• https://help.returnpath.com/hc/en-us/articles/224236627
• https://datatracker.ietf.org/doc/html/rfc7489#section-3.1
DMARC Domain-based Message Authentication, Reporting & Conformance

An email security control that is applied to a domain and is very effective at mitigating spoofing of both of the two aforementioned From addresses.

This is essentially achieved by receiving MTAs:
1. Referencing the SPF check result, if available.
2. Referencing the DKIM check result, if available.
3. Extracting the email domains from both From addresses in preparation for Identifier Alignment checks.
4. Referencing the 5322.From domain's public DMARC policy (or, if that doesn't exist, the Organisational Domain's) which includes instructions on:
• What action to take if an email is found to be non-compliant - none, quarantine, or reject.
• Where to email the forensic report if an email is found to be non-compliant. Not all email service providers do this. This is usually done pretty rapidly.
• Where to email the daily aggregate statistical reports of emails sent using the domain name. Most email service providers do this.
• How strict to be regarding subdomains when carrying out Identifier Alignment checks.
etc
5. Failing the check if:
• Both SPF and DKIM authentication results are available and both fail - one failure out of both checks is allowed.
• Only an SPF or a DKIM authentication result is available and it fails.
• No SPF or DKIM authentication results are available. This protects against spoofing of non-existent subdomains, sometimes referred to as a snowshoe attack.
• SPF or DKIM Identifier alignment fails.

The final DMARC check can be considered as the following Boolean equation provided by Industry SME:
[DMARC = TRUE] = [(SPF Auth = TRUE) AND (SPF Align = TRUE)] OR [(DKIM Auth = TRUE) AND (DKIM Align = TRUE)]

Refer to:
• https://en.wikipedia.org/wiki/DMARC
• https://dmarcly.com/blog/how-dmarc-works-with-subdomains-dmarc-sp-tag
External Destination Verification A DMARC control which essentially allows you to consent to receiving DMARC reports for a different domain. This is achieved by publishing a DNS RR in a standard format (example.com._report._dmarc.mythofechelon.co.uk. IN TXT "v=DMARC1;" - case sensitive).

Refer to:
• https://dmarc.org/2015/08/receiving-dmarc-reports-outside-your-domain/
• https://dmarcian.com/what-is-external-destination-verification/
• https://powerdmarc.com/dmarc-external-destination-verification/
SEG Secure Email Gateway

A platform that protects an organisation against inbound and outbound email-based threats such as spoofed emails, infected attachments, or malicious URLs.

Refer to https://www.proofpoint.com/uk/threat-reference/email-gateway

Standards

The following standards are recommended:

  • A dedicated subdomain per sending email service should be used wherever possible.

    The reasons for this are twofold: (1) if a sending email service in an SPF policy is compromised then the scope of impact is only that subdomain rather than the entire "parent" domain and (2) an SPF policy has a maximum of 10 DNS lookups before failure but a single service often causes 3 alone.

  • The following SPF policy / root DNS TXT RR should be publicly published once we're sure that any and all sending email services have been added:
    "v=spf1 <mechanisms for approved services, if any> -all"

    This basically means “we’re 100 % sure that this list is exhaustive so treat anything else as malicious” and typically leads to a reject action.

  • DKIM keypairs must use a length / size of 1024 bits (minimum) or 2048+ bits (preferred).

  • The following DMARC policy (case sensitive) / _dmarc DNS TXT RR should be publicly published once we're sure that all non-compliances have been remediated:
    "v=DMARC1; p=reject; pct=100; fo=1; rua=mailto:dmarcreports_rua@mythofechelon.co.uk,mailto:others@example.com; ruf=mailto:dmarcreports_ruf@mythofechelon.co.uk,mailto:others@example.com"

    The policy action means that the email system should reject the email. However, behaviour may not always be what we're expecting because some MTAs don’t respect these policies. For example, Microsoft’s Office 365 / Exchange Online interprets "reject" as "quarantine" by default.

    The tags that have not been explicitly declared will be default, so, in this case, the notable ones are sp=reject (for subdomains - same as p=), aspf=r (relaxed), and adkim=r (relaxed).

↑ Back to Index

The procedure

Setting up restrictive email anti-spoofing policies for a single domain can take a long time (typically months) so it makes sense to "parallelise" as much of this procedure as possible.

1. Discover web domains

(This step depends on whether we're proactively attempting to seek out domains that may not have proper anti-spoofing policies published for remediation or we've been given a list of domains to work on. If the latter / second, this step can be skipped.)

Any web domain name can be used for sending email so anti-spoofing policies should be published for all those registered to ensure that only the owners’ trusted systems can do so. However, we aren’t always aware of every domain name that has been registered. For example, marketing may have registered a domain name for an advertising campaign but not informed anyone else.

To create a complete-as-possible list of web domain names to work with, we should check with our domain name registrar(s), IT, web developers, marketing, management, etc.

2. Discover services (via DMARC reporting)

Once we have a list of our web domain names, we need to discover what services are sending emails as those domain names so that we can ensure that the legitimate ones are authenticated correctly.

This is where DMARC reporting comes in as it allows us to gain insight into how our domains are being used for email "in the wild" without introducing disruption. This is possible because when MTAs (e.g., Gmail) receive an email from anywhere purporting to be from one of our domains, they SHOULD:

  1. Look up the sending email domain’s DMARC policy (DNS TXT RR at _dmarc.<5322.From email domain name or, if that doesn't exist, the Organisational Domain's>).

  2. Process the email as instructed by the policy (at this stage with the below configuration, do nothing different to normal).

  3. If an email is found to be non-compliant, instantly email a forensic sample which contains the subject and full headers but no content.

  4. Once per day (if the tag ri still has its default value of 86400) and per domain, email an aggregate report to the addresses specified in rua= containing crucial diagnostic information:

    • Sending IP addresses.

    • Both from addresses: 5321.MailFrom and 5322.From.

    • The results of the various authentication checks.

DMARC aggregate reports are XML files so manually analysing them quickly becomes unscalable. To address this, services have become available which ingest this data and render it much more useful and easier to analyse. Dmarcian, for example.

Also, it's important to remember that the DMARC data is not a full picture because not all email systems email DMARC reports. For a long, long time, Microsoft’s Office 365 / Exchange Online was a great example of this.

To implement this, we need to do the following for each domain:

  1. Get the required DNS RRs (values are case sensitive) published, one RR per web domain name. Only "<email domain name>" needs to be changed - the designated email addresses are for all domains.

    • _dmarc.<email domain name>. IN TXT "v=DMARC1; p=none; pct=100; fo=1; rua=mailto:dmarcreports_rua@mythofechelon.co.uk; ruf=mailto:dmarcreports_ruf@mythofechelon.co.uk"

    • <email domain name>._report._dmarc.mythofechelon.co.uk. IN TXT "v=DMARC1;"

  2. Once they have been published, wait a day or longer. This depends entirely on how frequently the email domain is being used, if at all.

  3. Verify that DMARC reports are being delivered to the email addresses / any aggregator services you’re using.

  4. Wait anywhere from a week to a few months to allow representative data to gather. The amount of time will depend on a balance of how much the domain is being abused, how much it's being used legitimately, and how many different types of emails it may be used for (for example, certain types of emails may only be sent every 3 months).

3. Analyse services

After we've collected a representative sample of data, we need to start analysing the services that are reported to be sending emails as our web domain names.

For each domain, we need to:

  1. Analyse the DMARC data.

  2. For each identified sending email service (e.g., Mailchimp, Salesforce, or even just an IP address):

    1. Determine whether the usage is legitimate. If so, proceed.
      Things we can check are:

      • Whether we're aware of or even personally received the emails.

      • General sender reputation. For example, DigitalOcean is known to be abused a lot.

      • Forensic sample metadata such as Reported-URI, subjects, etc.

      • Whether the sending FQDN has been whitelabelled. Attackers usually don't bother doing this.

      • Sending geo region.

    2. Identify the current state of authentication and note any failures as needing remediation:

      1. SPF check results.

      2. DMARC check results, including identifier alignment.

      3. DKIM check results.

    3. Identify the logical location of the service. If it is internal sending out through our standard SEG then SPF and DKIM may already be set up.

    4. Identify whether the sending email service’s provider adequately supports all authentication mechanisms. This is often in public documentation, but sometimes we may need to speak to the provider’s support directly.

      1. Can they provide an SPF policy that we can simply include? If not, can they provide an exhaustive list of sending public subnets or IP addresses? If only a single IP address is used, can they provide a DNS RR instead?

      2. Do they support DKIM signing for outbound email?
        Some providers charge extra for this.

      3. Can they guarantee DMARC compliance, particular Identifier Alignment? Some providers cannot.

      4. Can they prove that emails can only be sent as a domain from their service once proof of ownership has been verified? Some providers do not do this.

    5. Identify the internal service owner (again, this will likely involve a lot of collaboration) and reach a consensus on the plan:

      1. Whether we can change the sending email address(es) to use a dedicated subdomain.

        As the sending email address is user-facing, the service owner should choose the subdomain name (this should probably be something service- / usage-oriented like hr.mythofechelon.co.uk, rather than provider-oriented like hrprovidercompany.mythofechelon.co.uk), communicate the change to users ahead of time, etc.

      2. Anything else we need to know such as support contact details, the location of the service, etc.

If no email services are found then we can jump straight to stage #6 for these domains.

4. Perform remediation

The analysis of the sending email services likely discovered authentication non-compliances which need to be remediated.

Miscellaneous examples:

  • A subdomain is not being used.

  • A subdomain is being used but it hasn't been added to the DMARC aggregator service.
    etc

SPF examples:

  • The domain doesn't have an SPF policy.

  • The domain does have an SPF policy but it is ineffective because it's invalid, it doesn't include all sending email services, or a provider's included SPF policy is invalid.

  • The domain has multiple SPF policies.

DKIM examples:

  • The digital signature / hash is being broken by an in-line MTA of ours due to modification of the content. A common example cause of this is when SEGs apply a footer stating that the content has been scanned by their antivirus engine.

  • The email service doesn't have DKIM set up. This would be remediated by doing the following:

    1. Publishing a public DNS RR with the following configuration:

      • Type: CNAME / Canonical Name or TXT / Text.
        Generally, the former / first will be used if the provider will be managing the RSA keys and vice versa.

      • FQDN: <selector name>._domainkey.<email domain name>.
        Generally, the selector name is dictated by the provider but can sometimes be custom. I recommend using a naming scheme of "<sending email service name>-<date in ISO 8601 format with no separators of when set up>". For example, esc-20220316.

      • Value if CNAME: FQDN pointing to a DNS TXT RR for the DKIM public key

      • Value if TXT: v=DKIM1; k=rsa; p=<public key>

    2. Enabling DKIM signing on our last MTA in the flow, usually the sending email service itself but sometimes in the SEG.

DMARC examples:

  • The domain doesn't have a DMARC policy.

  • The domain does have a DMARC policy but it is ineffective because it's invalid, doesn't have all options that we require specified, or has a neutral policy action (p=none).

  • The domain has multiple DMARC policies.

  • The service sends emails with mismatching email domains / FQDNs in the two From addresses. This is usually remediated by asking the provider to correct this, but sometimes it's within our control within the system's settings.

Before proceeding to the next stage, these types of issues will need to be remediated and verified as successful.

5. Implement light restrictions

Once we're reasonably sure that we've remediated all authentication problems for the domain and any subdomains (there are alternatives for this scenario such as only proceeding with SPF which doesn't inherit or using DMARC's sp=none), we need to start implementing restrictive policies. To minimise disruption, we start with "light" restrictions:

  • SPF SoftFail: ~all.
    This basically means “we’re not 100 % sure that this list is exhaustive so treat anything else as suspicious but potentially legitimate” and typically leads to a quarantine action, rather than a reject.

  • DMARC percentage-based quarantine: p=quarantine; pct=<integer including or between 1 and 100>
    The policy action means that, depending on the email system, the email will be quarantined or delivered to some type of junk / spam folder.
    The percentage means that only the stated percentage will have the stated policy applied and the remaining percentage will have the next-least-restrictive policy, in this case none. For example, if a DMARC record has p=reject and pct=60 then 60% of traffic would be rejected if it fails the DMARC check, and 40% would be quarantined. Refer to https://dmarcian.com/pct-tag/ and https://dmarc.org/wiki/FAQ#What_changes_in_the_draft_submitted_to_the_IETF_affect_me_as_a_sender.3F. However, each SEG implements this differently so we should assume that at least some will apply the new policy action at 100%.

This can be implemented by doing the following for each domain:

  1. Confirm that the syntax of the new drafted policies are valid by using offline validator tools such as the following:

  2. Get the new SPF and DMARC policies published by creating the following DNS RRs per web domain name.

    <domain name>. IN TXT "v=spf1 <mechanisms for approved services> ~all"

    _dmarc.<domain name>. IN TXT "v=DMARC1; p=quarantine; pct=10; fo=1; rua=mailto:dmarcreports_rua@mythofechelon.co.uk,mailto:others@example.com; ruf=mailto:dmarcreports_ruf@mythofechelon.co.uk,mailto:others@example.com"

  3. Regularly review headers of test emails and new DMARC results and ensure there are no new problems.

  4. Repeat the previous steps (5.1, 5.2, and 5.3) with DMARC percentages 25, 50, 75, and 100 at each stage.

6. Implement hard restrictions

Once the light restrictions are in place 100 % and no problems have arisen, we can move on to "hard" restrictions:

  • SPF (Hard)Fail: -all

  • DMARC reject: p=reject; pct=100

This can be implemented by doing the following for each domain:

  1. Confirm that the new drafted policies' syntax are valid by using offline validator tools such as the following:

  2. Get the new SPF and DMARC policies published by creating the following DNS RRs per web domain name.
    <domain name>. IN TXT "v=spf1 <mechanisms for approved services, if any> -all"

    _dmarc.<domain name>. IN TXT "v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; fo=1; rua=mailto:dmarcreports_rua@mythofechelon.co.uk,mailto:others@example.com; ruf=mailto:dmarcreports_ruf@mythofechelon.co.uk,mailto:others@example.com"

  3. Regularly review headers of test emails and new DMARC results and ensure there are no new problems.

↑ Back to Index

Sign-off

As usual, I sincerely hope that this has been useful to someone.

Feel free to subscribe to my newsletter to be automatically notified of new blog posts in the future.

😊

How to back up an iCloud Photo Library offline on Windows

Converting Blurb BookSmart to Microsoft Word