Email spoofing protection guideline

Final | March 2022 | v1.0.0 | OFFICIAL - PUBLIC |QGCDG

Introduction

This Email spoofing protection guideline provides recommended best practice advice to deliver email hygiene and protection controls to all Queensland Government owned Domain Name Service (DNS) domains and subdomains that either:

• are used to send email - to reduce the likelihood and effectiveness of these domains being used for invalid email practices such as spoofing and spamming (see Configuring SPF, DKIM and DMARC for email)
• exist but are not used to send email - to reduce the likelihood and effectiveness of these domains being used for invalid email practices such as spoofing and spamming (see configuring SPF, DKIM and DMARC for non-email).

Audience

This document is primarily intended for:

• agency staff and operational areas involved in email system and web site management
• agency information security management, particularly DNS management staff
• information security governance bodies.

Scope

Whether your domain is managed in-house or by a commercial provider, this guidance should be followed to configure DNS domains and subdomains to protect them from being used in spoofing, phishing or spamming attacks.

Unprotected domains and subdomains can be used as sending domains for email spoofing, phishing and spamming, potentially resulting in fraud, reputational damage to, and reduced trust in, your organisation by external parties.

This guideline applies to all registered DNS domains and sub-domains that:

• are used to send email
• are never used to send email, e.g. web domains and "look alike" domains
• were previously used to send email but now no longer do
• are used by 3rd party email services and applications to send email on behalf of an agency.

What protections need to be configured?

SPF, DKIM and DMARC Protections

Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are mechanisms that allow receiving parties to assess the legitimacy of incoming email.

Configuring appropriate DNS records for SPF, DKIM and DMARC will increase the ability for receiving parties to identify the instances of an unauthorised party sending fake emails by masquerading as an agencys domain name.

All domains (and subdomains) that fall within the scope need to have appropriate email protections configured.

Guidance on what to configure is provided in Configuring SPF, DKIM and DMARC for email.

Additional industry guidance on SPF, DKIM and DMARC is available at:

• Sender Policy Framework
• Open SPF
• Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
• DMARC
• Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• DKIM
• Domain Keys Identified Mail (DKIM) Signatures

Protecting subdomains

Domains and their subdomains (even if no subdomains are defined) both need to be protected with SPF, DKIM and DMARC records.

SPF and DKIM records are not inherited by subdomains from their organisational domain, therefore specific SPF and DKIM records need to be defined for each subdomain that sends email. Subdomain wildcard records can be used to apply to all subdomains. 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.

DMARC is usually set at the organisational domain level and subdomains inherit the subdomain policy set via the "sp=none/quarantine/reject" parameter from their organisational domain DMARC record. There is no concept of a subdomain wildcard record for DMARC, this is achieved using the "sp=none/quarantine/reject" parameter on the organisational domains DMARC record.

An explicit subdomain DMARC record can be set to override the organisational domains DMARC record if different policies are needed.

Agencies using Microsoft 365

For agencies using Microsoft 365, additional vendor guidance for setting up SPF, DKIM and DMARC is provided at:

Use DMARC to validate email in Microsoft 365 and should be reviewed in conjunction with guidance in this document.

Email security guidance from the Australian Cyber Security Centre (ACSC)

Complementary and more detailed guidance is also available from the Australian Cyber Security Centre (ACSC) at the following link:

How to Combat Fake Emails

Combat fake emails

Monitoring Queensland Government email hygiene

The Queensland Government has centrally funded a service that supports aggregating DMARC reports and allows agencies to monitor their email hygiene.

Since 2018, DMARC Analyzer has been made available as the centralised DMARC analysis and reporting tool for the Queensland Government and provided to agencies at no cost as part of Queensland's the whole of government Cyber Improvement Program.

All Queensland Government agencies are encouraged to leverage the centralised service. If an agency has already implemented its own DMARC tool or service, it is still encouraged to leverage both the centralised service and any existing or alternative tool of choice in parallel. This can be easily achieved by configuring your agency DMARC records to send reports to the whole-of-government reporting addresses as well as to existing reporting addresses (see DMARC when using Microsoft 365 for more detail).

By sending DMARC aggregate (standard) and forensic/failure reporting to a whole of government DMARC service (i.e.

rua=mailto:dmarc-qldgov@qld.gov.au; ruf=mailto:dmarc-qldgov-forensic@qld.gov.au)

This makes any broad spoofing activity using Queensland Government domains visible to the Cyber Security Unit and therefore can be assessed and if necessary actioned.

Additionally, 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)

Then, if the whole of government service provider changes most DMARC records will not need to be changed as the GovNet mailers will redirect to any new service provider.

