Introduction

By using fake emails, adversaries commonly try and conduct social engineering and spear phishing attacks against organisations. An adversary alters the genuine senders address, or email header to appear as though it came from a legitimate source. Therefore, increasing the chance of their target complying with an action they ask of them in the email such as disclosing information or opening a malicious attachment.

If an organisation implements Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting and Conformance (DMARC) and records in their Domain Name System (DNS) configuration, they can reduce the likelihood of their domains being used to support fake emails.

Secondly, they can get more security against fake emails by using DMARC with Domain Keys Identified Mail (DKIM) to sign emails.

In addition to better protect their users against fake emails organisations can ensure their email systems use and apply SPF, DKIM and DMARC policies on inbound email as well.

And publicly good visible indicators of good cyber hygiene are SPF and DMARC records. In other words, the public can see whether an organisation has SPF and/or DMARC protection by querying a DNS Server. Also visible to any external party is your email and whether there is the presence of DKIM records that are attached to outgoing emails, their presence or lack thereof can be seen.

Firstly, this publication will provide the details of how SPF, DKIM and DMARC work. Secondly, give advice for security practitioners and mail server operators on how to prevent their domains from being used as the source of fake emails. In other words, how to configure their systems.

How SPF, DKIM and DMARC work

Sender Policy Framework

Designed to detect fake emails SPF is an email verification system. As a sender, a domain owner publishes SPF records in DNS to indicate which mail servers are allowed to send emails for their domains.

Firstly, the sending mail servers verifies against the published SPF record when an SPF-enabled mail server receives email. Secondly, verification will fail, if the sending mail server is not listed as an authorised sender in the SPF record.

The diagram below helps you visual the process

SPF ‘from’ header weakness

However, SPF does have a weakness that is known. Mail servers applying SPF policies check the RFC5321. Commonly called the ‘envelope from header’ Mailfrom header email – clients typically display the RFC5322. Commonly called the ‘message/letter from header’ Mailfrom header – to the users as the source of an email.

Therefore, aware of this weakness adversaries bypass SPF checks by using a domain they control in the envelope from header, and the domain they wish to spoof (but don’t control) in the message/letter from header.

DMARC can address this weakness and does by checking that these two headers align. As a result, organisations should use both DMARC in junction with SPF.

Domain Keys Identified Mail

To allow sending mail servers to sign outgoing emails, and receiving mail servers to verify those signatures, the DKIM standard uses public key cryptography and DNS. For this to happen, firstly domain owners generate a public/private key pair. Secondly, the key pair (public pair) is then published in DNS, next the sending mail server is configured to sign emails using the corresponding private key.

The receiver can verify the digital signature attached to an email using the sending organisation’s public key (retrieved from DNS). The following diagram illustrates how this happens.

DKIM ‘from’ header weakness

In the same vein as SPF, DKIM has a known weakness. Mail servers applying DKIM policies check the RFC5321.Mailfrom header (commonly called the ‘envelope from header’) while email clients typically display the RFC5322.Mailfrom header (commonly called the ‘message/letter from header’) to the users as the source of an email.

Meanwhile adversaries being fully wise to the weakness can publish DKIM selectors/public keys in a domain they control, using this domain in the envelope from header, and specifying the domain they wish to spoof (but don’t control) in the message/letter from header.

But adversaries prefer using the SPF weakness compared to the DKIM weakness. The SPF is easier to set up and causes a similar amount of damage.

By using DMARC both weaknesses are neutralised as DMARC addresses the issue by checking that these two headers align. In other words, organisations should utilise DMARC in addition to DKIM to protect themselves against known weaknesses.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

When handling inbound emails, those claiming to come from the owner’s domain, DMARC enables domain owners to advise recipient mail servers of policy decisions that should be made.

Specifically, domain owners can request that recipients:

  • allow, quarantine, or reject emails that fail SPF and DKIM verification
  • notify the domain owner of emails falsely claiming to be from their domain and collect statistics
  • notify the domain owner how many emails are passing and failing email authentication checks
  • send the domain owner data extracted from a failed email, such as header information and web addresses from the email body.

From DMARC notifications and statistics results are sent as:

  • aggregate reports provide regular high-level information about emails, such as which Internet Protocol (IP) address they come from and if they failed SPF and DKIM verification
  • forensic reports are sent in real time and provide detailed information on why a particular email failed verification, along with content such as email headers, attachments, and web addresses in the body of the email.

