This SMTP data can be considered to have three primary components:

1. The email ‘envelope’ which contains the HELO, MAIL FROM and RCPT TO elements.

• HELO is the command that is sent by an email server to identify itself when connecting to another email server to initiate an email (or a similar starting command known as ELHO). This command contains the sending email server's domain name. In this case it claims to be agency.qld.gov.au but this could be set to be any domain and does not need to be the domain associated with the server initiating the sending of the email.
• MAIL FROM starts the email transfer, and it provides a sender mailbox which is the ‘envelope from address’.
• RCPT TO is the email address of the intended recipient of the email that the receiving server will send it to.

DATA commences message part of the email which contains the message header and the message content. The data component finishes with the final ‘.’ on a line by itself.

2. The message header, which is the To, From and Subject lines.

• To is the address of the recipient.
• From is the address displayed by the email client and can be considered as the ‘message from address’. This should be the address of the person writing the message, but it can be set to any address and this is what is used to create spoof emails.
• Subject is the displayed subject line, and the rest of the lines are the email message contents.

3. The rest of the email is the message body – that is the contents of the email, and this ends when the final line with a single ‘.’.

QUIT then terminates the SMTP session established with HELO.

Email authentication mechanisms

There are three primary email authentication mechanisms used to verify an initial email: SPF, DKIM and DMARC. These are outlined below. A newer mechanism known as Authenticated Received Chain (ARC) supplements DMARC and is also being adopted by message sending providers. Adoption of ARC is essentially transparent. It is designed to preserve and verify the results of email authentication checks as the message passes through multiple intermediaries, forwarding services or other relays (more detail provided below).

Sender policy framework (SPF)

SPF is the simplest (and least robust) of the email authentication mechanisms available.

When an email is sent, the receiving email server checks the sending email server’s address against the published SPF record for the sending domain, which is the domain specified in the envelope’s HELO or MAIL FROM statement (also called MFROM).

If the IP address of the sending email server is an address included in the SPF record of the domain specified in HELO or MAIL FROM, the email passes the SPF check.

To setup SPF, a domain publishes a DNS TXT record that contains the IP addresses of all the email servers that are authorised to send emails for that domain, including those of service providers used to send emails on their behalf (such as Microsoft 365).

A weakness of SPF that is exploited by malicious parties is that it checks the IP addresses specified by the SPF record of the domain of the HELO or MAIL FROM ‘envelope from address’, not the ‘message from address’ which is the address the reader of the email sees.

To exploit this, a malicious actor can send an email using an envelope sending address (HELO or MAIL FROM) for a domain they control (e.g. malicious.com as in the above example). The sending server is checked against the addresses permitted by the SPF record at malicious.com and this would pass SPF. Without an enforced DMARC policy this email will be delivered to the recipient and will appear to the email reader as being from and address of accounts@agency.qld.gov.au even though it was sent from malicious.com. DMARC prevents this from happening.

DomainKeys identified mail (DKIM)

DKIM is an email authentication protocol where sending email servers sign outgoing emails using public key cryptography and receiving email servers verify those signatures to confirm it was sent from a legitimate sender of the organisation and that it has not been tampered with during transit.

To facilitate this, domain owners generate a public/private key pair and the sending mail server is configured to sign emails using the private key. The signature is unique to the email as it is generated by using the private key to encrypt a hash of selected email headers and the email body. The DKIM signature is added to the email as a new header that specifies the domain signing the email.

The public key from this pair is then published in the domain's DNS records. A domain can have multiple valid DKIM key pairs, which is made possible by giving each key a name, known as a ‘selector’.

When a receiving email server receives an email that has been signed by a DKIM sending server, it uses the selector name stored in the email header during the DKIM signing process to query the domain's DNS and retrieve the public key associated with that selector. This key is then used to decrypt the encrypted digital signature attached to the email, and if successful, this confirms that it was sent by an authorised email sending server.

Having multiple keys allows for different senders to sign on behalf of the sending domain. For example, a newsletter mailing service can DKIM sign emails on behalf of an organisation. They can provide the public key to be published on the domain’s DNS along with the selector name they have used. That way receiving email servers can obtain the third-party provider’s public key from the organisation’s domain to check the validity of the email even when it was sent from a different domain of the mailing service.