Access to the centralised tool can be arranged by contacting cybersecurityunit@qld.gov.au.

Configuring SPF, DKIM and DMARC for email sending domains and subdomains

SPF configuration

An SPF record defines all mail servers that are authorised to send email using the domain or subdomain.

An SPF DNS text record should be added to the authoritative DNS zone for all registered organisational domains and subdomains that send email.

Configuration and syntax guidance for configuring an SPF record can be found on multiple web sites including:

• SPF Record Syntax
• Sender Policy Framework
• DMARC analyzer.

Typical Domain SPF record

The following is an example of the skeleton syntax of an SPF record.

@ IN TXT "v=spf1 <server list> -all"

Notes:

1. <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
2. <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
3. -all causes all emails not sent from this explicit list of servers to hard fail the SPF test and the emails will be categorised as unauthorised.

SPF when using Microsoft 365

When an agency uses Microsoft 365 as their email system, then the servers used by Microsoft Office 365 to send email should be included as valid servers in their domains SPF record.

Microsoft provide a predefined SPF include for Microsoft 365 that includes all the IP addresses of valid Microsoft 365 email sending servers. A simple SPF record for agencies that only use Microsoft 365 to send email would be:

@ IN TXT "v=spf1 include:spf.protection.outlook.com -all"

Note:

• If agencies use additional email sending servers either on-premise servers or third-party email services, then the SPF record needs to include the IP addresses for these servers as well.

Additional SPF guidance is available from Microsoft here:

• Set up SPF to help prevent spoofing - Office 365 | Microsoft Docs
• How Sender Policy Framework (SPF) prevents spoofing - Office 365 | Microsoft Docs

SPF when using other or additional third-party email services or SaaS services

If an agency uses a third-party email service to send campaign triggered emails, or if an agency uses a SaaS service (Software-as-a-Service, e.g. ServiceNow) that may send emails on their behalf, then the email servers for the third-party or SaaS service need to be "included" in the agency's SPF record.

Most third-party email or SaaS services publish their server IP addresses or an SPF include for customer use. An example of an SPF record for an agency using Microsoft 365 and a third-party email service would look like:

@ IN TXT "v=spf1 include:spf.protection.outlook.com include:mail.3rdpartyservice.com -all"

Agencies should seek the vendors advice to ensure appropriate SPF configuration.

Many Queensland Government agencies use Vision6 for citizen and community outreach programs via email. Some additional guidance when using services such as Vision6 are provided in Guidelines for Configuring Third-Party Email Services.

SPF when using a third-party email gateway

If an agency uses a third-party email gateway service (e.g. Mimecast) then the email servers for the third-party service need to be "included" in the agency's SPF record.

Most third-party email gateway services publish their server IP addresses or an SPF include for customer use, e.g.:

Mimecast SPF and DKIM setup

http://knowledge.ondmarc.redsift.com/en/articles/1183013-mimecast-spf-and-dkim-setup

Agencies should seek SPF configuration advice from the third-party gateway provider.

SPF structure limitations and guidelines

One of the limitations of SPF is the restriction of ten SPF DNS sub-queries to resolve the list of approved IP addresses.

A common approach to address the ten DNS lookup limit is to flatten out the SPF record by removing DNS lookups for A, MX or included SPF entries and converting them to their actual IP address, which wont require a DNS lookup. One issue with converting to IP addresses is that the SPF record becomes hard to read and hard to identify what an IP address relates to. This issue can be minimised by grouping IP addresses into includes for similar functions and nesting the includes within the SPF record. Each include will represent one DNS lookup.

In the example below a large number of SPF DNS queries are likely and as such this may restrict the ability to add new or additional email service provider SPF entries.

agencydomain.qld.gov.au IN TXT "v=spf1 a mx mx:mail.qld.gov.au include:spf.protection.outlook.com include:spf.vendor1.com -all"

The above example will likely require at least six DNS lookups, and possibly more if there are three or more MX hosts on the agencydomain, and or if the vendor1.com SPF include entry contains additional DNS references.

The above SPF configuration can be flattened by converting DNS names to IP addresses, grouping into includes and then nesting the includes. Each include needs to be defined as a TXT record in the agencydomains DNS or published in the DNS of a supplier or vendor:

agencydomain.qld.gov.au IN TXT "v=spf1 include:spf.mail.agencydomain.qld.gov.au include:spf.vendor1.com -all"

(agency defined SPF include)

spf.mail.agencydomain.qld.gov.au IN TXT "v=spf1 ipv4:a.a.a.aipv4:mx1.mx1.mx1.mx1 ipv4:mx2.mx2.mx2.mx2 include:spf.mail.qld.gov.au include:spf.protection.outlook.com -all"