DMARC is enabled when the domain owner publishes information in their DNS record, just like SPF and DKIM. Then using DNS, the DMARC record of the domain is verified when a recipient mail server receives an email.

To be effective DMARC relies on SPF and DKIM

The following diagram illustrates this process.

Please note: for the protections to be in effect receiving mail servers need to be configured to honour SPF, DKIM and DMARC.

Addressing SPF and DKIM weaknesses

DMARC addresses the weakness in SPF and DKIM by introducing an alignment check. During the alignment check it verifies that the RFC5321.Mailfrom header (commonly known as the ‘envelope from header’) and the RFC5322.Mailfrom header (commonly known as the ‘message/letter from header’) match.

Insights and strategies for effective protection

With a plethora of a toolbox of mechanisms, SPF, DKIM and DMARC can be used to protect an organisation’s domain against being impersonated with email. But, the best approach for your business in deploying these mechanisms will vary and will depending on the mechanism itself and your environment. You may require extra advice.

In this section we’ll discuss the central differences between the mechanisms and advice

This section discusses key differences between the mechanisms and give advice on implementation approach.

SPF vs DKIM

Both SPF and DKIM allow a recipient to determine if an email is legitimate using their mechanisms. However, how they do this is done in different ways. For us understanding the difference between the how helps us understand the area each is better suited to.

For instance:

SPF – can identify a legitimate email because it recognises it is from an authorised source.

  • made by the first mail server that receives the email after being relayed over the internet

DKIM – can identify a legitimate because the email itself is authenticated by a digital signature.

  • irrespective of where the email is received from, the recipient can rely on the digital signature in the email

Most importantly, DKIM authentication is possibly more valuable because the authentication mechanism is:

  • portable, and travels with the email irrespective of the mail servers it passes through (consequently, DKIM can be used for more sophisticated email authentication flows)
  • stronger, being based on public key cryptography (thus, for example, resistant to other attack techniques, such as person in the middle).

However, due to the simplicity of SPF, it is simpler to implement, has been a standard for longer and widely supported, we can’t overlook SPF.

As a result, organisations may find that some circumstances are best served by DKIM, while others are adequately served by SPF, when considering how to authenticate their email flows.

DMARC is critical – implement it now irrespective of your existing controls

On the other hand, DMARC is critical as it provides three unique features in the battle against fake emails. These simplify the implementation of the other controls to combat fake emails holistically:

  • DMARC records are hierarchical: Subdomains will inherit your DMARC policy and its protection. In contrast, both DKIM and SPF require per-domain configuration.
  • DMARC provides visibility: Publishing a DMARC record, with an associated reporting mechanism, will allow your organisation to see how other mail servers see the email flow from your organisation’s domains. This will make it easier to implement email authentication controls such as SPF and DKIM by enabling you to identify email flows and configuration errors.
  • DMARC allows a phased approach to implementing email authentication methods: DMARC allows a domain owner to publish email authentication mechanisms (through SPF and DKIM) but then set their enforcement policy at ‘none’, which will, for DMARC-aware mail servers, override any other result, such as an SPF fail due to not having an SPF record.

Certainly, implement DMARC immediately, no matter where your organisation is in terms of implementing anti-spoofing controls. Even if you are only active it, in monitoring mode (‘p=none’) configuration.

DMARC also addresses weaknesses in alignment checks.

SPF still matters

While SPF is simple to understand, implement and is a useful indicator domain owners should really continue to use it. Even if it has significant security weakness, it still matters.

When it comes to maintenance and implementation of new features mail servers often receive little attention, it’s evidenced across the internet.

Many mail servers only have SPF policy agents these haven’t taken up DKIM and DMARC, so they won’t look for, and interpret, DKIM markings and DMARC records.

However, in the future the uptake of DKIM and DMARC by recipient mail servers will improve. In the meantime, domain owners should publish SPF records to identify authorised mail servers for all domains.

If you need more information, take a look at the General strategies section below.

Anticipating recipient mail server behaviour