DKIM has a similar weakness to SPF in that when the email is signed with a DKIM key, the domain specified in the DKIM header can be set to any domain the sending email server wants. This can allow adversaries to publish DKIM keys using a domain they control, passing DKIM, but still using a message from address from a different domain that they do not have legitimate rights to send from.

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

DMARC is an email authentication mechanism which addresses the weaknesses identified above in SPF and DKIM. It does this by checking the domains used for the sender on the envelope is from the same organisation as the sender in the message that is displayed to the email reader. DMARC is the best available protection organisations can take to prevent the abuse of their domains, stop spoofed messages, and protect their brand.

For SPF, DMARC does this by performing an alignment check on the two addresses involved (envelope and message). The receiving email server will compare the HELO or MAIL FROM domain from the envelope used to verify SPF with the domain of the ‘From: ‘ address in the message header. If they align the message will pass DMARC, and if they are not aligned, DMARC will fail.

In the example above, the MAIL FROM domain is malicious.com and the From: domain is agency.qld.gov.au, as they are not the same, this will fail DMARC.

For DKIM, DMARC likewise checks the alignment of the domain specified in the DKIM header (d=) with the message ‘From:’ domain, and if they align, DMARC will pass.

DMARC alignment for both SPF and DKIM can be set to be ‘strict’ which requires both domains to be exactly the same. It does, however, default to performing ‘relaxed’ alignment (aspf=r) which allows a subdomain (for example mail.agency.qld.gov.au) to be counted as ‘aligned’ to a primary domain (agency.qld.gov.au).

Note that DMARC only requires either an SPF or a DKIM alignment check to pass for the message to pass DMARC. This can be useful, as a legitimate forwarded email may fail SPF but using DKIM alignment it can still pass DMARC and be authenticated.

Once DMARC checks are completed, how the email is handled is affected by the organisation's stated DMARC policy, can be one of three following options:

• ‘None’ policy enables collection of statistics about emails being sent from addresses that use your organisation’s domain. This enables security staff to configure email systems to pass DMARC checks. This policy mode does not affect any existing email delivery and does not provide protection from spoofing of your email domain.
• ‘Quarantine’ policy instructs email servers to deliver any email which passes DMARC to the recipient’s inbox, and any email which fails DMARC to the recipient’s junk email folder. This policy mode will lift email delivery rates, as receiving email servers will be able to check that emails sent on behalf of your organisation are legitimate or not, but it can also mean malicious email that looks like it comes from your organisation will still be available to the recipient through their junk email folder and they may still be compromised if the open and action it.
• ‘Reject’ policy offers the greatest protection by instructing email servers to reject and not deliver email which does not pass DMARC checks (and is therefore a spoofed or illegitimate email). This is recommended and should always be the policy for domains that are not intended to send email (see Parked domains below).

Even though it has no impact on email delivery, setting a DMARC policy of None is a useful first step when seeking to protect your domains at it instructs the receiving email system to send a report, called an aggregate report, to a specified email address which provides statistics and information relating to DMARC compliance.

These reports are in a compressed XML format and are best ingested into a DMARC tool for correlation and analysis. Once the files are being received through the DMARC policy addresses, organisations can track the delivery of their email and make the necessary changes to SPF and DKIM to ensure that legitimate emails are being authenticated without impacting their delivery before changing the DMARC policy to Quarantine or Reject.

Authenticated received chain (ARC)

If an email is forwarded, the original authentication results may no longer hold true. SPF may fail as the forwarding server may not be authorised to send on behalf of the original domain. DKIM may fail if the email content is modified by adding a mailing list footer or security message.

ARC works by creating a ‘chain of trust’ by allowing each intermediary (for example a forwarding service) to add its own authentication results to the email headers. These results are cryptographically signed, so the next recipient or mail server can verify the integrity of the chain and decide whether to trust the email.

The forwarding ARC compliant server adds an ARC header to the email which can have the following components:

• ARC-Authentication-Results (AAR): Records the results of SPF, DKIM, and DMARC checks performed by the forwarding server (Example: spf=pass; dkim=pass; dmarc=pass).
• ARC-Message-Signature (AMS): Cryptographically signs the email content and the AAR header to ensure they haven’t been tampered with.
• ARC-Seal (AS): Cryptographically signs the entire ARC chain (including all previous ARC headers) to maintain the integrity of the chain.

Each intermediary adds its own set of ARC headers, creating a chain of trust.

No specific implementation is required for ARC for email servers which support it, but it is useful to understand it is there and how it works if authentication issues need to be solved.

The DMARC authentication process in detail

As described above, there are three different domain addresses that are used in DMARC authentication, referred to by many different names in available documentation. For the purposes of this explanation, the following terms are used:

• email ‘Sending domain’ which is obtained from the email envelope MAIL FROM command or from HELO/EHLO. This domain can be set to any value by the sending server
• email ‘From domain’ which is obtained from the ‘From:’ address in the email message header – this is the address displayed to the user in their email client
• ‘DKIM domain’ obtained from the ‘d=domain’ tag in the DKIM header entry. There can be multiple DKIM signatures on an email, so there may be multiple DKIM domain entries to check.

The authentication process steps

SPF check

• Extract Sending domain (if present) from MAIL FROM, or from HELO/EHLO or both.
• Check IP address of sending mail server is allowed by SPF record of the Sending domain – if YES, SPF passes.

SPF DMARC alignment check (if SPF check passed)

• Extract ‘From domain’ from the message ‘From:’ address (RFC5322.From).
• Compare the From domain with the sending domain (as per strict or relaxed) – if the domains align then DMARC passes.

DKIM check

• Extract DKIM domain (d=domain) and selector name (s=selector) from the DKIM signature in email header.
• Retrieve the selector public key from the DNS of the d=domain DKIM domain.
• If able to decode the DKIM signature with the retrieved key, then DKIM passes.
• Note a single email may contain multiple DKIM signatures. Each should be checked for a pass in turn. Any DKIM signature passing is an overall DKIM pass.

DKIM DMARC alignment check (if DKIM check passed)

• Retrieve the DMARC policy of the ‘From domain’ from the message ‘From:’ address. If the domain does not have an explicit policy, check if it is a sub-domain, and if so, collect the DMARC policy from the associated primary domain.
• Check if the policy alignment is strict or relaxed (relaxed is default if not specified).
• Compare the DKIM domain with the ‘From domain’ based on the alignment specified.
• Note a single email may contain multiple DKIM signatures. If one or more align then DMARC passes.

Apply DMARC policy

• If DMARC has failed, then apply the DMARC policy of the message ‘from domain’. If the policy is none, deliver the email to the recipient. If the policy is quarantine, deliver the email to the recipient’s junk folder. If the policy is reject, don’t deliver the email to the recipient.

DMARC reports

Email servers that support DMARC provide two different reports to organisations which have a DMARC policy in place. These are an aggregate report (known in the DMARC specification as an RUA report) and a forensic report (known as an RUF). Technically, RUA stands for ‘Report URI Aggregate’ which expands to ‘Reporting Uniform Resource Indicator for Aggregate reports’ – in other words, the address to which to send an aggregate report. RUF is a similar contraction but for Forensic reports.

These reports are emailed to addresses specified in the published DMARC policy.

Aggregate reports (RUA)

• Combined data on a group of emails.
• Not real-time, they are sent everyday by default.
• Sent in XML format.
• No personally identifiable information.
• Supported in all DMARC-compliant mailbox providers.
• Best imported into a tool such as DMARC Analyzer to enable the data to be analysed and used.

Forensic reports (RUF)

• Details of an individual email.
• Sent almost immediately after the failures – but randomly and only occasionally (perhaps around 1 in 1000 failed emails).
• PGP encrypted plain text format.
• Contains personally identifiable information.
• Supported in only a handful of mailbox providers.

Aggregate reports provide data about DMARC policy application and are best imported into, presented and analyzed through a DMARC analysis tool. The information provided includes details of the email quantity and authentication status for SPF, DKIM, and DMARC. Included are sending hostnames and IP addresses. Aggregate reports only contain message counts and email authentication characteristics, and no email message contents, recipient details or any other identifiable information.