(whole of Govt defined SPF include)

spf.mail.qld.gov.au IN TXT "v=spf1 ip4:203.18.108.160/28 ip4:203.9.184.0/22 ip4:147.132.12.52 ip4:147.132.12.152 -all"

In this example:

• the number of DNS queries has been reduced, making it easier to include / add other email service providers
• ipv4:a.a.a.a. is the IPv4 address for the DNS A record for the agencydomain.qld.gov.au
• ipv4:mx1.mx1.mx1.mx1 is the IPv4 address for the first DNS MX record for the agencydomain.qld.gov.au
• ipv4:mx2.mx2.mx2.mx2 is the IPv4 address for the second DNS MX record for the agencydomain.qld.gov.au.

One of the risks of flattened SPF DNS entries is if there are IP address changes to the agencydomain DNS A and or MX records then the SPF record will need to be updated. To mitigate this risk, DNS changes should be reviewed for impact to email originating from the domain.

Additionally, some DMARC vendors provide the ability to have a dynamic SPF record which can address this challenge:

DMARC Analyzer Avoid the SPF look-up limitation with SPF Delegation

SPF for subdomains

The SPF record for an organisational domain (e.g. agencydomain.qld.gov.au) is not inherited by any subdomains so each subdomain, whether it is used to send email or not, effectively needs to be protected with its own SPF record.

A subdomain wildcard SPF record can be used that will apply to all subdomains reducing the need to configure explicit SPF records for all known and unknown subdomains.

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:

*.agencydomain.qld.gov.au IN TXT "v=spf1 <server list> -all"

Or to simply include or redirect to the parent organisational domains SPF record for the subdomain wildcard record:

*.agencydomain.qld.gov.au IN TXT "v=spf1 include:agencydomain.qld.gov.au -all"

OR

*.agencydomain.qld.gov.au IN TXT "v=spf1 redirect=agencydomain.qld.gov.au"

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

*.agencydomain.qld.gov.au IN TXT "v=spf1 -all"

DKIM configuration

DKIM (Domain Keys Identified Mail) is a protection mechanism by which sending mail servers can use a private key to sign all or parts of an email, and the receiving mail servers can verify the emails validity by decrypting the email signature with the sending domains public key published in DNS.

More details and explanation of DKIM can be found at:

• What is DKIM?
• DomainKeys Identified Mail (DKIM)

DKIM for domains and subdomains that send email

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 domains DNS:

<selectorname>._domainkey.agencydomain.qld.gov.au TXT "v=DKIM1; k=rsa; p=<public key>"

Notes:

• <selectorname> is a name configured on the sending mail server and is referenced in the DKIM headers of an email and receiving mail servers use this name to lookup the public DKIM key for the sending domain
• <public key> the public key generated when configuring DKIM on the sending mail server.

The process for generating DKIM keys is generally facilitated by email service providers, but additional details on how to generate your own public/private key pair are provided in the DKIM section of the latest ACSC guidance.

DKIM when using Microsoft 365

Microsoft 365 supports the use of DKIM for sending emails and Microsoft have published guidance on how to configure an M65 tenancy to sign outgoing emails, and how to configure custom domains DNS (CNAME records) to support DKIM.

Use DKIM to validate outbound email sent from your custom domain

Email sending domains not yet configured for DKIM

Current guidance (as at December 2020) from the ACSC says that domains or sub-domains that send email should be configured for DKIM wherever possible.

Earlier guidance from the ACSC promoting the configuration of a wildcard DKIM record for domains that send email, but are not yet configured for DKIM, is no longer considered necessary because this wildcard DKIM record, while causing no harm, is unlikely to ever be referenced in a spoofing attack.

In a spoofing attack, attackers may configure a domain that they control with a valid DKIM record allowing a spoofed email to pass a standard DKIM check, but a DMARC alignment check will fail and hence the email will fail DMARC and be subject to the domains DMARC policy (e.g. p=reject).

See guidance documents published at How to Combat Fake Emails | Cyber.gov.au for more information.

DMARC configuration for email sending domains

Organisational Domain DMARC configuration

The following DMARC DNS text record should be added to the authoritative DNS zone for registered organisational (agency) domains that send email:

_dmarc.agencydomain.qld.gov.au IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; fo=1; rua=mailto:dmarc-qldgov@qld.gov.au; ruf=mailto:dmarc-qldgov-forensic@qld.gov.au"

DMARC notes:

• agencydomain is the name of the agency's DNS domain
• this causes DMARC reports to be sent to the Queensland Governments GovNet mail relay which redirects DMARC aggregate and forensic/failure reports to the Queensland Governments centralised DMARC Analysis service
• sending reports via the GovNet mail relays eliminates the need to update multiple agency DMARC records if the service vendor changes, only the redirection at the GovNet mailer needs to be updated requiring no changes to agency DNS records
• there is no concept of a subdomain wildcard DMARC record, the "sp=reject" parameter on the organisational domain record serves the same purpose.

DMARC when using Microsoft 365

For agencies using Microsoft 365 additional vendor guidance for setting up DMARC is provided at Use DMARC to validate email in Microsoft 365.

Collecting DMARC reports to an agency repository in parallel

If an agency also wants DMARC reports collected locally in the agency's email system (Microsoft 365 or on-premise) or other repository (e.g. Splunk) then local mailboxes need to be created for the simultaneous collection of DMARC reports and the domains DMARC record needs to be adjusted to also include the target local mailboxes, e.g.

1. create a local mailbox target for aggregate reports e.g. dmarc@agencydomain.qld.gov.au
2. create a local mailbox for forensic/failure reports e.g.dmarc-ruf@agencydomain.qld.gov.au
3. create a DMARC record with multiple target rua and ruf addresses:

_dmarc.agencydomain.qld.gov.au IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; fo=1; rua=mailto:dmarc-qldgov@qld.gov.au,mailto:dmarc@agencydomain.qld.gov.au; ruf=mailto:dmarc-qldgov-forensic@qld.gov.au,mailto:dmarc-ruf@agencydomain.qld.gov.au"

Configuring DMARC for Organisational Domains with subdomains that send email

If a domain also has subdomains (e.g. app.agencydomain.qld.gov.au) that send email, then those subdomains need to have appropriate SPF and DKIM protections and also be protected by the "sp=reject" parameter on the organisational domain DMARC record (see above).

Configure an explicit DMARC record for the subdomain only if the subdomain needs DMARC policies different to what is configured on the organisational DMARC record.

Configuring DMARC if Organisational Domain doesn't send email, but with subdomains that do send email

To protect a high order domain (Organisational domain) that does not send email, but has subdomains that do send email, you should:

1. configure the organisational domain with a nil/"no server" SPF record e.g. "v=spf1 -all"
2. configure a subdomain wildcard SPF record to specify the servers approved to send mail for the subdomain(s).This will apply to all subdomains, an explicit SPF record for a subdomain will not reliably override a wildcard SPF record.
3. if the subdomain is using DKIM then configure a subdomain DKIM record(s) with the selector(s) used by the subdomain
4. configure the organisation domain with p=reject and sp=reject on the DMARC TXT record.
5. configure an explicit DMARC record for the subdomain only if the subdomain needs DMARC policies different to what is configured on the organisational DMARC record.

Guidelines for configuring third-party email services

Allowing a third party to send outbound emails on behalf of an agency involves varying degrees of risk, e.g. an agency's domain might be blacklisted if a third-partys email service is abused by hackers or has a large number of bounced emails. Agencies should perform a risk assessment for all third-party email services, and are suggested to adopt one of the following strategies, in descending order of preference to mitigate some of the potential risks:

• delegate a sub-domain for the service, e.g. comms.agencydomain.qld.gov.au for marketing and community outreach emails using services like Vision6
• and/or
• issue a unique DKIM key for the third-party service. This unique DKIM key is only to 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.
• or in some less common cases:
• 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

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.

Or if directed by the third-party vendor include the third-party vendors SPF in the agency's SPF entry to allow SPF to pass.

Additional guidance on how to configure third-party email services can be found at:

• the vendors support site
• DMARCs Email Service Provider register
• DMARCIAN How to send DMARC compliant email on behalf of others
• DMARCIAN Full Sub-domain Delegation
• DMARCIAN Sub-domain delegation with CNAMES.

Vision6 marketing email service

Vision6 is used across several agencies for community engagement, outreach, marketing and awareness campaigns. Agencies should implement Vision6s recommended SPF, DKIM and DMARC configuration as detailed at:

https://support.vision6.com.au/hc/en-us/articles/360019774071-Emails-Going-to-Spam-Set-up-Your-Domain-Records

Implementing DMARC in stages

Some agencies may not be comfortable that they know all their mail flows for a domain and so may not have all the email sending servers for that domain properly configured in the domains SPF record. Implementing DMARC in reject mode (p=reject) with an inaccurate SPF record may result in legitimate emails being rejected (or junked).

In this situation, it is appropriate to stage the implementation of DMARC by:

implementing DMARC in monitor mode (p=none) for a period of time (e.g. a week or two) while monitoring mail results in a DMARC analysis tool (e.g. the DMARC Analyzer service) and using this information to adjust and improve a domains SPF record