The configuration and support of policy agents on recipient mail servers can vary. When taking into considering how SPF, DKIM and DMARC records are used to authenticate email by recipient mail servers, the following list of standards-compliant configurations for recipient mail servers (the mail servers your organization is sending email to) may be useful:

  • Recipient mail server does not support SPF, DKIM or DMARC: Your markings and policies will have no effect.
  • Recipient mail server supports only SPF: Only SPF policies will be followed. If an email flow relies on DKIM for authentication, and you have a hard fail SPF, mail servers that are only SPF aware may drop your email. Likewise, if you are relying on a DMARC p=none configuration to allow email to flow in the presence of a hard fail SPF, mail servers which are only SPF aware will likely drop your email.
  • Recipient mail server supports only DKIM: While this configuration is possible, it is unlikely a recipient mail server will drop email for not having a DKIM signature, as this would result in many emails being discarded. Emails may be dropped for having an invalid DKIM signature though.
  • Recipient mail server supports SPF and DKIM: A mail server configured thus would enforce SPF and DKIM rules potentially in isolation. For example, if the sending mail server is not specified in a hard fail SPF record the mail server may refuse delivery of the email before it checks for a valid DKIM signature.
  • Recipient mail server supports DMARC, SPF and DKIM: By standard, to support DMARC, recipient mail servers must also support SPF and DKIM. The recipient mail server will apply your DMARC policy by evaluating both SPF and DKIM checks and allowing email that passes either test to flow.

In addition, it’s also worth noting that many recipient mail servers may not necessarily act strictly in accordance with your policy instructions even if they’ve consumed the information you publish via SPF, DKIM and DMARC.

But rather decide for themselves on what to do or use  SPF, DKIM and/or DMARC information to make a better choice such as an anti-spam filter.

General strategies

Your organisation can target to assist other recipient mail servers in identifying fake email claiming to come from your domains, these general strategies are presented as potential end states.

Best practice

To ensure the best possible protection to the widest amount of recipient mail servers, the best practice strategy seeks to provide the best way to protect. It will then allow within limits, the protection of recipient mail servers operated by others who don’t stay up to date with standard:

  • DMARC enables the quarantining or rejection of 100 percent of the emails that fail SPF and DKIM checks. The DMARC policy is configured to your organisation’s root domain and subdomains which decide on quarantines or rejections. And the DMARC record along with publishing at your organisation’s root domain also has a location for reports, and these reports are captured into a system and reviewed regularly by your email or cyber security teams. In addition, the lower level DMARC records are published on a subdomain-by-subdomain basis where a different policy is required.
  • To specify authorised mail relays, all of your domains, subdomain and hostnames have a hard fail SPF record. Included are the specifications for no mail relays for domains that do not send email.
  • All outbound email flows that leave the organization DKIM is utilized. But when sending authority to a third-party mail relay, there may be a desire not to delegate excessive email sending authority, which means that SPF is inappropriate. As too if there’s a complexity of the email flow, SPF is inappropriate.

Good practice

The strategy of good practice tracks down information to provide recipient mail servers with good information to make good policy decisions. But that depends on whether they’ve stayed up to date with standards by implementing a DMARC policy agent to evaluate DMARC, SPF and DKIM policy published by senders:

  • DMARC enables the quarantining or rejection of 100 percent of the emails that fail SPF and DKIM checks. The DMARC policy is configured to your organisation’s root domain and subdomains which decide on quarantines or rejections. And the DMARC record along with publishing at your organisation’s root domain also has a location for reports, and these reports are captured into a system and reviewed regularly by your email or cyber security teams. In addition, the lower level DMARC records are published on a subdomain-by-subdomain basis where a different policy is required.
  • Outbound mail servers for domains, subdomains and hostnames which send email are explicitly specified with an SPF record which includes a hard fail.
  • When sending authority to a third-party mail relay, there may be a desire not to delegate excessive email sending authority, which means that SPF is inappropriate. As too if there’s a complexity of the email flow, SPF is inappropriate.
  • Domains, subdomains and hostnames which are not explicitly authorized through an SPF record, or a DKIM selector, are implicitly protected by the overarching DMARC record.

How to implement SPF, DKIM and DMARC

Sender Policy Framework

Identify outgoing mail servers

Including your primary and backup outgoing mail servers, identify your organisation’s authorised mail servers. If they send emails directly, you may also need to include your web servers. In addition, identify other entities such as advertising or recruitment firms who send emails on behalf of your organisation and use your domain as the email source.

Construct your SPF record

SPF records are specified as text (TXT) records in DNS. An example of an SPF record might be v=spf1 a mx a:<domain/host> ip4: -all where:

  • v=spf1 defines the version of SPF being used
  • a, mx, a:<domain/host> and ip4: are examples of how to specify which mail server is authorised to send email
  • -all specifies a hard fail advising receivers to drop emails sent from your domain if the sending mail server is not authorised. Note, for DMARC-enabled recipient mail servers they will apply the policy published in your DMARC record. However, if your SPF record is configured as a soft fail (e.g. +all) then the SPF test will never fail, and consequently all email will pass DMARC checks.