Forensic reporting is a feature of DMARC that allows email domain owners to receive detailed information about the delivery and disposition of email messages which fail DMARC tests. Forensic reporting provides information about the authentication status of email messages, including information about the sender IP address, the email message headers, and the authentication results. This information can be used to identify and investigate cases of email spoofing and phishing attacks, and to improve the overall security of the email domain.

The number of forensic reports returned is randomly selected, and very low, and some emails servers will send no forensic reports. Most received reports will be of obvious spoof emails, but they can be useful if an organisation is having issues understanding why their DMARC may be seeing failed emails.

To read a forensic report, the message needs to be decrypted. If an agency is using the Queensland Government instance of the DMARC Analyzer and wish to view a forensic report, please contact CyberSecurityUnit@qld.gov.au for assistance. Information about how to do this and appropriate keys to use will be provided.

DMARC Analyzer

The Queensland Government is currently using the DMARC Analyser tool to read and analyse RUA and RUF reports. The following shows the elements of the DMARC Analyzer tool’s display when viewing the details of emails.

Initial set up of DMARC on domains

Domains which have no DMARC policy established should set a default policy as a priority as detailed below.

The use of the qld.gov.au RUA and RUF addresses shown below ensures that if the whole of government service provider is changed, DMARC records will not need to be changed as the Queensland Government mailers will be redirected to any new service provider without requiring actions from agencies.

Agencies can obtain access to the Queensland Government DMARC analysis tool by sending an email to CyberSecurityUnit@qld.gov.au with the names and email addresses of the staff requiring access. The Cyber Security Unit can also provide training and documentation on the tool’s use, and assistance in implementing DMARC.

The following instructions are based on an example domain of agencydomain.qld.gov.au. This domain will need to be replaced with your domain.

Domains not intended to be sending emails

The following DNS records should be established for any domain which is not sending emails as clearly all emails that seem to be being sent would be unauthorised and likely malicious. This includes any domains that are registered to keep them from being used by someone else, a type of domain often known as a ‘parked’ domain. These records ensure that any emails that attempt to spoof the domain will be rejected.

The first SPF record should be in place on these domains to ensure SPF checks will always fail, as no valid servers apply.

Because SPF is not inherited by subdomains, the addition of the second record also ensures that all subdomains of the parked domain will also ensure they always fail SPF checks, whether the domains are defined or not.

The fourth record sets a DMARC reject policy for the domain, which will ensure that any email messages that are spoofed to use the domain address will be rejected and ensures that the reports of these spoofed messages are sent to the Queensland Government DMARC analysis tool.

Because DKIM spoofing attacks are very rare due to the cost and complexity of setting up a DKIM spoof, no DKIM record is generally required for these non-email sending domains and sub-domains and the combination of the specified SPF and DMARC records will provide the necessary protection for these domains, since the SPF check will always fail, and with no DKIM, DMARC will also fail.

However, a wildcard DKIM reject entry can be established which will prevent DKIM spoofing attacks, it causes no issues and is simple to do. This entry is also useful to ensure that if a domain was previously used to send email and had an active DKIM selector setup, that this DKIM is no longer valid.

If a domain publishes an A or AAAA record but is not setup to receive mail it is recommended to also publish a ‘NULL’ MX record.

This prevents emails becoming stuck in sending email server queues, as without it the sending email server could continue to attempt delivery to the domain for a period of time, potentially weeks (see A "Null MX" No Service Resource Record for Domains That Accept No Mail).

Domains sending emails

The following DMARC record enables the Queensland Government DMARC analysis tool to receive reporting information on email delivery and has no impact on the delivery of agency emails.

Next steps

Once one of the DMARC policies above is active on your DNS, statistics will start to show in the DMARC analysis tool. If the domain is being used to send emails, this will show the level of DMARC compliance for your emails and identify if there are SPF or DKIM changes that are required.