once satisfied that the SPF record captures all authorised email servers, then move the domain policy to reject mode (p=reject) or quarantine mode (p=quarantine).

Most major email services treat incoming mail the same under a domain policy of p=reject or p=quarantine (e.g. Microsoft 365 sends all rejected email to a users junk folder under either reject or quarantine policies).

(https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide#how-microsoft-365-handles-inbound-email-that-fails-dmarc )

Some mail services or mail gateways may provide a quarantine service and differentiate in their treatment of reject or quarantine policies.

Since the implementation of the Queensland Government DMARC Analysis service (using DMARC Analyzer) in 2018, a DMARC record with a monitor policy (p=none) (see below) has been configured for the high-level domain qld.gov.au, which allows the capturing of all DMARC aggregate and forensic reports into the service for all domains *.qld.gov.au that do not have their own specific DMARC record.

This means that all *.qld.gov.au domains have effectively been in monitor mode since 2018 and the data is already available to enable agencies to determine the accuracy of the SPF records for these domains; therefore step 1) above should be already done.

Any non-*.qld.gov.au wont have been captured in this way and may need to be treated using the steps above.

# DMARC record for qld.gov.au which captures DMARC reports for all *.qld.gov.au domains that do not have their own DMARC record

v=DMARC1;p=none;sp=none;fo=1;rua=mailto:dmarc-qldgov@qld.gov.au;ruf=mailto:dmarc-qldgov-forensic@qld.gov.au;ri=86400"

Additional information and guidance on a staged approach to implementing DMARC can be found at:

• How to Combat Fake Emails
• Best practices for implementing DMARC in Microsoft 365

Summary for email sending domains

Configuring SPF, DKIM and DMARC for non-email sending domains and subdomains

DNS domains registered for any purpose can be used as sending domains for email, and if not protected appropriately they can be used as vehicles for spam and phishing emails.

All DNS domains owned by the Queensland Government, whether used to send email or not, need to have appropriate SPF, DKIM and DMARC protections configured.

The following sections detail protections that should be applied for DNS domains and subdomains that do not send email.

SPF, DKIM and DMARC configuration actions

In order to configure non-email sending domains and subdomains for the maximum protection that SPF, DKIM and DMARC offer, the configuration actions in the following sections should be taken.

SPF configuration

The following SPF DNS text record should be added to the authoritative DNS zone for registered organisational domains that do not send email:

*.agencydomain.qld.gov.au IN TXT "v=spf1 -all"

This causes all emails from all subdomains to hard fail the SPF test since any subdomains do not send email and any emails spoofed using a subdomain should be treated as spam by receiving mail servers.

DKIM configuration

No DKIM configuration is necessary for domains (and sub-domains) that do not send email.

The combination of the specified SPF and DMARC records provide the necessary protections for domains (and sub-domains) that do not send email.

DMARC configuration

The following DMARC DNS text record should be added to the authoritative DNS zone for registered organisational domains that do not send email:

_dmarc.agencydomain.qld.gov.au IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; fo=1; rua=mailto:dmarc-qldgov@qld.gov.au; ruf=mailto:dmarc-qldgov-forensic@qld.gov.au"

DMARC notes:

• agencydomain is the name of the agency's DNS domain
• this sends DMARC reports to the GovNet mail relay which redirects DMARC aggregate and failure/forensic reports to the Queensland Government centralised DMARC Analysis service
• there is no concept of a subdomain wildcard DMARC record, the "sp=reject" parameter on the organisational domain record serves the same purpose.

If an agency also wants DMARC reports collected locally in the agency's email system (Microsoft 365 or on-premise) then see DMARC when using Microsoft 365 for additional guidance.

Summary for non-email sending domains

Appendix A

Anatomy of a DMARC resource record in the DNS

DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned (failing DMARC checks) mail it receives.

Consider a simple example DMARC TXT RR for the domain "dmarcdomain.com" that reads:

"v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@dmarcdomain.com"

In this example, the domain owner requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace "reject" with "quarantine" which would tell the receiver they shouldn't necessarily reject the message but consider quarantining it.

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

Sources: https://dmarc.org/overview/

https://dmarc.org/resources/specification/

How DMARC handles subdomains in email addresses

If an email address contains a subdomain, then the receiving mail server will check for a DMARC record for that subdomain and act according to the subdomains DMARC record. Otherwise it will fall back to the higher-order organisational domains DMARC record.

How DMARC Handles Domains and Subdomains in Email Addresses (Part 1) provides a more detailed discussion of how subdomain DMARC records are handled.