Most importantly, ensure that for each of your subdomains you set a separate record as subdomains do not inherit the SPF record of their top-level domain.

To make it easier, you can redirect the record lookup to another SPF record if you want to avoid creating a unique record for each subdomain. For Instance, the top-level domain record or a special record for subdomains would be the easiest way.

Identify domains that do not send email

If a domain does not send emails and the organisation wants to use the best practice strategy, the best practice is to specify v=spf1 -all in the SPF record for that domain. That way emails claiming to be from that domain can be rejected, as it advises receiving mail servers that there are no authorised sending mail servers for the specified domain.

Warn your users

If any implementation issues arise you want to know so ensure users are told of the new SPF email policy so they can report any issues. Once SPF is implemented you should note that emails sent from non-authorised mail servers, may not reach their destinations, such as those outside the corporate network. Provisions should be made if users are required to send email while they are not in the corporate network so authenticated remote access can be achieved. Specified in the SPF entry, authorised mail server.

Test your SPF record

Ensure you test your SPF record, as it confirms that emails are processed correctly. You can help assess the correctness of SPF records by using tools such as MX Lookup before finalising them. A hard fail policy (i.e. -all) is the preferred approach for SPF. However, you may wish to use a soft fail policy while testing. This is done by specifying ~all instead of -all in the SPF record. So, you can be made aware of potential issues before implementing a hard fail policy, combining this with DMARC reporting.

If not treated correctly, the older methods of forwarding emails, can fail SPF checks. (e.g. .forward files on UNIX-based systems)

That is to say if your operating agreement is like this, you may want to consider converting forwarded emails to re-mailed emails using Sender Rewriting Scheme (SRS). To address these kinds of issues, there are emerging standards coming in such as Authenticated Received Chain (ARC).

Deploy your SPF record

Above all ensure the Time to Live (TTL) is set low (e.g. 5 minutes) when you have an SPF record you intend to deploy. Setting the TTL low will allow you to correct or rollback your SPF record quickly in the case of an issue.

Monitor the success of the SPF record after deployment

It will take some time before mail servers on the internet recognise the implementation of a new SPF record. Moreover, your existing SPF record timings are defined by the TTL associated with this record. However, if you don’t have an existing SPF record the TTL is different. Firstly, review your domain’s ‘start of authority’ to determine the negative cache TTL value, sometimes referred to as ‘minimum TTL’ – This number, in seconds, is the maximum time it should take mail servers on the internet to detect your new SPF record – a typical default value is 7,200 seconds (i.e. two hours). You should monitor your mail server up to the TTL time and confirm that email delivery is continuing normally, once you implement an SPF record. Meanwhile recipient mail servers will begin to reject your email, if you have the configuration of your SPF incorrectly.

Incorporate SPF into the change management process and associated procedures

Whenever new email sending mail servers are deployed, DNS entries are added, and DNS entries or IP addresses of sending mail servers change, SPF records will need to be updated. In other words,

  • new mail servers will need to be added to the SPF record of the associated domains
  • new SPF records will be required (including wildcard SPF records)
  • the SPF record of all associated domains will need to be reviewed

Most importantly, update your procedure management processes to account for these changes.

Additional resources

For more information about SPF, see the SPF standard and its update.

For on how to setup SPF, see Microsoft’s Set up SPF to help prevent spoofing publication and Google’s Help prevent email spoofing with SPF publication.

see Microsoft’s Sender Rewriting Scheme (SRS) in Office 365 publication for additional information on SRS

Domain Keys Identified Mail

Decide what sections of your email you want to sign

The more protected you are from adversaries sending fake emails that appear to come from youi, when you sign more sections of an email.

For instance, the body and the following headers of emails should be signed:

  • to
  • cc
  • date
  • from
  • subject
  • sender
  • reply-to
  • references
  • mime-version
  • content-type
  • references
  • in-reply-to
  • return-path
  • content-disposition
  • content-transfer-encoding

It is also important to sign headers one more time than the number of times they occur, if supported by your email software. For more information on why this is important check out Breaking DKIM – on Purpose and by Chance publication.

Decide when to sign your outgoing email

If signed sections of emails are changed during delivery, DKIM verification may fail. It doesn’t have to mean an adversary has interference. It could mean after signing an email, you attach a legal disclaimer.  In other words, because the content of the email has now changed, it will likely invalidate the DKIM signature.