These changes can be implemented over time, and the results are monitored in the tool. Once all legitimate email sending services have been appropriately configured, the default DMARC policy can be moved to a protective state (either quarantine or reject).

Implementing SPF

SPF is implemented as a TXT record in a domain DNS. An SPF DNS text record should be added to the authoritative DNS zone for all registered organisational domains and subdomains that send email. The following is the standard format where <server list> is a list of IP addresses of valid email servers:

<server list> is a combination of mechanisms such as ip4, a, mx, etc used to define a list of valid servers for sending email for this domain. See SPF Record Syntax for the full syntax of an SPF record.

<server list> can leverage the include mechanism to reference servers from another domain (e.g. a parent or third-party email sending domain) as valid sending sources.

For example, if an agency had two email servers with the IP4 addresses of 123.123.123.123 and 123.123.123.124 would be:

The ‘~all’ at the end is important and some form of ‘all’ statement must be at the end of an SPF record. As ‘all’ matches everything, it says ‘everything else on the internet is not authorised.’

There are a few options for this part of SPF. This guideline recommends using the ‘softfail’ version (~all) for all domains which are intended to be sending emails, and the ‘hardfail’ option (-all) for all domains which are not intended to send any emails.

The SPF RFC 7208 defines a hardfail SPF (-all) in such a way that it means that SPF has failed and the email should be rejected. Softfail (~all) means that SPF has ‘Not Passed’ and the email should be treated as suspicious but not rejected outright.

When used with DMARC, softfail is the more appropriate approach, as a legitimate email may fail SPF but pass DKIM and then pass DMARC based on correct DKIM alignment. While email servers should correctly handle this in most cases and process the DKIM and DMARC evaluations despite the use of a hardfail on SPF, some email servers will simply reject an email that fails an SPF hard fail without first evaluating DKIM and DMARC and a legitimate email may be inappropriately rejected.

In SPF statements, IP addresses can also be specified in ranges. For example, the following SPF record contains a static IP range (198.155.0.1/24).

Adding ‘MX’ to the SPF record will include all the MX IP addresses from your domain to the list without needing to restate them and ensures that the SPF record remains valid even if an MX address changes. Thus, if your domain has all your email servers listed in MX records, then the following SPF record may suffice:

Setting up SPF when using third-party email services

Often agencies will have email sent on their behalf by other organisations, for example Microsoft as part of a Microsoft365 subscription. In this case the list of valid addresses operated by the third-party can be added to your domain’s SPF list through an ‘include’ entry, for example, Microsoft365:

Your email service provider will provide the right include statement for their email service or may provide a list of specific IP addresses or IP address ranges to add to your SPF record.

Include statements will be required for products like ServiceNow, email gateway services such as Mimecast, marketing tools such as Click Dimensions, or bulk email tools such as Vision6 or Mailchimp. Multiple includes can be added to the SPF record:

SPF lookup limit

To prevent SPF lookups being used for a denial-of-service attack, there is a 10 DNS lookup limit on resolving an SPF record. The original SPF RFC identifies which entries add to the number of lookups:

SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the ‘include’ mechanism or the ‘redirect’ modifier. If this number is exceeded during a check, a PermError MUST be returned. The ‘include’, ‘a’, ‘mx’, ‘ptr’, and ‘exists’ mechanisms as well as the ‘redirect’ modifier do count against this limit. The ‘all’, ‘ip4’, and ‘ip6’ mechanisms do not require DNS lookups and therefore do not count against this limit. The ‘exp’ modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated.

If your SPF record exceeds the 10-DNS-lookup limit, SPF authentication returns a permanent error (PermError) indicating ‘too many DNS lookups’. An SPF permanent error is interpreted in DMARC as a fail, and this has a negative impact on email deliverability.

The Queensland Government DMARC Analyzer tool shows how many lookups are required for your DNS record. To view this, select ‘DNS records’ from the DMARC Analyzer menu, select SPF Record Check, and enter the domain to check. The tool will indicate how many lookups are involved in the SPF check.

To address the 10 DNS lookup, limit the SPF record can be flattened by removing DNS lookups for A, MX or included SPF entries and converting them to their actual IP address and including these directly in the SPF record. Other techniques can also be used. Email CyberSecurityUnit@qld.gov.au for assistance.

One issue using IP addresses is the SPF record may become harder to read and to identify what an IP address relates to, so records should be kept of why each IP address has been added to the SPF record. This issue can be minimised by grouping IP addresses into local ‘includes’ for similar functions and nesting the ‘includes’ within the SPF record, although each ‘include’ will represent one DNS lookup.

A risk of using IP addresses to flatten SPF DNS entries is that if there are IP address changes to the domain’s DNS A and or MX records then the SPF record will need to be manually updated.

Third-party email sender SPF risks

A risk that can occur with a third-party email sending service is the SPF record may include a very large number of IP addresses due to a very permissive or even an ‘allow all’ SPF record. This can pose a risk for organisations using these services if SPF is relied on for authentication. One option is to set the third-party service up with DKIM and not include their SPF record in your own SPF record. This means that SPF checks on these emails will always fail, but if the DKIM is setup properly, the DKIM checks will pass and DMARC will also pass. If the third-party service provider does not support DKIM, an alternative service provider should be considered, as all up to date legitimate third-party email providers should support this capability.

SPF and subdomains

SPF records are not inherited by subdomains from their organisational domain, so specific SPF records need to be defined for each subdomain that sends email.

Subdomain wildcard records can be used to apply to all subdomains however an explicit SPF record for a subdomain will not reliably override a wildcard SPF record if a subdomain wildcard SPF record is defined, therefore care should be taken when designing and implementing wildcard SPF records.

If any email sending subdomains use the same sending servers as the parent organisational domain, then the subdomain wildcard SPF record can basically reference the same set of servers:

or can include or redirect to the parent organisational domain’s SPF record for the subdomain wildcard record:

or can use a redirect entry:

If no subdomains are used to send email, then a nil/’no server’ subdomain wildcard SPF record should be configured and will look like:

Implementing DKIM

All domains and subdomains that send email should be configured to use DKIM signing (configured on the sending mail server) and the DKIM public key should be published in the domain’s DNS.

When establishing DKIM, your email server/system should enable the creation of a public and private key pair, along with an associated ‘selector’ name. Documentation on how this occurs is system dependent, and the process for generating DKIM keys is generally facilitated by email service providers. Additional details on how to generate your own public/private key pair are provided in the DKIM section of the latest ACSC guidance; How to combat fake emails.

Once this key pair and selector name have been created, the public key needs to be published in your DNS records, as a TXT record, using the following format:

<selector> is a name configured on the sending mail server and is referenced in the DKIM headers of an email. Receiving mail servers use this name to lookup the public DKIM key for the sending domain, published as <public key>, which is the public key generated when configuring DKIM on the sending mail server.

DKIM records are not inherited by subdomains from their organisational domain, so specific DKIM records need to be defined for each subdomain that sends email.

Most email providers publish instructions on how to configure DKIM for their services, which are usually easily found through an internet search.

DKIM has the added benefit of being able to confirm that the email that has been signed has not been tampered with in transit.

Revoking a DKIM selector

If a domain has previously had a DKIM selector published which is no longer in use, the previously active selectors can be revoked by publishing the DKIM record with an empty ‘p’ value.

DKIM key lengths

As with all cryptography, the longer the key length, the more secure the signature is against potential attacks that may attempt to forge or modify the message in transit. A 2048-bit key is the current recommended minimum key length for DKIM, though many existing systems will be using 1024-bit keys.

Benefits in using 2048-bit over 1024-bit lengths

• Increased security: A longer key length provides a higher level of security against potential attacks that may attempt to alter the message in transit. The larger key size makes it more difficult for an attacker to brute-force the key and create a valid signature.
• Better compatibility: Some email servers or security software may require the use of longer key lengths for DKIM signatures. By using a 2048-bit key, you can ensure that your emails are compatible with a wider range of email servers and security software.
• Compliance: Some industry regulations or standards require the use of a minimum key length of 2048-bits for DKIM signatures. Using a 2048-bit key can ensure compliance with these standards.
• Futureproofing: Cryptographic attacks and advancements in computing power can make shorter key lengths obsolete over time. By using a 2048-bit key, you can future-proof your DKIM signatures against potential security threats and ensure they remain secure for a longer period.