As a result of not wanting to invalidate DKIM signatures on outgoing emails, you need to firstly understand your email infrastructure and secondly realise when the content of email changes.

To start your DKIM rollout we recommend to sign emails as they leave the email gateway. After that if you come across any issues you can always change it to assist your email setup. But normally, doing it this way reduces the chance of unintended changes, if you’re signing emails at the last stage before they leave the infrastructure under your control.

Generate your public and private keys for DKIM

To generate a public/private key pair, you will need a tool. The type of tool you chose will depend on your organisation, its key management plan and operating system. If there’s no specific tool for your organisation, there are these available: ssh-keygen for Linux, Microsoft Windows and macOS

In the terminal for your operating system run ssh-keygen -b 2048 -t rsa -f filename to generate a public/private RSA key pair. The key length will be 2048 bits and the public/private keys will be called filename.pub and filename respectively.

Once you’ve created the public/private key pair be aware that you need to keep it safe. In other words, protect your private key in accordance with your organisation’s key management plan. Otherwise, an adversary could potential be able to sign into your emails as you, if your private key becomes public. And you don’t want that.

In addition, if you want different parts of your organisation to have the ability to independently sign emails, you may want to generate multiple public/private key pairs.

Publish your public key in your DNS record

Public keys for DKIM are published in DNS TXT records. You will need to include a different TXT record for each private/public key pair you want to use by using a selector. You will then need to configure your mail server to specify the correct selector when sending emails.

Make sure you put the public keys at ._domainkey.yourorganisation.com.au where selector must be different for every public/private key pair. For example, you might have brisbane._domainkey.yourorganisation.com.au and melbourne._domainkey.yourorganisation.com.au for different offices in your organisation.

The content of the record itself will be similar to v=DKIM1; k=rsa; p=

Warn your users

Notify SPF users of the change. That way, they are aware and can advise of any unpredicted change in email behaviour.

Develop and test your mail server configuration

Prior to implementation test the environment, identify how your mail server implements DKIM and test your configuration as rigorously as you can.  

Configure your mail server to attach DKIM records to its headers

If your infrastructure allows it, a phased implementation approach is recommended. After deployment, immediately test any emails are being signed correctly. You can do this by sending emails to external email accounts and reviewing email headers.

Monitor after deployment

If you have already configured DMARC, now DKIM has been added, you can use DMARC email reports to verify how many emails are failing DKIM checks.

Additional resources

For additional information on DKIM, see the DKIM website, the DKIM standard and its first and second update.

For additional information on how to setup DKIM, see Microsoft’s Use DKIM to validate outbound email sent from your custom domain publication and Google’s Increase security for outgoing email with DKIM publication.

Domain-based Message Authentication, Reporting and Conformance

By publishing a policy as a TXT record in DNS is the way DMARC is implemented and then it acts hierarchically. For instance, whatever policy is published in the main domain (organisation.com.au) will automatically apply to the sub domain (sub.domain.organisation.com.au). Unless there’s an explicit subdomain policy that’s different from the main domain. As a result, organisation for wider coverage can specify a smaller number of high-level DMARC records.

As a result, care should be taken when configuring the sub-domain to ensure they don’t inherit the DMARC record of the main domain.

It is advisable when implementing DMARC, to first implement it in:

  1. monitoring mode, then
  2. quarantine mode
  3. and finally reject mode

As the implementation maturity level increases.

Policy inheritance with DMARC

We often describe DMARC policy as hierarchical due to the reason above. However, the mechanism may not always work as a hierarchy.

DMARC policy agents on recipient mail servers will perform a maximum of two lookups to determine if there is an effective DMARC policy, to avoid to many DNS look ups.

Firstly, the initial check (lookup) is done of the domain the email claims it’s from. Secondly, a lookup in done on the organisation’s domain. What is the organisations domain exactly? It refers to the highest order non-public suffix of the email’s from domain (that is, the end of the domain that includes the public suffix, and the next part of the domain name). For example:

  • An email is received from @a.b.c.yourorganisation.com.au.
  • A DMARC policy agent first checks for a TXT record at _dmarc.a.b.c.yourorganisation.com.au. If this record exists, and is a valid DMARC policy, then it will be the applied DMARC policy.
  • If no records exists at this location, the DMARC policy agent:
    • uses a public suffix list to identify the public suffix as the end of the domain name (e.g. com.au)
    • appends the first domain name part that is not in the public suffix part of the domain (e.g. yourorganisation), to arrive at yourorganisation.com.au – the highest order non-public suffix of the email’s from address
    • checks for a TXT record at _dmarc.yourorganisation.com.au (note: _dmarc.b.c.yourorganisation.com.au and _dmarc.c.yourorganisation.com.au are not checked by the policy agent).