Using 4096-bit keys

While this is supported, there is a need to take some extra care when using longer keys, as some DNS systems may require some additional steps to ensure the full key is able to be published in the DNS record. Many systems will handle this seamlessly, and your DNS provider should have information available on how to publish long DNS entries.

Implementing DMARC

A domain's DMARC policy is published in the domain's DNS record and is available to all recipient email servers. DMARC relies on the SPF and DKIM mechanisms. An email is deemed to pass DMARC if either (or both) SPF or DKIM are validated as ‘aligned’.

For the Queensland Government, when first starting with DMARC, a policy of None can be assigned using the following DNS record.

Publishing the above record will ensure the collection of aggregate reports into the whole of government DMARC analysis tool.

Once it appears that emails are being authenticated (an authentication rate of about 98% or higher), an agency should implement DMARC in quarantine mode, which starts to provide protection to the agency’s email domains.

Some agencies may elect to stay at quarantine, but a reject policy is recommended to provide maximum protection.

DMARC record details

DMARC records follow the extensible ‘tag-value’ syntax for DNS-based key records. The following chart illustrates some of the available tags and an example for Queensland Government domains:

By configuring all DMARC records to instruct receiving mail servers to send DMARC aggregate reports via the whole-of-government relay addresses (i.e. rua=mailto:dmarc-qldgov@qld.gov.au; ruf=mailto:dmarc-qldgov-forensic@qld.gov.au), DMARC records will not need to be changed if the Queensland Government changes to a different DMARC analysis tool provider, as these addresses will redirect to any new service provider.

As noted in the above table, DMARC reports can be sent to multiple destinations, including an agency’s own email addresses.

Guide to configuring third party email services

There are many email services in use, and each will provide guidance to how to configure DMARC and this advice is usually easily located on their website.

Allowing a third-party to send emails on behalf of an agency involves varying degrees of risk. For example, an agency’s domain might be blocked from email servers if a third-party’s email service is abused by hackers or has a large number of bounced emails (a bounced email is an email message that is rejected by a mail server).

Agencies should perform a risk assessment for all third-party email services. Adopting one or more of the following strategies is suggested, in descending order of preference, to mitigate some of the potential risks:

• Delegate a sub-domain such as comms.agency.qld.gov.au for marketing and community outreach emails using services to use. Even if the service does get blocked, it won’t impact agency email sent from other domains.
• Issue a unique DKIM key for the third-party service. This unique DKIM key must only be used for emails from the third-party email service and should not be reused for any other outbound email flow. A valid DKIM key will allow emails to pass DMARC.
• Include the third-party vendor’s SPF in the agency’s SPF entry to allow SPF to pass, unless their SPF policy is overly permissive, in which case DKIM alone can be used to pass DMARC checks.
• If the third-party email service prescribes and supports it, configure the service to re-write the 5322.FROM email address (which the user sees) to a valid email address at the vendor (with the same org domain as the envelope 5321:MailFrom address) which will pass SPF and SPF alignment, and/or DKIM and DMARC validation, and append a REPLY-TO email address to the email for the agency contact sending the email; e.g.
  • RETURN-PATH: bounces@emailserviceprovider.com
  • FROM:    messages@emailserviceprovider.com
  • REPLY-TO: john.doe@agencydomain.qld.gov.au.
    
    Email providers should provide more information on implementing this.
    Note: This approach while valid, risks emails appearing as a phishing attempt due the FROM address coming from an external address and not the sending agency.

Microsoft Office365

For agencies using Microsoft Office365 additional guidance for setting up SPF, DKIM and DMARC is provided in Use DMARC to validate email article.

When an agency uses Microsoft Office 365 as their email system then the servers used by Microsoft Office 365 to send email must be included as valid servers in their domain’s SPF record. Microsoft provide a predefined SPF include for Office365 that includes all the IP addresses of valid Office365 email sending servers. A simple SPF record for agencies that only use Office365 to send email would be:

The following link is a very clear guide to setting up DMARC when using onmicrosoft.com domains: Configure DKIM record for Office 365 - ALI TAJRAN. Other links are provided below.

DMARC inheritance

DMARC policy is inherited when it is not explicitly defined for a domain. Where a domain has an explicit DMARC record, that will define domain DMARC policy. Where a record is not explicit, DMARC will seek an appropriate policy to apply using the approach outlined below.

The following is an overview of the process of inheriting a DMARC policy where it is not explicitly defined, as defined in the DMARC RFC. If no DMARC record is found on the domain, the receiver may check one other domain for a DMARC record. This second location is known as the ‘organisation domain’, and is determined by the following process:

1. Take the domain from the ‘From’ address.
2. Check the public suffix list maintained by ICANN for the ‘largest’ suffix contained in the domain (largest being the matching public suffix with the most component parts).
3. Keep one level past the public suffix and discard the rest.

Of most relevance to Queensland Government agencies, the following domains are public suffixes:

Note that due to the nature of the above lookup approach, an explicit DMARC policy on a sub-domain will override any sp= policy on an organisation’s domain.

Note, you can use CNAME records to express a DMARC policy on an organisation domain that is referenced from other subdomains, allowing a change to the single policy to be reflected on all referencing sub-domains.

Implications of inheritance rules

For qld.gov.au domains:

• If subdomain.agency.qld.gov.au does not have a DMARC policy defined, it will inherit from agency.qld.gov.au if it exists.
• If agency.qld.gov.au does not have a DMARC policy, it will not inherit one from qld.gov.au, and in fact will simply have no DMARC policy applied as none will be found. With no DMARC policy found, many mail servers will treat the email with more suspicion and it is much more likely email from those domains will be sent to junk or not delivered at all.
• The DMARC policy set on qld.gov.au only applies directly to the qld.gov.au domain and will not be inherited by any other domain. As at 2025, new extensions to the DMARC specification are being developed which will change this approach in the future and will provide public suffix domains the ability to establish DMARC policy for subordinate domains.
• Setting an sp= flag only has an impact if the sp= policy is different to the p= policy, but doing so also causes no harm.

Issues with implementations

The DMARC standard itself notes that determining the right suffix is not guaranteed, and it should be noted specifically that the commonly used tool MXToolbox incorrectly identifies qld.gov.au as the organisation domain for all example.agency.qld.gov.au domains or for agency.qld.gov.au primary domains that do not have an explicit DMARC record in place.

This can lead users of this tool to believing that there is a DMARC record being inherited from the qld.gov.au domain, when it is not. Every other tool tested, including DMARC Analyzer’s internal DMARC check, Dmarcian and EasyDMARC correctly identifies the organisation domain for a sub-domain of example.agency.qld.gov.au as agency.qld.gov.au.

Non-delivery report (NDR) emails

An NDR is an automated email message that is generated by an email system to inform the sender that the email message could not be delivered to the intended recipient. NDRs are also known as bounce messages or delivery status notifications.

NDRs may be generated for a variety of reasons, such as:

• invalid email address
• full mailbox
• blocked sender
• out of office message
• issue with the recipient's email server.

NDRs typically include information about why the email was not delivered, such as an error code or a brief description of the problem. The content and format of the NDR can vary depending on the email system that generates it.

NDR emails typically contain a ‘From’ header that is different from the original sender's domain. This is because the NDR is generated by the mail server, and it is sent back to the ‘Return-Path’ or ‘From’ address specified in the original message. This means that the ‘From’ domain in the NDR will not match the domain in the SPF or DKIM authentication mechanisms. As a result, DMARC may fail for NDR emails.

Email service providers like Mimecast and Microsoft use distinct NDR email servers to send NDRs that differ from their standard ones. Mimecast, for instance, uses servers with a .22x address for sending out NDR messages, while normal emails are sent from servers with a .11x address. The NDR servers are NOT included in their SPF include records, and this is intentional. The below is an example of NDR servers in practice, showing emails from their main servers (with addresses of .121), and from their NDR servers (which have addresses of .221). Because these emails have DKIM in place, they have all passed DMARC checks.