Most organisations implementing DMARC will likely want to rely on DMARC inheritance so should consult a public suffix list (e.g. https://publicsuffix.org/) to determine the correct level to apply a DMARC record at to give policy coverage.

Entities of Australian state and territory jurisdictions may find that their state or territory has removed their jurisdiction from the public suffix list, and hence a DMARC record published at ..gov.au may not be inherited by subdomains. Contact your State or Territory Government’s Chief Information Security Officer’s office if this applies to you and you require further information.

Monitoring mode

Even before you’ve implemented SPF or DKIM in your infrastructure, you can start your DMARC implementation. This can be done using a simple monitoring policy for your domain which requests that DMARC-capable mail servers send you statistics about emails they see using your domain. But keep in mind you won’t be able to move beyond this step when you implement SPF or DKIM in your infrastructure.

And as you launch SPF and DKIM, you’ll notice reports supplying details of the number and IP addresses of emails that pass these checks. Furthermore, you’ll also see those that don’t pass these checks. In other words, you have insight how much legitimate traffic is passing SPF and DKIM checks. Secondly, you can check your SPF or DKIM configuration based on any problems you see.

As a result, you’ll see just how many fake emails are being sent, and from where they are being sent because you now have full view. Now it is time to put in process to review reports from recipient mail servers sent in accordance with DMARC configuration to identify malicious activity.

For example a DMARC record is v=DMARC1; pct=100; p=none; sp=none; ruf=mailto:[email protected]; rua=mailto:[email protected] where:

  • v=DMARC1 defines the version of DMARC being used
  • pct=100 specifies the percentage of emails subjected to filtering
  • p=none specifies the policy for your organisation domain
  • sp=none specifies the policy for all your organisation subdomains
  • ruf=mailto:[email protected] states the email address to which forensic reports should be sent
  • rua=mailto:[email protected] states the email address to which aggregate reports should be sent.

Most importantly, you will need to include a special record in the receiving domains DNS record, if you plan to send your DMARC reports to a domain that is not the domain for which the DNS record exists.

Quarantine mode

The next step is to implement a quarantine policy, when you believe that all or most of, your email traffic is protected by SPF or DKIM. Meaning it will mark emails from your domain that fail verification as spam for those DMARC-enabled mail servers.

To clarify, you will still get the full statistical reports that show what is happening with your emails, even if you request that only a small percentage of your email traffic have a quarantine policy applied.

And as your implementation issues are fixed you can gradually increase to 100 percent.

Reject mode

Once you’ve done some testing using a quarantine policy, the next step is to implement a reject policy. In other words, emails that fail SPF and DKIM verification that have DMARC-enabled mail servers will be rejected. You can again monitor the results through reports and request that this policy only be applied to a small percentage of your emails (with the remaining percentage being quarantined). Based on reports and gauging from the feedback from users you can gradually increase to 100 percent implemented.

Additional resources

See the DMARC website and the DMARC standard for additional information on DMARC. The DMARC website also identifies common problems with DMARC records and includes answers to frequently asked questions.

See the Global Cyber Alliance website for additional information and assistance in generating a DMARC record,

See Microsoft’s Use DMARC to validate email publication and Google’s Increased security for forged spam with DMARC publication for additional information on how to setup DMARC.

Other standards to combat fake email

Authenticated Received Chain

Authenticated Received Chain or ARC for short is an up and coming standard.

It aims to

  • address the problem where intermediate mail servers may need to modify emails to deliver them (such as email list software)

or

  • where downstream mail servers are unable to perform checks such as SPF.

And proposes

  • a signed chain of custody which allows intermediate mail servers to attest to the validity of DKIM and SPF checks at each step

Even if DMARC checks would otherwise fail, downstream mail servers can choose to rely on these attestations. For more information about Authenticated Received Chain Overview presentation in DMARC.org’s 

Additional resources

For additional information on ARC, see the ARC standard.

Further information

To protect their systems and data from cyber threats the Information Security Manual is a cyber security framework that organisations can apply.

And to compliment the framework is the advice in the Strategies to Mitigate Cyber Security Incidents, along with its Essential Eight.

And to reduce the incidence of malicious email entering an organisation’s environment effective email filtering is an important control. These effective strategies are discussed in the ACSC’s Malicious Email Mitigation Strategies publication.

Marketing and Filtering Email Service Providers publication you’ll find the secure use of marketing and email filtering service providers is discussed in the ACSC’s .

Further information can be found in the ACSC’s Implementing Certificates, TLS, HTTPS and Opportunistic TLS publication Re:  TLS encryption and Mail Transport Agent Strict Transport Security (MTA-STS) can be used to protect email confidentiality and integrity against person-in-the-middle attacks.

Contact details

If you have any questions regarding this guidance you can write to us or call 1300 CYBER1 (1300 292 371).

Annex A: Detailed examples and edge cases

Records for SPF, DKIM and DMARC are published as follows.

Analysis of common SPF syntax

Using an example of v=spf1 a mx a:<domain/host> ip4: -all:

  • mx specifies that recipients should accept the mail servers identified by the mail exchanger (MX) record for your domain/host
  • a specifies that recipients should accept the mail server identified by the A record for your domain/host
  • a:<domain/host>, ip4: are examples of specifying other hosts that can send email, either by an A record or an IP address
  • -all specifies a hard fail directing receivers to drop emails sent from your domain if the sending mail server is not authorised.

Note, the +all and ?all flags should never be used as they could allow any mail server to send emails from your organisation. Further, be careful when using include or redirect. If you include or redirect a domain whose SPF record’s syntax is incorrect, mail servers will return an error when validating emails against your SPF record.

Redirecting subdomains SPF records to save time

An individual SPF record should be set for each domain and subdomain, depending of course on the general strategy adopted. To make it easier you can redirect each subdomain to your top-level domain. In other words, you’ll avoid creating a unique SPF record for each subdomain and save time. For instance, you can set all subdomain records to be v=spf1 redirect=yourorganisation.com.au. As a result, all subdomains will use the SPF record of their parent domain yourorganisation.com.au, according to this configuration. This is useful, if for instance all emails from subdomains pass through a centralised email relay.

If you want all subdomains to have a specific SPF record that is different from that of the top-level domain, you could redirect to a special subdomain. As an example, all subdomains would use the SPF record at spf.yourorganisation.com.au if you set all the subdomain records as v=spf1 redirect=spf.yourorganisation.com.au. That’s to say, you only need to maintain one actual SPF record for all subdomains.

Examples of what your DNS records may look like for different scenarios

Domains that don’t send email – best practice

yourorganisation.com.au. TXT “v=spf1 –all”

_dmarc.yourorganisation.com.au. TXT “v=DMARC1; p=reject; ruf=mailto:[email protected]; rua=mailto:[email protected]

Even though this domain doesn’t send email, the SPF record is needed to prevent adversaries sending emails pretending to be you and the DMARC record is needed so you are notified when this happens.

The email accounts specified in the DMARC record, [email protected] and [email protected], are examples of email addresses you could use to receive DMARC reports.

Domains which send email

yourorganisation.com.au. TXT “v=spf1 a mx a:domain1.com.au ip4:1.2.3.4 –all”

selector1._domainkey.yourorganisation.com.au. TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK5iAj+54lsAg4qRRCnpKK68hawSd8zpsDz77ntGCR0X2mHVvkf0WEOIqaspaG/A5IGxieiWer+wBX8lW2tE4NHTE0PLhHqL0uD2sif2pKoPR3Wr6n/rbiihGYCIzvuY4/U5GigNUGls/QUbCPRyzho30wIDAQAB”

_dmarc.yourorganisation.com.au. TXT “v=DMARC1; p=reject; ruf=mailto:[email protected]; rua=mailto:[email protected]

Subdomains which don’t send email

subdomain.yourorganisation.com.au. IN TXT “v=spf1 –all”

Subdomains which send email

subdomain.yourorganisation.com.au. IN TXT “v=spf1 redirect=yourorganisation.com.au”

selector1._domainkey.subdomain.yourorganisation.com.au. TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK5iAj+54lsAg4qRRCnpKK68hawSd8zpsDz77ntGCR0X2mHVvkf0WEOIqaspaG/A5IGxieiWer+wBX8lW2tE4NHTE0PLhHqL0uD2sif2pKoPR3Wr6n/rbiihGYCIzvuY4/U5GigNUGls/QUbCPRyzho30wIDAQAB”

In these examples, there are no DMARC records published. For the sake of this example we are assuming the parent domain has published a DMARC policy which we are accepting through inheritance.

Example of DKIM signature header in an email

DKIM-Signature a=rsa-sha256; d=yourorganisation.com.au; s=selector; c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938; h=from:from:to:to:cc:cc:subject:subject:date:date:sender:sender:content-type: content-type:content-transfer-encoding:content-transfer-encoding:content-disposition:content-disposition:mime-version:mime-version:reply-to:reply-to:in-reply-to:in-reply-to:references:references; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Further examples, as well as advice on what to do with domains you aren’t currently using, can be found in the Messaging, Malware and Mobile Anti-Abuse Working Group’s M3AAWG Protecting Parked Domains Best Common Practices publication.

Edge cases

Hosting services on a shared IP address

Hosting your mail server on a shared IP address could mean that other people can send emails as your domain, if they have a service on the same IP address. That’s to say, SPF authentication resolves to IP addresses rather than domains.

For example, your mail server is acorp.com with an IP address of 1.1.1.1 and you authorise emails to be sent from this domain with an SPF record of v=spf1 mx –all (assuming that your mx record resolves to 1.1.1.1). If bcorp.com also hosts a service at 1.1.1.1, then bcorp.com can send emails claiming to be acorp.com as they have the same IP address and SPF resolves and authenticates on IP addresses.

For additional advice visit the Marketing and Filtering Email Service Providers publication available on ACSC.

Publishing SPF records for HELO names used by your mail servers

There is a SPF standard with recommendations suggesting both:

1.HELO name specified by the connecting mail server

2. MAIL FROM field of the envelope

**undergo an SPF authorisation check

But note, if you are using a different domain for the HELO name, and the MAIL FROM field of the SMTP connection, you will need to construct SPF records to authorise both the mail server you are using in the HELO field and the address you are using in the MAIL FROM field. For example of two example scenarios.

Emails are being sent from [email protected] but being relayed by your email list service provider’s mail server mail.bcorp.com.au

  • To authorise the MAIL FROMacorp.com.au. IN TXT “v=spf1 mx a:mail.bcorp.com.au –all”.
  • To authorise the sending server: mail.bcorp.com.au. IN TXT “v=spf1 a –all”.

Note, if you publish a nil SPF record for the hostname of your email relay some SPF filters will reject it.

Emails are being sent from [email protected] via mail.bcorp.com.au

In this case, publishing the below SPF entries, will result in some SPF filters rejecting email due to the HELO hostname lookup:

  • acorp.com.au. IN TXT “v=spf1 mx a:mail.bcorp.com.au –all”
  • mail.bcorp.com.au. IN TXT “v=spf1 –all”.

A correct configuration could be achieved by using mail.bcorp.com.au. IN TXT “v=spf1 a –all”.

Treatment of CNAME records

Canonical Name (CNAME) records are a common DNS technique used to enable transparent redirection to an alternate domain name. They are frequently used by organisations to redirect requests for services to a third-party service provider (e.g. a public cloud). While this is an effective technique, organisations need to be aware that a CNAME record effectively delegates all DNS calls for the target domain to the domain specified in the answer section. For example, if you have yourorganisation.com.au CNAME serviceprovider.com.au then requests for the SPF, DKIM and DMARC records for yourorganisation.com.au will be answered as if directed to serviceprovider.com.au. Hence, if a CNAME record is used in your DNS record to redirect requests to an alternate domain, then it will not be possible for you to specify SPF, DKIM and DMARC records. This is a risk that needs to be accepted when deciding to delegate DNS records in this manner. Appropriate SPF, DKIM and DMARC records can be discussed with your service provider, and can be specified in contracts when engaging with such services.

Sending DMARC reports to a different domain

If your domain is yourorganisation.com.au, and you want to send your reports to report.com.au, then the recipient domain (report.com.au) needs to have a TXT DNS record at yourorganisation.com.au._report._dmarc.report.com which has content v=DMARC1.

If you are sending all your reports to the same domain, you may want to implement a wildcard DMARC record so you can receive reports from anyone who wants to send them to you. A wildcard record would be *._report._dmarc.report.com which specifies v=DMARC1. However, doing this does allow your domain to receive reports you have not explicitly authorised. This could be used by an adversary to cause you inconvenience.

 

Want insights like this in your mailbox? Join our monthly mailing list

How can we make your business better with IT?